- S -

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?

The up/down/left/right arrow keys on the keyboard should adjust rotation and scale of the Clone Brush tool.

Up until mid 2016, camera raw codecs were added to Windows 10 automatically by Microsoft via Windows Update, which meant Windows File Explorer would display CR2 raw files (thumbnails and metadata) natively without the user needing to do anything. However, Microsoft stopped updating these codecs in mid 2016 (Windows 10 1607 was the last version that contained the latest camera codecs). This means Windows File Explorer will natively support raw files for cameras that were announced up to 2016 Quarter 2, but it won't natively support cameras announced 2016 Quarter 3 onwards. Therefore, if the Canon CR2 files are from a camera more recent than mid 2016, you will need to install the Microsoft Raw Image Extension from the Microsoft Store. Microsoft Raw Image Extension: https://www.microsoft.com/store/productId/9NCTDW2W1BH8

One option is to uninstall the MSIX/Microsoft Store versions of the Affinity apps and install the alternative EXE versions that Serif provide as well. Using the EXE versions will use predictable file paths to the Affinity executables (I.E. %ProgramFiles%\affinity\photo 2\photo.exe). However, if you would prefer to continue using the MSIX/Microsoft Store versions of the Affinity apps, you could add the apps to the Controlled Folder Access allow list using PowerShell. By using PowerShell, it will allow you to use wildcards (*) in place of the version numbers in the file paths to the executables. See my previous post at the below link: https://forum.affinity.serif.com/index.php?/topic/170384-saving-files-blocked-by-controlled-access-folder-how-to-fix/&do=findComment&comment=979210

When attempting to use the Healing Brush tool without using any modifiers keys to select the source, a bubble is displayed to notify the user they need to use the Alt modifier key first. However, the wording is incorrect. Current wording: You must Click + Alt Expected wording: You must Alt + Click Screenshot: ----- Affinity Photo - 2.3.1.2217 (exe installer)

I'm not sure what went gone wrong there, I recreated the image from scratch and the black outline doesn't appear (see the below modified file). I would imagine the root cause happened during the masking phase – which is not part of the file. Modified File: DSC_4324 PF Changs B.afphoto [Large afphoto attachment now removed to reduce space] As you've already tried using a mask, I assume you want to remove the black outline from the background image itself, rather than use a mask. For this particular image, I would just start again as it's a fairly simple image. However, if you did want to remove it from this image, you could use selection tools combined with [Select > Grow/Shrink] and either the healing brush tool (if removing the black outline from the background image itself) or a black/white brush (if removing the black outline using a mask). Video.mp4