v_kyr

These capabilities are sadly missing and should usually be offered in a vector program like AD. - Nowadays it should support vector based envelope and freeform distortions.

This short explanation here pretty much sums it up for the Tagged Image File Format (TIFF): Difference Between TIF and TIFF

There are also apps like Hustl for the Mac, which is easy to use and does all automatically.

In Camtasia one can usually setup a lower frame rate ...

Well, if you know that batch processed RAWs will be always underexposed by 1-2 stops, you can apply a macro on batch execution to compensate for that. - For a series of single RAW developed files (under equal lighting conditions) instead a reusable custom setup preset might be useful to use then. Or if that is overall not satisfactory, don't use APh and develop RAWs instead with another RAW converter tool here, which keeps to handle NEFs as default in a better way.

I doubt it will be implemented, otherwise they would already have announced some sort of freeform or envelope distortion as an AD v.1.7 feature. - So one has still to use other third party vector tools for things like this.

Well old DOS file name 8.3 character conventions are long ago, thus it's pretty legitime and common usage to use 4 character file name extensions nowadays. Generally it shouldn't hurt if a program generates ".tif" or ".tiff", ".jpg" or ".jpeg" etc. file format name extensions, as far as it does that in an uniform/consistently manner. So IMO it's pretty fine if the Affinity products generate consistently ".tiff" extensions instead, since it is the responsibility of the respective third party programs to deal with different file extensions when opening files. When programming it's nowadays common usage to use file filters for those file formats, which an app handles and deals with. So when opening files programs usually should do the following here ... ... File myFilename; chooser = new JFileChooser(); chooser.addChoosableFileFilter(new OpenFileFilter("jpeg","Photo in JPEG format") ); chooser.addChoosableFileFilter(new OpenFileFilter("jpg","Photo in JPEG format") ); chooser.addChoosableFileFilter(new OpenFileFilter("tiff","Photo in TIFF format") ); chooser.addChoosableFileFilter(new OpenFileFilter("tif","Photo in TIFF format") ); chooser.addChoosableFileFilter(new OpenFileFilter("png","PNG image") ); chooser.addChoosableFileFilter(new OpenFileFilter("svg","Scalable Vector Graphic") ); int returnVal = chooser.showSaveDialog(mainWindow); if (returnVal == JFileChooser.APPROVE_OPTION) { myFilename = chooser.getSelectedFile(); //do something with the file } ... ... that way it can open either case. - If a program can't handle ".tiff" as an extension and only ".tif" it's poor file format handling.

Note however that the above said is when using a vector shape with a rainbow style as fill. - If you instead rasterize the vector shape first, you can afterwards use the fill tool and apply directly another color onto the pixel.

Not sure if I understand correctly your problem here (?), but when you use the pixeltool you can place a pixel of another color on that selected pixel. Afterwards you can merge the visiable layers of the initial rainbow style shape and the single placed pixel.

Look at the APh shape tools, there is one with a donut shape, also the cog shape tool offers a lot of customizations (can also be made a ring). Try to reuse those for your mask. - Or draw two circles with the shape tools (a smaller on a bigger one) and then geometrical substract those, you will get a donut like shape too then.

See: Vector Masking in APh Also check the vector shapes donut etc. You can convert that to curves and adjust it's nodes to your needs then.

So you think it's pretty fine and normal that in APh exporting creates "four_letter_ext.tiff" files, but batch processing instead then "three_letter_ext.tif" files. - Well maybe they should write out .tiffy files ...

Yip it's pretty inconsistently handled.

I now tested that on my older OS X system here and here it works for "TIF" files ... But APh's batch conversion (which saves as xxx.tif and not xxx.tiff) does generally really do strange things when generating TIF/TIFF files here ... Thus I don't generate or export TIFF-files with APh at all on OS X, since it always messes up things. Instead I use GC or PSE etc. here then.

Ok I see it's a "tif" file and that should also be handled by NX-D, two other Nikon apps Capture NX2 and ViewNX-i are already associated to "tif" there. It might be that NX-D doesn't propagate itself to the OS to use/support that file extension, even it can handle this, since all Nikon DSLRs (and thus their software too) can deal with NEF(RAW), JPEG, and TIFF files.