Paul Coddington

This is a good point I had forgotten to consider, but it should be possible to detect and extract embedded image files by reading the header rather than load the entire file? Other apps can read/write the header and extract/embed image files in very large MKV files within a second or so.

For me it does not hang or crash, it keeps loading the file in the background (progress is written in the title bar). It is possible to continue using the program while it does so, but it creates a lot of background disk and processor churn and might eat quite a bit of memory as well. Crashing would be much worse because that can cause a user to lose current work in progress. Perhaps your test ran out of memory and my accident did not? When I click the X button, a message pops up to say AFPhoto cannot be closed while a file is being loaded and tells me to wait until it has finished loading. Sure, I can be more careful, but accidents do happen, especially with Explorer sometimes changing the order of the file list when about to select a file. Dragged files can also drop off from the mouse over the wrong app at times, such as a mouse pad glitch or a neurological tic (not everyone is young and in perfect health). It seems odd and risky behaviour to load any file before basic extension checking to see what it is and whether it can be opened. Maybe fair enough to do it with PNG and JPEG, etc, in case they accidentally have the wrong file extension, but seeing ".MKV" at the end of the filename should be instant rejection. It is possible that because drag-n-drop is a Windows integration feature, AFPhoto dev team might not have full control over this behavior.

Extra: After some more time using States, it appears that States can get muddled as more layers are added, deleted, duplicated and rearranged, and the update button does not always work properly when that happens. So, at times a collection of states may need to be re-created from scratch rather than updated.

AFPhoto appears to validate file type for compatibility after it attempts to load the file, which leads to some inconvenient outcomes. For example, when working in a folder with mixed media, it is possible to accidentally drag-n-drop a large MKV file instead of its cover image. AFPhoto will spend a very long time loading the MKV file (very large files, 8-60GB): this cannot be cancelled and AFPhoto cannot be exited until the entire file has been read and rejected. Would it be possible to evaluate compatibility of files being opened ahead of loading the entire file?

In the Metadata pane, copy any block of text into a long field, such as "Description", preferably with quite a few long words that will wrap badly (likewise, long hierarchical tags in "Keywords"). When the field is not selected, the justification is left (ragged right). But when the field is selected by clicking on it, the text oddly becomes fully justified (left+right) with uneven large spaces that attempt to compensate for uneven line splitting. Try typing in new words or deleting existing words, these spaces will grow and shrink distractingly, and it is not clear whether each space between two words is only a single space character or several space characters (a typo) without highlighting each space with the cursor to check.

I just tried it again and was initially a bit confused as to why it wasn't replicating. The missing part of the puzzle is that the PNG were being struck from a TIFF master and Affinity is truncating whenever changes to the TIFF is saved. Thanks for helping track that missing detail down. So, the problem is with TIFF, not PNG. Other details that have now become apparent: Windows Explorer writes tags to both XMP and IPTC fields identically, and does not observe the IPTC character limit (breaking the spec). Affinity imports IPTC fields without a character limit, but saves them with a character limit (observing the spec, but this means everything seems to be working fine until you later discover keywords were silently truncated). Raises the question, is IPTC taking priority over XMP an established standard, given it leads to data loss in cases where both XMP and ITPC exist? If this is the standard, should Affinity warn when a conflict is detected? Another question I need to follow up is whether ";" and "," preferences in keyword separation are cosmetic (app) or literal (file), and it is a bit tiresome having to swap between the two schemes on a per app basis. Commas are also potentially useful characters (eg: person names) which may make semicolons more desirable. I probably need to follow up on whether tagging supports escaped commas at some point. The main concern though is to not end up with a collection of images using mixtures of separators or with silently truncated keywords discovered long after backups have been overwritten.

Yes, to clarify, the problem is Affinity Photo has the following issues with keywords in metadata: If the keywords are short and comma separated, all is well. If the keywords are semicolon separated, the keyword order is scrambled and the semicolons are replaced with commas. I suspect keywords that contain commas will be split, but I have not tested this. Keywords get truncated to 64 characters, corrupting hierarchical tagging schemes. So, this is a metadata corruption issue, not just an inability to add metadata in a particular way. I do not currently know what Designer and Publisher do behind the scenes when opening and saving shared documents (they have no metadata pane, but may still have these problems).

Affinity forces keyword separators to be commas when some schemes use semicolons. Is this a standard that varies automatically by file format or is it user preference? If it comes down to user preference, then perhaps users should be offered a choice as to which separator is used in Affinity?

Keywords in the metadata pane are truncated to 64 characters, which is exhausted very quickly with hierarchical tags. Confirmed with PNG output. Not sure if this is a standards limitation or a bug. Have saved longer hierarchical tags in the past with other applications, but those were TIFF not PNG.

It is quite difficult to edit and proof-read metadata pane information, such as Description and Keywords, as the text is fully justified with often extreme spacing (sometimes wider than entire words). The spacing changes in size and entire phrases constantly move and jiggle around with every single letter typed creating confusing visual feedback. Suggest making data entry fields flush-left (ragged right) to resolve this problem. Currently, it is necessary to copy-paste text between Affinity and a text editor to ensure there aren't any extra spaces and to prevent blocks of text jiggling around while typing. Also suggest this adjustment be made to any other text entry field in the suite with this problem, where applicable.

My perspective is that any application that has a metadata editing feature is, in effect, a metadata editor and expected to conform to the established standards of metadata editing. Recompressing an otherwise unaltered JPEG is unexpected behaviour because the standards are designed to avoid that. Turns out I got around the immediate problem using EXIFTool GUI, but it is much slower and more cumbersome to correct metadata that way (open another app, then browse down through a tree of folders, rather than just drag and drop from the currently open Explorer project working folder into an already open AFPhoto).

Affinity Photo recompresses JPEG images when metadata is edited even though the image itself has no changes. Steps: 1. Make a copy of a test JPEG image as backup. 2. Edit metadata in one copy of the image in Affinity Photo. 3. Stack before and after images in layers and view as Difference.

I too am having trouble with HDR workflow but on Windows 11. AFPhoto does not seem to report levels in nits that I can find so far, and the Clip Warning does not accept arbitrary numbers to do any meaningful sanity tests in lieu of a nit picker tool. When I export an image to HDR or EXR format, the max nits reported by Clip Warning are not what is saved when exporting, not even close. Since v1 I have encountered problems trying to expand SDR images to HDR, attempting to create HDR vector illustrations, such as color swatch menus not even being close to matching tool output and documents containing vectors having their colors grossly distorted when converted to 32-bit. Yesterday, I discovered AFPhoto color management is broken on Windows 11 for SDR images when the HDR desktop is enabled. It cannot display wide gamut images because AFPhoto does not use the new color management API and Windows 11 remaps the AFPhoto window to display as sRGB. To remedy this, you have to set a compatibility setting in the Start Menu shortcut ("use legacy display ICC color profile"). But if you turn this on, will AFPhoto still be able to display HDR images correctly in HDR or will it remap them to SDR through ICC? Additionally, SDR images are displayed well below the correct brightness levels. I would really like to hear from anyone who has (or can point to) a successful HDR workflow for: 1) expanding SDR to HDR with specified targets for nit levels in AFPhoto, 2) creating vector artwork in HDR in AFDesigner, 3) converting existing SDR AFPhoto/AFDesigner projects to HDR intact and non-destructively. Hopefully one that does not require additional purchases or a great deal of study into cinema/gaming industry workflows, because color-managed HDR ideally shouldn't be any harder to work with and less intuitive than color-managed SDR, it should be point and click WSYWIG, simple enough for non-technical artists and photographers to use.

Clearly a bug because the EXIF specification stores dates as strings in YYYY-MM-YY HH:NN format. It is hard to believe that is 2024 and there it is still an uphill battle to tag images with the most basic and fundamental metadata, such as a correctly spelled name (unicode, not bastardized to ASCII and not abbreviated in length to fit an arbitrarily short field) or a date taken so that libraries of images can be accessed and retrieved using Search. Adobe, Affinity and Microsoft all have fundamental metadata bugs that halt progress, and some metadata bugs have been ignored by Adobe and Microsoft for more than 10-15 years. Now my hopes that I can tag images with Affinity are dashed for the time being as well.

1. It is not possible to set a date taken for old photographs. Try tagging a photo taken in, say, 1926. It will not be saved and will come back blank when the file is reopened. 2. IPTC fields are short, for example, some longer country names must be entered abbreviated rather than in their correct form.