superpos

Yes I disabled all the relevant settings in the Develop Assistant. I should have mentioned that. I'm doing some tests with DNG files from a Sigma DP Quattro H.

Hi, thanks for pointing that out. The Serif Labs engine is what I've been using. I did try the Apple Core engine just now, and the output was a little more blue than my baseline from the other apps mentioned. I should add that I had not noticed some of the colour profile settings in the prefs when I posted, so I did just now try setting the profile rendering to absolute colorimetric but it didn't change the output to match. I did try toggling a few more profile settings on and off and then testing the export again, but no luck. Enabling "convert opened files to working space" seems to apply the profile at least twice when developing, and resulted in a very warm image. What I settled on is maybe just choosing the 32b .icc profile in the prefs and ignoring the "output profile" option in the Develop module, as that applied the profile in the prefs anyway. I also checked that the displayed image matches between AF and Nuke when using OCIO on the viewer in both apps. The exported AF image as displayed in Nuke matches AF, assuming the correct primaries management of the imported file (ACES IDT converting primaries only). So the slight warm twist is definitely happening in AF.

Affinity Photo 1.10.4 running on OS X 12.1 on an M1 Mac. I've been checking the raw DNG development to 32-bit rgb pipeline in Affinity Photo, and I'm getting a slightly warmer image than when using other raw developers (OpenImageIO tool, DCRaw, Davinci Resolve) which all give me matching results if I develop to ACES AP0. As far as I know, I disabled all image processing on the Develop page to hopefully get a neutral export. It's also worth noting that under the hood all the apps except DCRaw are using LibRaw. Attached is a screengrab in Nuke showing a split screen of the Affinity output on the left and DNG to ACES from the other software on the right. Nuke ignores .icc profiles, but the way I believe AP works for its raw development to 32-bit RGB is it bakes the .icc output profile transform into the image rather than tagging the image with that profile - so it doesn't matter if Nuke can't read .icc profiles. Initially I thought there may be an issue with the pre-installed Apple ACEScg .icc profile selected as the output profile when developing to 32-bit RGB. But if I ignore ACES in AP and develop using an .icc profile with sRGB primaries, I get the same warm tone. I did also download an ACES AP0 .icc profile and I got the same results in Nuke. Just to be clear, that if the files exported with different .icc profiles are viewed in Nuke without taking into account the needed transformation of the primaries, then they look different as expected. When the primaries are accounted for with an ACES input transform for the primaries only, then they look the same (all warmer from AP). I'm not sure if there's an overall issue here where the .icc profiles are baking in a chromatically adapted white point that accounts for .icc profiles being based on D50, where my monitor is D65. Obviously, what I want is an absolute colorimetric transform that is not trying to account for my display in any way. It does seem less than ideal that display profiles are used to do the colour transform when OpenColorIO would be the obvious better choice, rather than only being for preview purposes. It's also possible this has nothing to do with a transform from .icc profiles and there's something else making the image slightly warmer.