Paul Coddington

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.

Suggested improvements to States feature: Ability to rearrange order of States. Ability to rename States. Ability to group States in names Groups. Ability to capture unique File/EXIF/IPTC data per State. Safeguard accidental deletion of States. Safeguard accidental update of States. Safeguard accidental deletion: the Add and Delete buttons for States are very small and very close together. The incidence of accidentally clicking Delete while trying to add a new State is very high. Delete has no confirmation and no undo. Options: relocate buttons or confirm delete or undo delete State using document History? Same problem with hitting Update when aiming for Settings. Metadata: layer States are effectively subdocuments/variants, which when exported often need specific amendments to metadata (eg: if a layer containing a cat is turned off, there should no longer be a metadata tag for 'cat' when exported). At the moment, the only solution is to mash metadata for all States together and then amend metadata manually when exporting them, as was the case before States were available. If States captured metadata it would be very useful. [As an aside, I would add editing tag metadata is currently difficult because there is a text justification and scrolling bug for that field creating abnormally large gaps between tags that constantly shift while typing, making it hard to proof-read tags for punctuation and spacing errors. Tags have to be edited in Notepad and pasted in because it is too difficult to type them directly.]

I have a nagging doubt that I have previously encountered a truncation problem with tags. When this problem is investigated, it would be a good idea to check that the full length of the Tags field is always preserved and not truncated to something shorter than it should be. The Tags field can hold an large amount of data to cater for a long list of many hierarchical tags with potentially long paths. Some apps have been known to truncate it to 255 or even fewer characters, and/or limit each semicolon delimited item to an unrealistically short length. The Tags in the attached sample file have been truncated, but I think I accidentally did that while copy-pasting them (the last tag should end with the word "FILM" but ends with "F").

Problem: When exporting to TIFF, any of the Subject, Tags, Comments metadata fields are corrupted (changed to Chinese characters). Usually the Subject and Tags or the Subject and Comments fields are corrupted depending on scenario. Steps (Scenario 1): 1. Add metadata tags to a TIFF file in File Explorer. 2. Open in Affinity Photo. 3. Export to TIFF unaltered (with ZIP compression). Steps (Scenario 2): 1. Add metadata tags to an image in Affinity Photo. 2. Export to TIFF (with ZIP compression). Steps (Scenario 3): 1. Add tagged TIFF files to Batch process in Affinity Photo. 2. Use Batch process to export TIFF files unaltered to TIFF (with ZIP compression). The goal of resaving the file with ZIP compression is to workaround the bug in File Explorer that saves tagged TIFF (Zip) as TIFF (LZW) at about three times the size. However, I currently have no editors available that can save a TIFF file with metadata intact without corrupting it (this is also a bug in all Adobe products last time I used them, which was quite some time ago, and the reason I would attempt to use File Explorer to add metadata after editing). Side discussion: Compression is an interesting problem. On top of the metadata tagging in File Explorer roughly tripling the file size by converting to LZW, simply embedding a TIFF in an AFPHOTO file roughly doubles its size, and if the layer is rasterised with no modifications whatsoever, the AFPHOTO file doubles in size again (even when saved as a fresh copy to compact it). All of this adds up to massive (and expensive) storage waste. They say storage is cheap, but it isn't cheap enough to want to buy three times as many hard drives at several hundred dollars a pop to do the job of one. For the sake of not sharing family photos, examples are a frame exported from Blu-ray movie for desktop wallpaper. Tags made up to be "typical" (with Unicode characters). [Explorer bug has been reported to Microsoft.] export.tiff original.tiff

Windows 11 Pro 22H2, Ryzen 7 3700X with NVIDIA GeForce RTX 2060 Super New issues 2.2: Project file sometimes silently fails to save latest session changes (do not know how to reproduce). Other people now reporting same problem on Facebook. Project file can be missing hours of work when re-opened. Running a macro instantly crashes the application (crash report uploaded, 100% reproducible). Application does not crash when applying macro actions manually. Macros created in 2.1. Blemish Removal tool when used to dab away dust spots slows down with each successive use, until eventually the application becomes unresponsive for long periods of time. Application does not crash (so far), eventually recovers, but I have always given up when the unresponsive periods become intolerable (30s to 1 min), never pushed it further (frequently reproduceable). Merge Visible sometimes produces a result that has somewhat shifted levels/color (not easily reproduceable). Workaround is to break up merge into batches of fewer layers and then merge the results. Issues 2.2 (carried over from 2.0/2.1): Blur Brush region of influence does not preview blur effect, it previews like an erase tool (reveals layer underneath or transparency grey squares) (100% reproducible). Blur Brush tool is often reluctant to make any changes or makes some small amount of change and then becomes unable to make any more changes (even at 100%) (frequently reproducible). Grid cannot be turned on (100% reproducible). Makes it difficult to snap objects. Amending a TIFF file and saving it directly (without export) severely corrupts metadata (Subject, Tags, Comments). Comments and Subject are completely replaced by seemingly random bursts of Chinese characters, long hierarchical tags and large lists of tags are truncated even though they have not exceeded any limits imposed by File Explorer or dedicated tagging applications (100% reproducible). Application repeatedly displays a reminder dialog to turn on crash reporting when launched. Apart from settings choices being repeatedly questioned, the reminder dialog frequently interrupts train of thought. If it only comes up after a failure, then this suggests there are frequent silent failures happening in the background going unnoticed.

I wonder if this will cause problems when there are multiple profiles on the machine from different vendors? For example, different vendors install their own sRGB profiles, but they differ in accuracy, so assigning the wrong one by accident can throw the colours out. After installations and updates, I tend to review all the ICC profiles on my machine to unclutter selection lists and make it easier to use the same profile each time. Anything I don't use, I put aside in a ZIP file in case it is needed down the track.

I am working on compiling a list of problems, but it might take me a little while to check them thoroughly and decide how best to present them. As a heads up, I am encountering serious problems with Affinity Photo on Windows with HDR desktop enabled (color pickers, previews, displaying SDR documents, converting 16-bit to 32-bit, clipping warnings, some tools, are not working correctly for me). As much as I want to have MSI installers, it is more important to me to be able to archive my scanned slides in HDR format for viewing on modern displays, as the results are far more lifelike and invoke a much stronger feeling of "being there". So, prioritising fixes, especially for features not completely working yet, is most welcome.

On Windows, the settings for all three apps are stored in the "%UserProfile%\.Affinity" folder (copy paste that path "as is" into File Explorer to see it, the system will automatically autocomplete the username and drive letter). It seems to me very likely that will be preserved and carried forward during uninstallation/reinstallation. The MSI should be identical to MSIX except for installation method and executable location. It would not surprise me if they could live side-by-side, but there would be no point in doing that because they will be the same version. I am assuming all this on the basis that I wouldn't expect the program code to be re-written to package it with a different installer, and .NET-based code tends to be quite portable (it is a framework that usually allows deployment by simply copying files to the installation folder without any need for an installer at all).

The point of confusion here is that they have just been officially announced today as available "now" (see above link in OP post) yet have not appeared in the locations described. Perhaps we are looking too soon after the announcement and there is an update to the downloads page that has not had enough time to roll out yet? Or today's announcement accidentally rolled out a bit early and jumped the gun a bit? Patience. Sounds like they will be here very soon.

Ditto. I avoid Store/MSIX apps as much as possible on my Windows desktop workstation. It is important for me to be able to arrange the Start Menu in subfolders by task/topic so I don't have to memorise all my apps and can find apps when I have forgotten the names, shorten Start Menu names for speed reading legibility, remove brand names to improve alphabetic sorting, have short names on pinned items so there are no extra eye movement zig-zags to navigate text wrapping when speed reading/scrolling them. I have some neurological problems where I become fatigued quite quickly and can be impacted by clutter, messy text wrapping, and sometimes forget what name I need to type in the search box to launch an app, so for me controlling the Start Menu entries shortcuts for as many apps as possible is an accessibility issue. If only Microsoft would allow MSIX apps to be given user-defined aliases and be put in sub menus in the advanced options it would not be an issue, but the display name is locked in when the MSIX is packaged and can't be altered after the fact without breaking package certification (so far as I know).

Doh! Must be going blind in my old age! Thanks for your patience.

I seem to be encountering some color management and conversion issues with v2. Issue 1 (also present in v1): It does not seem to be possible to preserve document colors when converting documents to 32-bit from any other format. They are not mapping to equivalents (dark grey becomes light grey, etc), notably vector documents in Designer, at the least (not tested with photos yet). I am not certain if this is user-error, a conversion issue or a display issue, still bogged down in system updates/tweaks with new Windows 11 install to do thorough tests at the moment. Manual correction of all colors in document for all objects would be an enormous undertaking (intent is to experiment with converting SDR vector to HDR). Issue 2 (have not tested in v1): When Affinity Photo is launched with Windows HDR-enabled desktop (12-bit HDMI BT.2100 PQ monitor profile), SDR images with embedded ICC profiles do not display correctly (have not tested with HDR documents yet), even though the application window frame, buttons and Windows desktop all do display correctly. Photos come out looking like they have been layered transparently at about 10-20% opacity on top of a pure white background. SDR photos display correctly in all monitor gamut modes on SDR desktop (10-bit USB-C, sRGB, BT.2020. BT.709, Adobe RGB), so color management is working fine under those circumstances, at least for 8/16-bit documents (RGB and LAB). Wondering if anyone else has encountered these problems? Windows 11 22H2 with NVIDIA GeForce RTX current studio drivers

I was surprised to find the new templates that would most always be used for TV screens default to portrait (eg: 1080x1920 instead of 1920x1080). If it switches to last used, does that mean A4 (etc) will then switch to landscape? Might be better to be able to select portrait vs. landscape in the new document dialog rather than have to alter it afterwards? One extra checkbox next to the dimensions?

This is good news for me: a little OCD niggle of mine was wanting to rename the Start Menu shortcuts for easier readability at glance, have the option of putting them in Start Menu subfolders, and to have them not wrap text badly when pinned to the Start Menu due to the extra length of the version number. Seemed a little fussy to ask though.

This just caught me out as well. Was attempting to contribute to a public SVG resource, but my drop shadow got rasterised. So, I recreated the same outcome using gaussian blur on a copy of the shape instead, but that got rasterised too. Yet, when I look up SVG standards, there appears to be support for both drop shadows and gaussian blur effects. And Affinity does not rasterise gradient fills or semi-transparent objects, so this seems a bit inconsistent. It seems to be a common enough problem though: when I work with SVG files pulled from the same public resource site, I often have to convert rasterised glows and shadows to drop shadows and gaussian blurs when importing them to Affinity. Hopefully this is on the ToDo list at some point.

Hi NotMyFault, After I posted, I realized that what had happened was that my gradient had been accidentally created in an 8-bit document, but remained seemingly stuck in 8-bit when the document was corrected later to 16-bit, which seemed unexpected behavior for what I had assumed about the nature of vectors. When I recreated the overlay in 16-bit, it greatly improved, although not quite as smooth as the imported SVG version I had tried to reproduce (as practice and learning curve), but people would have trouble seeing the remaining banding on an average monitor, I think. So, I can still see some very slight gradient banding on objects I create, but not on imported SVG, which indicates things could be a little better, but the problem is not enough for anyone to really notice unless really squinting. Interestingly, when I had the gradient object visible, PNG would export as 32-bit (unexpected, so was not noticed at first), but when I had it hidden, PNG would export as 64-bit. Unfortunately, I have already corrected the problem and moved on to getting my Windows 11 upgrade underway and the files I emailed in are probably not much help after all, given my initial take on the problem was erroneous. But today I learned that not all vectors (or rather effects applied to them) in a document take on the bit depth of the document, and the bit depth of the export can depend on which objects are visible. Not sure if that is expected behavior or a glitch, but at least it can be worked around once understood.

I'm seeing significant banding in your sample file (which is reported as 16-bit DCI-P3) when opened in Affinity Designer on an sRGB display, but not when exported to PNG and opened in a photo viewer. I have high quality display settings enabled in Affinity, and my desktop is running in 10-bit. Which is interesting, because I am trying to solve a problem where a gradient I created in Affinity is banded during editing and after export, but gradients imported from SVG files created by others are not. So, playing with your file has led to an interesting discovery that might shed light on my problem. Your 16-bit document exports as 48-bit PNG, but mine exports as 64-bit PNG, unless I export with the vector object that has the gradient overlay visible, in which case I end up with a 32-bit PNG. Yet both documents are 16-bit to begin with, and export settings seem to be the same in all cases. However, mine has a transparent background and yours does not, so only the 32-bit output case is surprising. But the 64-bit/48-bit difference primed me to spot that I was unexpectedly exporting the gradient overlay vector as 32-bit, which was something I missed before. But now I am thinking the gradient that has given me trouble is somehow stuck in 8-bit regardless of the document it is embedded in. I accidentally started that object off in an 8-bit document, so perhaps I need to recreate the gradient FX in 16-bit (rather than copy-paste the vector into a 16-bit document, or convert the source document to 16-bit). And sure enough, that did make a difference. It now exports as 64-bit rather than 32-bit. It still has subtle banding not seen in an imported SVG of the same image (which I was recreating for practice as part of my learning curve), which is still a bit odd, but it has improved. But there seems to be something odd going on, such as vector objects somehow being partially baked as the bit-depth they were created in and not being upgraded to higher bit depths when copy-pasted or documents are set to new parameters. I'll have to have more of a play when I have had some sleep. It is late and I could be making silly mistakes. BTW I just realized the banding in your document might be a color-management issue, and I have a monitor that actually covers DCI, so switching monitor mode to DCI and relaunching Affinity to pick up the new monitor profile, your sample document is displaying without banding in Affinity. However, it also displays without banding after I switch back to sRGB mode(!), so now I have another problem to track down! I might take a break from this until I either restore my system from a backup image (to amend that backup image with latest video drivers and various updates, etc), and see if that fixes any glitches that may have developed, or perhaps get cracking on rebuilding the system with Windows 11, as that comes out tomorrow.

I'm seeing an odd pattern of banding with gradient overlay in Designer at the moment, that ripples badly while adjusting settings, even in 16-bit document with 10-bit video output to calibrated monitor, not just while editing but also after export to PNG 32. Not seeing banding in SVG files imported into Affinity from elsewhere (eg: from Wikimedia Commons), but rather only in objects I create. I have emailed support tonight, but just realized my attached document was accidentally set to 8-bit (however, re-testing with a 16-bit document does not solve the problem). There has been some major optimization with the latest version, so I'm wondering if this is a new problem others are encountering? But I might have made a silly error due to fatigue, so I am not jumping to conclusions yet. I have not seen this problem before now, but I haven't used gradients much until this week (I've been doing 'old school' animation-cel style art and simple icons for software). That gradients are smooth for SVG imported into Affinity, both when edited and exported to PNG, but not for vectors created from scratch within Affinity using gradient overlay FX is an interesting puzzle. Likewise, those SVG files are smooth in photo viewers and web browsers.

Yes, files have been tagged in Explorer (right click properties) and/or Windows Live Photo Gallery (used to review and amend hierarchical tags display in tree view). As described above, the subject field is being replaced with seemingly random Chinese characters and the tags field content is being truncated. Other fields remain intact. As the truncation limit seems large, a file with a small number of tags might not have a problem (but Explorer allows at least 4096 characters). --UPDATE/AMENDMENT-- I just did a quick test on a blank TIFF file, gave it bilingual Japanese/English Title and Subject fields and added 4096 random alphabetic characters to the Tags field (making sure that the last 4 characters were "FRED" to be easily spotted when truncated). A bit extreme, as I have no individual tag 4096 characters long in reality, but I do have long hierarchical tags that can add up together to 1500 characters or so. File Explorer: Title: ハウルの動く城 ❘ Howlʼs Moving Castle [2004] Subject: この世界の片隅に ❘ In This Corner of the World [2016] Tags: P6gZT6gkj...FRED (4096 chars) Open in Affinity Photo, click Save without making any alterations: Title: ハウルの動く城 ❘ Howlʼs Moving Castle [2004] Subject: 渰ᘰ䱎湵䜰蕲殖‰堀‧䤀渀 吀栀椀猀 䌀漀爀渀攀爀 漀昀 琀栀攀 圀漀爀氀搀 嬀㈀　㄀㘀崀匀 Tags: P6gZT6gkj...FRED; P6gZT6gkjZudcqJpPBafasyiDi9oSiD8Dx4s6NvTao4hLuKNfINyooEQsOc2sm8Z; Which is interesting, because this test indicates the Tags field is actually being repeated with the repeated part truncated. Casually scrolling through my normal hierarchical tags, I would probably just see the truncated tag at the end and not realize they are all still there, but partially repeated (rather than truncated). Not quite as serious, because more easily correctable in Photo Gallery tree view (spot truncated extra tags then delete them rather than recreate tags from scratch), but Subject field is still lost and extra effort can lead to more uncertainty and errors, let alone wasted time. So, running another test with a real file (bilingual Tags, semicolon separated, hierarchical depicted with "/", 1230 characters total, longest tag 260 characters), I get 1540 characters back after Save. The 17 existing tags have been somewhat reordered, 6 seemingly random tags have been repeated then appended, with all 6 repeated tags truncated to arbitrary lengths between 40 and 55 characters (originally 58 to 260 characters). So, a tag might look like... person/Japanese Spelling (Romaji Spelling) ❘ English Spelling; ...and be repeated as... person/Japanese Spelling (Romaji Spelling) ❘ Engli; ...with no immediately obvious reason for truncation point (not a special character or language change boundary). The reordering seems somewhat arbitrary as well. It would be nice if it was sorting alphabetically for better human readability, but it isn't. Blank Test.tiff Test Result.tiff

It seems to be: you can run an ICC swap macro against each image in a batch operation and it is very fast (multithreaded) and reliable, it's just that when you open a TIFF and save it again in Photo, the metadata tags get corrupted when they shouldn't. As noted in the edit, it is a file save bug only and nothing to do with batch processing after all.

Accidentally posted this to Feedback subforum. Administration then moved it to MacOS. Seems I forgot to tag the OS type. Apologies. Currently exploring freeware/trial tools to see if one can act as a workaround (to swap out incorrectly embedded ICC profile for 3,000+ TIFF files without requiring them all to be individually retagged from scratch for subject/content/credits afterwards). Windows 10 Professional x64 20H2