- S -

I've seen this before where the individual was using an EF-S lens with a Canon mount adapter to mount it to their R body. It displays OK in Canon DPP, but not in Affinity Photo. You should be able to get rid of the vignette mask in the Affinity Photo Develop persona by going to the Lens panel and unchecking "Remove Lens Vignette". However, I'm not sure whether they are any other issues as I use Canon DPP.

Are you able to give steps of a particular workflow where it doesn't embed metadata when exporting as JPG (for example, is this when exporting from the Export Persona, rather than File > Export)? Ideally, also upload a sample JPG file that it happens with here in a ZIP file. The PNG file format historically didn't support standard metadata formats (I.E. IPTC, EXIF, XMP). While the authors of the PNG specification did finally add official support for metadata chunks fairly recently (2017), they took so long to add it quite a lot of applications such as Windows File Explorer never added support for it.

None that I can think of. I would expect the user to be able to choose whether or not metadata is embedded for all slices, not just the default slice.

The Affinity Photo Export Persona will only export metadata for the default slice. When creating additional slices, the metadata is lost. Is this perhaps the issue you're experiencing? Export Persona.mp4

I am able to reproduce this issue. The original image dimensions in the above post were 4000 × 2250; the image has then been doubled in size to 8000 × 4500. In this scenario, the masks will display this phenomenon when converted to RGB/16, RGB/32, Grey/16, LAB/16. Steps to reproduce: 01 Mask Bug.mp4

I use Curves initially when processing scanned images/negatives like these. However, Curves is missing some pretty crucial features in Affinity Photo, which means that although it can be done (in combination with the Info panel), it is really time consuming compared to Photoshop. This is predominantly due to Affinity Photo missing white/grey/black point pickers in Curves – along with the auto colour correction feature in Curves. The Photoshop Auto Colour Correction feature also has advanced settings that allows tweaking how the auto settings work, which makes it really useful and can save a lot of time (in Photoshop [Alt/Opt + Click] the "Auto" button to bring up "Auto Colour Correction Options"). Once getting the image to approximately what is should look like using Curves, it creates a good starting point where you can then tweak it further using normal tools – like you would any other image. As per the below videos, it will be OK for just a few images, however if you have hundreds/thousands of images, this will not be practical. 01 - Colour Photo (_DSC1845.ARW) File: _DSC1845.afphoto [Edit: Removed large afphoto file attachment to save storage space] 01 _DSC1845.mp4 02 - B&W Photo (_DSC1810.ARW) File: _DSC1810.afphoto [Edit: Removed large afphoto file attachment to save storage space] 02 _DSC1810.mp4

Affinity Photo is sporadically cutting off one pixel from the layer width when rasterising. This is probably going to be difficult to reproduce, as the issue is sporadic. In the below examples, with the exact same images and exact same steps, sometimes it cuts off one pixel from the width and sometimes it does not. When this occurs, the layer is aligned perfectly to the pixel grid, therefore this should not be occurring. Example 1: In this video, the image is rasterised using [Document > Flatten]. The first time it works incorrectly and cuts the pixels off (999 pixels wide); the second time it works correctly and doesn't cut the pixels off (1000 pixels wide). Test 01.mp4 Example 2: In this video, the image is rasterised using [Right-click layer > Rasterise & Trim]. The first time it works incorrectly and cuts the pixels off (999 pixels wide); the second time it works correctly and doesn't cut the pixels off (1000 pixels wide). Test 02.mp4 Example 3: This video is showing the image aligned perfectly to the pixel grid before rasterising. Test 03.mp4 Grey PNG test file used in the video (1000 × 610 px): PNG Test File.zip ----- Affinity Photo - 2.1.0.1799 Windows 10 - 22H2 (19045.2965)

The TIFF file exported from Affinity Photo is 91.4 Megabytes. This is around the file size I would expect for an uncompressed 16-bit RGB TIFF file of that resolution (give or take a bit for metadata and embedded thumbnail). I.E. 4896 × 3264 = 15,980,544 pixels 15,980,544 × 48 (bits per pixel) = 767,066,112 bits 767,066,112 ÷ 8 (bits in a byte) = 95,883,264 bytes 95,883,264 ÷ 1024 = 93,636 Kilobytes 93,636 ÷ 1024 = 91.44 Megabytes Therefore, I think Capture One is storing extra data in the TIFF file for some reason. Looking at the metadata of your TIFF file using ExifTool, it lists the below properties – which I think is likely where the issue lies. [IFD0] TileWidth : 2048 [IFD0] TileLength : 2048 Looking at the Capture One help page (LINK HERE), it appears to have an export option for "Tile Dimensions". I think the reason for the extra file size is that you're exporting the image from Capture One with "Tile Dimensions" set to "2048". I would suggest going into the Capture One export options and changing it to "Not Tiled". The exported file size from Capture One will then likely be around 91.4 Megabytes – the same as Affinity Photo.

When the left-hand toolbar is full, adding more tools to via [View > Customise Tools] adds them to an overflow menu. However, once added, it does not allow the user to remove them again by dragging then back out. Video: Capture 01.mp4 ----- Affinity Photo - 2.1.0.1799

Perhaps it would be better not to store IP addresses or location data in the first place? Especially not for months like in the below page. https://forum.affinity.serif.com/index.php?/settings/devices/

That's a different clipboard issue to the one in this post; this bug report is specifically about the image data shifting right by three pixels when pasted – causing it to wrap. Your issue is regarding Affinity Photo pasting a completely blank layer, which is more closely related to the bug report in the link below. However, your issue is a bit different to that one as well, because in that one it's related to copy and pasting from a document in Affinity Photo, to another document in Affinity Photo, using [Edit > Paste Special] and pasting as "Device Independent Bitmap" or "Device Independent Bitmap V5". As your case is to do with pasting from Fireshot, it may be worth creating a new topic. I don't have Fireshot installed, so I'm unable to check whether it's related to the linked topic or not – it's possible Affinity Photo is pasting from Fireshot as a DIB or DIBv5 and so could be related. The clipboard from Affinity 2.0.3 onwards is pretty broken and it seems that their primary Windows developer has left the company.

See the below post on how to download the MSI/EXE installers, rather than the MSIX installers.

Hi Dan. Please see the video below, which includes both the Snipping Tools as well. The reason you're not seeing the issue with the other Windows Snipping tool [Winkey + Shift + S], is because Affinity Photo is then pasting as a PNG, not a "Device Independent Bitmap V5", and the issue occurs when Affinity Photo pastes the image as a "Device Independent Bitmap V5". As the issue always adds three pixels in the bottom-left corner, it almost seems as though with "Device Independent Bitmap V5", Affinity Photo is adding some bytes of data into the actual bitmap data itself (perhaps something like an RGB color table from between the header and the image data), and this is causing the image data to shift right by three pixels (drawing from left-to-right, bottom-to-top, as with a bottom-up DIB). This is then causing the right-side of the pasted data to wrap to the left-side. These bytes of data shouldn't be in the actual bitmap image data, as they are not part of the image. Versions: Windows 10 - 22H2 (19045.2604) Affinity Photo - 2.0.4.1701 Video: Paste Video.mp4

More specifically, the bug was introduced in Affinity 2.0.3. The issue did not occur in Affinity 2.0.0. See here: It seems Affinity Photo is now pasting with "Device Independent Bitmap V5" and that is where Serif introduced the bug (it doesn't affect the older "Device Independent Bitmap"). See the video for "Issue 2" at the below link: That's incorrect. Try reproducing it again without having Affinity Photo open, copying from scratch and just pasting directly into MS Paint.

I see the same thing. The clipboard in Affinity Photo V2 is pretty broken. Issue 1 (This Issue): When copy and pasting from a document in Affinity Photo, to another document in Affinity Photo and using [Edit > Paste Special], when pasting as "Device Independent Bitmap" or "Device Independent Bitmap V5", it pastes as an empty image. Video A Issue 01.mp4 Issue 2 (Reported HERE): When copy and pasting from the "Print Screen" button on the keyboard and using [Edit > Paste Special], Affinity Photo adds some bytes of data to the start of the bitmap data when pasting as "Device Independent Bitmap V5" (although not with the older "Device Independent Bitmap"). This causes the image data to shift right by three pixels (drawing from left-to-right, bottom-to-top) and making the right-side of the pasted data wrap to the left-side. Video B Issue 02.mp4 Issue 3 (Reported HERE): When copy and pasting from a document in Affinity Photo, to another document in Affinity Photo using [Edit > Paste Special] and pasting as "Serif Persona Nodes" (the proprietary Affinity format used by default when copying and pasting between Affinity apps), it doesn't automatically convert the pasted image from say RGBA/8 to RGBA/32. Video C Issue 03.mp4

I see the same thing. The issue is occurring when copying and pasting from an RGBA/8 document into an RGBA/32 document. In Affinity V1, when going to [Edit > Paste Special] there's no difference between pasting as PNG, Serif Persona Nodes or Device Independent Bitmap. Whereas in V2, pasting as PNG automatically converts it to RGBA/32, pasting as Serif Persona Nodes doesn't and pasting as Device Independent Bitmap is empty. So it seems Serif Persona Nodes (the proprietary Affinity format used by default when copying and pasting between Affinity apps) is automatically converting it in V1, but not in V2 for some reason. Video (Affinity Photo V2) Issue 03.mp4 Video (Affinity Photo V1) Affinity V1.mp4

When exporting to PDF, Affinity Photo adds unwanted edges that were not in the original document. Steps to reproduce: 1) Open the attached Affinity Photo files (at the bottom of this post). 2) Export to PDF using the 'PDF (flatten)' preset; although it occurs with other PDF presets as well. 3) Open the exported PDF at 100% view in a Chromium-based web browser (Google Chrome, Microsoft Edge, Brave Browser), or Adobe Acrobat Reader. Actual Results: The PDF shows an edge from the pixel layer, even though the pixel layer has no border in the original document. PDF A (Chrome/Edge/Brave – not correct): PDF A (Adobe Acrobat Reader – not correct): PDF B (Chrome/Edge/Brave – not correct): PDF B (Adobe Acrobat Reader – not correct): Expected results: The PDF should show only a green circle and an orange cross. Original document (Affinity Photo – correct): Test files (Zip file): Test Files.zip ----- Windows 10 22H2 (19045.2486) Affinity Photo (2.0.4.1701) Google Chrome (110.0.5481.78) Adobe Acrobat Reader DC (2022.003.20314)

I see the same issue. The issue occurs not just when toggling the Embed Metadata setting, but also when changing any setting in the Advanced section. Export Dialogue.mp4

TIFF is an acronym for "Tag Image File Format" and is the name of the file type, which is different to file extensions. In your RFC 3302 link, they say to use .tif as the file extension. File extension(s): .TIF It has also always been accepted best practice to put the most common and widely used extension first (which is .tif not .tiff), so that it is the default file extension. Microsoft documentation also says to put the most common extension first. "For Save File, include all variations of the supported file extensions, even if uncommon, and put the most common extension first." Adobe (the owners of the TIFF specification) also put the most common extension first (*.tif). TIFF (*.tif;*.tiff) Only Serif have it backwards. What Serif have done is completely nonsensical, but they won't listen to logic or reason. It's a headache when working with other applications, which all use the correct default file extension. It should look like this:

IMO, Serif should add an icon to the layer when Blend Options adjustments are not set to the default values – like they do with Layer Effects. Currently there's no indication to the user at all.

Did you try installing using the Affinity .EXE installer, rather than the .MSIX installer?

As the above poster mentioned, it's likely because [Document > Transparent Background] is enabled. You can create your own custom TIFF export preset that uses a solid white Matte, which will always export TIFF images with no transparency.

If it's not possible to program the pen buttons and there isn't a way to use some sort of on-screen Surface menu, then I guess using an on-screen keyboard may work better than trying to use the physical keyboard (or a Bluetooth keyboard). There are two different on-screen keyboards built into Windows. 1) The "Touch keyboard", that is activated in Tablet mode; or [Right-click Windows Taskbar > Show Touch Keyboard button]. 2) The "On-screen keyboard", that can be found by searching the Windows Start menu. While the "Touch keyboard" does have various different layout options, the "On-screen keyboard" should resize to a smaller size, so it doesn't take up as much screen space. They are both floating. If you're unable to find a better solution than using an on-screen keyboard, then I guess you could give feedback to Microsoft, as it seems like a bit of an omission for a tablet device. Alternatively, you may get more success trying to get Microsoft to include some sort of Modifier Keys floating menu feature in Microsoft PowerToys. One of the developers for PowerToys was recently asking for PowerToys suggestions on Mastodon. Lastly, you could give feedback in the Feedback section here for Serif to consider including on-screen Modifier Key buttons somewhere – such as in the Affinity Tools/Toolbar/Panel – like Adobe's Modifier Keys palette.

Windows clipboard is more complex than you would think it would be. I wouldn't read too much into copying from XnViewMP, as it may be copying and pasting clipboard data differently. I'm thinking the underlying issue is due to some Windows clipboard oddity that hasn't been accounted for in a change made between Affinity Photo 2.0.0 and 2.0.3. Looking at those three extra pixels in the bottom-left corner, it seems as though that's the start of the bitmap data and there's some bytes of data there that shouldn't be, which is causing it to shift right by three pixels (drawing from left-to-right, bottom-to-top). Hence why the right side ends up wrapping to the left. Edit: I posted an additional video in a post here.

It's likely due to the following setting: [Edit > Preferences > Performance > View Quality] Change the setting from "Nearest Neighbour" to "Bilinear (Best Quality)".