Michael Allman

Hi @Old Bruce. The image was generated by a toy Mac app I wrote for simple interactive brush-based "painting". The image itself is just a "blob" or "stamp" of a brush. In fact, if you use the AP Paint Brush Tool to paint a single blob of a brush with width 1000 px, opacity 100% and hardness 0%, you will see something very similar.

Hi @Hangman. Thank you for posting this workflow, however my bug report is that AP does not show transparency when loading the attached TIFF file. We've seen at least two workflows (including yours) to get it to do so _after_ the file has been loaded, but that's not really what my bug report is about. Cheers.

FYI, I've reported this as a bug in the bug forum.

When I load the attached TIFF file into AP 2.1.0, I only see black. However, this file has an alpha channel, and it should appear like a fuzzy black blob on a transparent background. I would expect that transparency to look like a checkerboard, like I see when loading the file in Photoshop.MetalPaint.tiff Please refer to the discussion here:

Thank you everyone. I think this falls under the rubric of "bug or feature"... Following @lacerto's video instructions as referenced by @walt.farrell displays the image correctly (which should be black-on-transparent). Personally, I think this is a bug. If I open an image which is black-on-transparent, I shouldn't be faced with an all-black image, even if the alpha channel is still available somewhere. The default behavior should show black-on-checkerboard, IMHO, or at least something that contrasts with black (as is the case with the Preview app). This is consistent with Photoshop and Pixelmator.

Hello, When I load the attached tiff into macOS Preview or Photoshop, I see a transparent background. When I load it in AP it shows solid black. How do I get it to show the transparency? (Or, why doesn't it show transparency in the first place?) I'm using AP 2.1.0 on macOS. Thank you very much. Michael MetalPaint.tiff

Wrong forum. Real post here: . Duh.

I'm getting prompted to update to 2.0.4.356. What's the difference between that and 2.0.4?

Oh noes! I just realized I posted in the Publisher forum instead of the Photo forum! Let's try again!

Well, I did it. I asked the question. I'm sure they'll get right on it. Top priority.

What's the difference between 2.0.4 and 2.0.4.326?

Thank you, this is helpful. It would be great if they clarified whether 2.0.4.356 is an additional patch on top of 2.0.4, and if it fixes anything else. I don't see information on that. It won't keep me up at night.

I'm being prompted to upgrade to AP 2.0.4.326. Where are the release notes? The only thing the prompt gives me is a link to https://affinity.serif.com/en-us/. Also, please put the release notes in your upgrade notice. Thanks.

I suppose if you work with affinity files directly this simplifies the situation, however afaik affinity files have no direct interoperability with anything outside the affinity ecosystem (hence my other post requesting a file format sdk so devs can start supporting it).

Thank you. 🙂

FYI, I've reported this as a bug in the bug forum https://forum.affinity.serif.com/index.php?/topic/164613-ap-overwrites-32-bit-tiff-with-16-bit-tiff-when-saving/.

If I load a 32-bit tiff in AP, make a trivial change (like applying an adjustment then undoing it) and save the file, AP saves it as a 16-bit tiff. This seems like a bug to me... Is there a workaround? Image export is not viable, because I need to save over the original file, not create a new one. I'm using AP 1.10.5. Thank you.

Hi James, Thank you. I completely missed the option under the "More" button. I was confused by the fact that AP is not saving my modified 32-bit tiff back as a 32-bit tiff, even though the document pixel format is 32-bit rgb. This sounds like a bug to me...

Please publish an SDK for reading/writing Affinity Photo .afphoto files. (Personally I'd be satisfied with something that's compatible with Apple's Image IO framework, but that's just my specific use case). This will greatly improve interoperability with third-party applications. This has been possible with Photoshop's PSD file format for years (decades?).

I am able to load 32-bit floating point rgba tiffs exported from Apple's Image IO framework into Affinity Photo. However, when I save it, Affinity Photo writes the file as 16-bit. Can you add support for saving/exporting 32-bit tiffs in a future release? OpenEXR provides this capability, however it is seriously handicapped in that it has no metadata support.

Good to know it's not off the TO-DO list. I really like Affinity Photo, and I think Serif can do something really great in a DAM. Personally, I haven't found anything that can match the now defunct Aperture. I know there are still die-hards like me that feel the same way. It's funny how Apple does document occasional compatibility enhancements to keep Aperture from outright crashing on current versions of macOS. My observation was it worked better in High Sierra than Sierra. Still, I have to give it up for good, because it will never support the D850. Cheers.

I reported a couple of problems with persisting settings between app restarts in beta 10. One of them—not persisting the default 32-bit rgb color profile—has been resolved, thank you. The other is still not working. The default value of the "RAW output format" setting in the develop assistant is "RGB (16 bit)". If I change that to "RGB (32 bit HDR)" and restart, the setting reverts to "RGB (16 bit)".

There are some changes in the handling of 32-bit color images in beta 11 compared to beta 10 that seem to be bugs. When I load a raw file it looks like Affinity is using my default rgb profile for 32-bit images instead of my default 32-bit rgb color profile. That is, the color profile is non-linear and so is the histogram. This is confusing because I thought all color handling was supposed be linear in 32-bit images. When I develop into a 32-bit color space, the color profile is still non-linear. If I convert to a new color profile in 32-bit mode, all of the options are labeled as linear. If I convert to the linear version of my current non-linear profile, the colors change subtly, the document color space is marked as linear (though the text label in the UI is truncated on the right) and the histogram looks like the histogram of a linear 32-bit image. Can someone explain what's happening here? Thanks.

With the EXIF loading issue out of the way, I've started playing around with the beta some more, especially the 32-bit color support. I found a couple of things that aren't working for me. In the Develop Assistant, the RAW output format setting is not being persisted across restarts. If I select 32 bit, close the dialog and restart, the setting reverts to 16 bit. In the Color Profiles preferences, if I select a 32 bit color profile other than sRGB and restart, the selection reverts to sRGB.

I found the problem. The exiftool file was quarantined by Safari and the Affinity Photo beta could not run it. To resolve the problem, I ran xattr -dr com.apple.quarantine /Applications/Affinity\ Photo\ Beta.app in Terminal. This won't be necessary when downloading Affinity from the App Store.