- S -

It's not possible. Although, it's possible to create your own export presets and specify the TIFF export settings you require (such as compression, bits per channel, etc.). However, you'll need to remember to not use Ctrl + S (Cmd + S) and instead use Ctrl + Alt + Shift + S (Cmd + Opt + Shift + S) to export instead. You could also map your own shortcut key to export instead (such as Alt + S / Opt + S). Alternatively, you could use [File > New Batch Job] and use a rotate macro to batch save multiple images at a time. But for some bizarre reason the "New Batch Job" dialogue box will not list your custom export presets there and instead will default to the last export setting you used. Therefore, you will need to keep double-checking the TIFF export settings in the "New Batch Job" dialogue box by clicking on the ellipsis (…) next to TIFF. Because algorithms used for compression (ZIP, LZW, etc.) may effect the ability to open them in say 50 years time. They may also be based on proprietary technology. With an uncompressed TIFF anything will be able to open it as it's just plain data.

Most applications will either assume sRGB/8 by default if there's no embedded colour profile or guess based on other information in the file. For example, the below JPG file would be assumed to be sRGB/8. The below TIFF file would be assumed to be sRGB/8. As the above poster mentioned, Affinity Photo will also handle unprofiled images based on the settings in [Affinity Settings > Colour]. I'm not sure what's happening with the Windows File Explorer properties dialogue box. When selecting "Embed ICC Profile" in the Affinity Photo export settings and also selecting a colour profile to embed (E.G. sRGB IEC61966-2.1), Affinity Photo does add the ICC colour profile information to the image file (even with "Embed Metadata" off – which is correct). Therefore, I would expect the Windows File Explorer properties dialogue box to show "Color Representation" as sRGB, but it doesn't. I think the Windows File Explorer dialogue box is only looking at EXIF/XMP metadata to populate the "Colour Representation" field. When the "Export Metadata" option is turned off in the Affinity Photo export settings, then IPTC/EXIF/XMP metadata are all removed from the image. Therefore, as Windows is only looking at EXIF/XMP and not the "ICC_Profile:ProfileDescription" tag in the file, then it displays the colour profile as blank, even though Affinity Photo has embedded the ICC colour profile into the image.

When recording a macro, Affinity Photo crashes if a layer is named without pressing Enter. Steps to reproduce: 1) Open a new 1920 × 1080 document. 2) Go to Macro panel. 3) Click the red circle to start recording macro. 4) Go to [Layer > New Fill Layer]. 5) Click on the fill layer in the Layers panel and name it something like hello world. 6) Do not press Enter; instead left-click on a blank area in Layers panel. 7) Affinity Photo crashes. Screen Capture: Screen Capture.mp4 ----- Windows 11 - 23H2 (22631.5335) Affinity Photo - 2.6.3 (MSIX)

From Google's Transparency Report. Percentage of pages loaded over HTTPS in Chrome by platform (17 May 2025): 99% - ChromeOS 99% - Android 97% - Mac 94% - Windows 81% - Linux Free Let's Encrypt TLS certs almost certainly helped adoption.

To export a JPEG with a vector clipping path, in Affinity Photo you would use the "Convert clips to paths" option in the JPEG export options. At one point it was enabled by default (many years ago), but was then quickly changed to disabled by default once Serif realised they had accidently enabled it in error.

When attempting to download machine learning models, if Affinity Photo is unable to connect to the internet, it will stick on the "Downloading Model" dialogue indefinitely. The only way to exit is to force close Affinity Photo using Windows Task Manager. This dialogue should either automatically timeout after a predetermined period, or there should be a cancel button.

You likely edited the Intensity or Alpha curve, rather than the Master. When you reopen the Curves Adjustment layer, it defaults back to Master (which can be seen at the bottom of your screenshot).

If it walks like a duck… https://www.startupdaily.net/topic/business/canva-cofounder-says-australian-investors-dont-understand-tech-and-thats-why-theyre-listing-in-the-us/

Putting "Date Taken" metadata in a different field such as Description is not a good idea, as nothing will read it there. This date needs to be in designated IPTC, EXIF or XMP "Date Taken" metadata fields (such as EXIF DateTimeOriginal), so that other applications (and Windows File Explorer) can read it and will know what it is. This will also allow image viewers to display the images in the correct chronological order by "Date Taken" (not Date Created or Date Modified file timestamps, which will be incorrect) and ensure they appear before other images taken after 1970-01-01. To do this, the dates need to be added using alternative software that is not restricted by the 32-bit 1970 Epoch time and is therefore capable of handling a greater date range. Unfortunately, I can't really advise which applications support this. I use Exiftool with 64-bit Perl as I don't just write dates, but sometimes convert them, however I think from Exiftool 12.88 (2024-07-11), the Exiftool site now offers a 64-bit version of Exiftool that comes with Strawberry Perl included – but I haven't used it yet. The issue with Exiftool though is the dates need to be added using the command line, which is not something that's user-friendly for the vast majority of people. However, for those who are OK with scripting, it will allow adding "Date Taken" metadata to an entire folder of images at once and even allow sorting by filename and then sequentially incrementing the timestamp too, so the photos retain the correct chronological order for that date. I.E. 1940:12:25 00:01:00 1940:12:25 00:01:01 1940:12:25 00:01:02 etc.

It may be easier if you upload a sample file. However, as mentioned, one thing to look at is masking groups in Affinity Photo doesn't work properly if the group blend mode is set to "Passthrough" – which is the default setting for groups. It would need to be set to "Normal" blend mode to work more as expected. Bug report HERE. Screenshot: Example: Example.afphoto

There is a limit in the IPTC specification to 64 bytes for Keywords. https://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata#keywords IIM Specs: 2:25 Keywords, max bytes for text: 64 https://www.iptc.org/std/IIM/4.2/specification/IIMV4.2.pdf (Page 32) 2:25 - Keywords Repeatable, maximum 64 octets, consisting of graphic characters plus spaces. When exporting to JPEG and TIFF file formats, the Keywords metadata is stored under both the IPTC "IPTC:Keywords" metadata tag and also the Dublin Core "XMP-dc:Subject" metadata tag. While the "XMP-dc:Subject" metadata tag is not limited to 64 bytes and isn't truncated, EXIF and IPTC metadata have a higher priority/hierarchy than XMP metadata. Therefore, when you open the image in Affinity Photo again, it will read the "IPTC:Keywords" metadata tag, not the "XMP-dc:Subject" metadata tag. "IPTC:Keywords" appears to be limited to 64 bytes per keyword (I.E. text between each comma or semicolon), rather than 64 bytes for the entire array. As can be seen below: Before exporting: After exporting (truncated): Therefore, ordinarily I would say the issue you're experiencing is possibly linked to above limitation in the IPTC specification. However, I do not understand why you are experiencing this issue with PNG files because when exporting to PNG file format, Affinity Photo only saves the Keyword metadata to "XMP-dc:Subject" – not "IPTC:Keywords". In addition, I am unable to reproduce your issue when exporting to PNG (either in the Affinity Photo Metadata panel, or when viewing the metadata with ExifTool). In order to try to reproduce what you're experiencing, are you able to post a set of keywords that you're able to reproduce the issue with and the steps to reproduce it? Perhaps upload a zipped PNG sample file as well. Screenshot A (Exporting from Affinity Photo as TIFF): Screenshot B (Exporting from Affinity Photo as JPEG):

I wish you luck, as I agree with your comments regarding Microsoft. However, as I'm not sure it will happen given the previous responses, wouldn't it be more worthwhile trying to aim for more organisation and focus in the FOSS community and to come up with a plan to fill the holes where creative-focused software is lacking on Linux? The first step would be to have a clear plan of what's needed on Linux, the next step would be to discuss methods of obtaining grants and other funding to make it happen.

I haven't seen this icon overlay before. Is it possible the issue is being caused by Norton Backup Status Overlays or Backup Status Indicators being enabled in the Norton settings? https://www.thewindowsclub.com/chevron-character-in-a-blue-box-icon-overlay

It's broken and always has been. I wouldn't hold your breath for a fix. https://forum.affinity.serif.com/index.php?/topic/164235-masking-a-group-causes-colour-fringes-due-to-passthrough-blending-mode/ Sample file: Sample.afphoto

Flow shortcut keys were added later on (in 2.2). The Paint Brush tool Opacity shortcut is [Number keys]. The Paint Brush tool Flow shortcut is [Shift + Number keys]. While the Opacity shortcut keys will work with both the number pad and the number keys, the Flow shortcut keys need to use number keys – they don't work with the number pad.

That was the first thing I tried when it first happened and it made no difference. Looking at the issue further, there's something weird going on with the Affinity EXE installers. As a test, I clean installed Windows 10 22H2 (19045.2965) from Windows Installation Media and Affinity Photo crashes on Windows 10 now as well. The last version of Affinity Photo that doesn't crash after a clean install is "affinity-photo-msi-2.0.4.exe" – this version works OK on both Windows 10 and Windows 11. All versions from "affinity-photo-msi-2.1.0.exe" upwards crash on both Windows 10 and Windows 11. As previously mentioned, I installed "affinity-photo-msi-2.4.2.exe" within the last 3-4 weeks and it worked OK then, therefore this is a really recent phenomenon. IIRC, "affinity-photo-msi-2.0.4.exe" used the below location to store files: C:\Users\Username\.affinity Then, from "affinity-photo-msi-2.1.0.exe" upwards, during installation it moved the files from that location to the below location: C:\Users\Username\AppData\Roaming\Affinity Therefore I'm wondering whether the issue is perhaps related to this in some way, seeing as 2.0.4 works fine and 2.1.0 does not. I no longer believe it's Windows Update related, as Windows Update never had a chance to run – meaning the Affinity installer was run on a pretty much out-of-the-box Windows 10 22H2 (19045.2965). I also don't think it could be due to faulty Microsoft Defender definitions or antimalware engine or cloud heuristics logic, as Defender doesn't run in Windows Sandbox and the issue occurred in the sandbox as well. Unfortunately, I have no explanation why this issue is only just occurring now – I have never seen anything like this before. It's almost as if something changed on a particular cut-off date sometime in the last month. As licencing information is stored in the above mentioned locations, has anything changed with online activation in the last month?

Hardware acceleration is automatically off, as this machine has never had an eligible GPU for hardware acceleration (just an Intel Integrated GPU). It's a particularly odd issue, as the last time I wiped this machine was only about 3-4 weeks ago when I was testing something else. And it really is a clean install each time ("Win11_23H2_EnglishInternational_x64v2.iso" booting from USB stick and wiping all disk partitions). At that time, "affinity-photo-msi-2.4.1.exe" worked OK and also updated using "affinity-photo-msi-2.4.2.exe" OK. So, same hardware, same Operating System, same applications – just 3-4 weeks apart. Also the MSIX version still works OK. That's why I'm thinking along the lines that it's possibly not a problem with the Affinity installer/application per se, but something else has changed in the last month that the Affinity application doesn't like now (at least when installed using the EXE installer).

On a clean installation of Windows 11 and Affinity Photo, Affinity Photo crashes when trying to open a new document (or any image file). The Affinity UI is initially OK, however as soon as the user tries to do anything that invokes the canvas, it closes by itself (crashes). It's pretty unusual for an application to fail on a completely clean install, therefore I tried installing Affinity Photo in Windows Sandbox – as the sandbox is pretty much out-of-the-box – and it also crashes there too, indicating it's not a config issue. While the current issue is with "affinity-photo-msi-2.4.2.exe", I also tried "affinity-photo-msi-2.4.1.exe" that has previously worked fine on the same machine/same operating system and the issue also occurs with that installer as well now. Therefore, it's possible that Microsoft have made changes in the last month or so, that is causing an issue (either Patch Tuesday changes, or perhaps changes they may have made to facilitate "Microsoft Store installers for web"). I don't know – it's just a theory why the issue would suddenly start occurring. The Windows Store version of Affinity Photo does not crash, it's only the *.exe version. affinity-photo-msi-2.4.2.exe - Not OK affinity-photo-msi-2.4.1.exe - Not OK affinity-photo-msi-2.3.0.exe - Not OK Affinity Photo Store version - OK Other third-party app exe installations on the machine appear to be working fine so far, just not Affinity. Video showing crash on clean Affinity Photo installation in Windows Sandbox: Sandbox Screen Capture.mp4 Crash report ID (should be automatically uploaded): 978adc79-8dad-4735-81bf-794107352a55 1c943729-4412-444d-83ba-889db83334ae Debugging DMP files is not something I know much about, however Microsoft WinDbg appears to refer to the below. Unknown exception - code c06d007e (first/second chance not available) SYMBOL_NAME: serif_interop_persona+1488944 MODULE_NAME: Serif_Interop_Persona IMAGE_NAME: Serif.Interop.Persona.dll FAILURE_BUCKET_ID: APPLICATION_FAULT_c06d007e_Serif.Interop.Persona.dll!Unknown ----- Windows 11 - 23H2 (22631.3527) The Windows build number is likely higher than the current stable channel patch level, due to installing the below preview updates to see if they made an improvement. They did not. 2024-04 Cumulative Update Preview for .NET Framework 3.5 and 4.8.1 for Windows 11, version 23H2 for x64 (KB5037591) 2024-04 Cumulative Update Preview for Windows 11 Version 23H2 for x64-based Systems (KB5036980)

Although Krita is technically aimed at drawing, it looks like it already has a wide range of tools that make it suitable for photo editing as well (I.E. tools that I generally use) and a more usable UI. Therefore, from an outside perspective, it looks like it would be much more appealing to use Krita rather than GIMP for general image editing – despite not technically being aimed at those users – and is probably the one most likely to achieve this. Are there any major features you've found Krita lacks as a general image editor?

Agreed. I have attached a set of macros below created with Affinity Photo 1.6.5.135, including one for 120DPI. Importing: 1) Ensure the Library panel is active in Affinity Photo by going to [Window > Library]. 2) In the Library panel, click the "hamburger" menu in the top-right corner. 3) Select "Import Macros…". 4) Import the below Affinity Photo Macro file. Macro Set: DPI (Affinity 1.6.5.135).afmacros Screenshot:

With the field length of the country name issue (item No.2), it's likely this is due to a limitation in the IPTC specification. The tag Affinity Photo is using for the "IPTC (Image) > Country" field is the IPTC "7.4. Country (legacy)" tag. https://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata#country-legacy XMP: XMP-photoshop:Country IIM: IPTC:Country-PrimaryLocationName The information on the IPTC website for this tag (see above link) says "Read the IIM note about Max bytes for text". Therefore, it looks like there's a maximum number of bytes (64 bytes) for text in this field, which is likely why it's limited to 32 characters. https://www.iptc.org/std/IIM/4.2/specification/IIMV4.2.pdf 2:101 Country/PrimaryLocationName Not repeatable, maximum 64 octets, consisting of graphic characters plus spaces.

I suspect the reason for the date issue (item No. 1) is Serif are using Exiftool behind the scenes to read and write metadata and it's 32-bit. The problem with 32-bit is it won't be able to handle dates before 1970-01-01 00:00:00 due to 1970 Epoch time. Therefore, if a pre-1970 "Date Taken" metadata tag was written by alternative software capable of handling a greater date range (or Exiftool with 64-bit Perl for example), although the pre-1970 metadata tags will be in the file, Affinity Photo won't be able to display them – despite Windows File Explorer displaying the pre-1970 "Date Taken" field correctly. If you attempt to write a pre-1970 "Date Taken" tag using Affinity Photo, as you have found, it will ignore what you typed and write the "Date Taken" DateTimeOriginal metadata tag as 1969-12-31 23:59:59. Unfortunately, this doesn't help you with your problem, I'm just providing a bit of information.

The issue is you're not drawing different shades of grey, but different levels of opacity. Therefore, you will need to go to [Layer > New Fill Layer] and add a white fill layer below the pixel layer.

I am also able to reproduce this issue with a new blank TIFF file created with Affinity Photo. At least for the "Comments" and "Subject" fields, but not for the "Tags" field. When opening the TIFF file, Affinity Photo converts some Microsoft metadata tags to their own Serif-specific XMP metadata tags [XMP-serifExifExt]. When the file is then saved again from Affinity Photo as another TIFF file, Affinity Photo writes back to the metadata tags shown below. However, when it writes the Microsoft metadata tags, presumably a text encoding/byte issue is introduced as the written text string now appears as Chinese characters. The IFD0:XPComment tag gets written to: XMP-serifExifExt:XPComment IFD0:XPComment (as Chinese characters) The IFD0:XPSubject tag gets written to: XMP-serifExifExt:XPSubject IFD0:XPSubject (as Chinese characters) Screenshot showing comparison before and after saving in Affinity Photo: Exporting to JPEG works as expected. ----- Affinity Photo - 2.3.1.2217 (EXE) Windows 10 - 19045.4046

The sRGB ICM profile in your screenshot is listed under "ICC Profiles (Advanced Colour)". Therefore, remove the "sRGB IEC61966-2.1 (default)" profile and add it again without ticking the "Add as Advanced Colour Profile" tick box. This alone is likely not causing your issue, however it will cause a problem in combination with other settings, therefore it needs changing. Secondly, it appears a faulty ICC/ICM monitor colour profile is still being used from somewhere, which is odd as it should now be using the generic "sRGB IEC61966-2.1" profile that you've set as the default Windows colour management profile. Therefore, click on the "Advanced" tab in Windows Colour Management and check what's listed for the "Device profile" (as per below screenshot). Finally, on the Windows Colour Management "Devices" tab, the top dropdown menu currently shows Display 1. I assume you're only using one display and there's not a Display 2 listed as well?