sRGB Export Issue Unresolved?

Do what? What appears to be happening is PL doesn’t embed a profile when you specify sRGB which as far as I can see is fine because images without color profile are supposed to be assumed to be sRGB.

When you specify a custom profile PL will embed the profile because (I guess) it doesn’t bother to test the profile for an exact match with sRGB (being named sRGB doesn’t mean it actually is). Likewise (I guess) when original is selected it embeds the input file profile without bothering to check it is exactly sRGB and able to be left out.

I would guess whatever you ‘opened’ with doesn’t assume files without profile are sRGB or it is applying a bad sRGB profile. It looks like that is what Affinity Photo does with .tif files.

Tif files exported from PL to disk with sRGB profile selected do not contain an
ICC Profile (34675) tag. If you have warnings enabled in photoshop it says the file has an embedded sRGB profile because sRGB is assumed when no profile is embedded.

When I exported to disk with a custom profile and selected “sRGB Color Space Profile.icm” the tif file still didn’t have an ICC Profile tag so I was wrong about that. I exported to disk with sRGB, custom sRGB, Adobe RGB and custom ProPhoto. Photoshop loaded and displayed them all correctly.

Affinity photo warned when loading the two sRGB versions that it was applying the working profile to an unprofiled file and messed up color when the working profile isn’t sRGB.

As far as I can see PL does not embed sRGB profiles in jpeg files either, however, Affinity photo correctly assumes jpegs without profile are sRGB.

I still don’t see PL doing anything wrong and see that Affinity Photo ought to assume sRGB for tif files without embedded profiles.

The tiff specification is pretty dumb. It says if the file is tagged RGB (RGB or monochrome being the only options for the tag) then sRGB should be assumed and an ICC Profile (34675) tag should be included. If you assume sRGB you don’t need the ICC profile and if you have an ICC profile you don’t need to assume sRGB - like I said dumb.

Confirmed.

@Gregor
Just use Exiftool and try to extract the embedded profile :

exiftool -icc_profile -b -w icc somefile.tif

Exiftool won’t find any profile. And that shouldn’t be a problem since in that case, sRGB should be assumed.

I just made a quick test. I opened the original RAW file in PS and exported it as sRGB/TIFF (the sRGB profile was embedded). There was no color shift when opening it in AP. Then, I stripped the profile out using Imagemagick (the sRGB tag still being there) and re-opened the file in AP. The color problem was back.

I’m currently discussing this with the AP support.

I am writing for the last time in this topic.

I recently looked at 2 files with a built-in sRGB profile using Exiftool.
.
One image was with built-in Nikon sRGB 4.0.0.3002, and the other with sRGB IEC61966-2.1.
The values ​​of the white point were different. With very little, but different.
In one case, the white point was 0.9505 1 1.0891.
In the other 0.95045 1 1.08905.
I don’t know what the values ​​are with other sRGB profiles, but it can be assumed that they are not the same. It would be the same with each specific color. Such a small difference is unlikely to be noticed with the naked eye, but theoretically the right way is clearly visible.

I for myself the choice of what to be color management in my work I did. I don’t know if precision in the DXO software will be a priority in the future.
I hope that at some point the developers will make their vision public. Until then, I will verify the result of my work in other software.

Be healthy!

1 Like

Affinity Photo set to Adobe RGB working profile pops up this notification when opening a tif (but not jpeg) with no embedded profile.

APTIF

The notification dismisses itself after a few seconds.

Nope you looked at one file with an sRGB profile. sRGB being shorthand for the profile defined by IEC standard 61966-2-1:1999. The other file had a profile with sRGB in the name.

Tiff files without embedded profile should be assumed to have been encoded with the IEC 61966-2-1:1999 standard profile. All the software I use except Affinity Photo does that.

Thank-you, Koko. So, nothing has changed since you first brought this issue to our attention. Best practices color management advice, I think, has been to always embed the profile – has something changed? The few extra kBs needed to do this is not much file overhead today. Is there some other downside? I had spent hours trying to track down a color matching problem I was having (not Affinity) until I found Koko’s post and a light bulb went off! Yes, there is a custom work-around by embedding Nikon or other sRGB profiles, each with its own flavor. I have been using one of Elle Stone’s non-proprietary “well-behaved” profiles available on GitHub and that seems to work well for me. But I do agree with you regarding the proper default behavior.

Even in the latest PL 4.1.1.47 on MAC this is not working, only in Export to Disk there is a profile in the file, in Export to Application not.

Unfortunately, nothing has changed with the latest version of Photolab in terms of sRGB exports. The color profile is still not attached.
I continue to export with the custom option until there is a clear indication from DXO that the problem has been fixed.

@kokofresha
Hi kokofresha,
after getting to know your findings, I was then aware of the problem and encountered something similar
in PhotoLab 4 with X-rite i1Display Studio display calibrator
– see this extract (from the very end)

BTW, your and Joanna’s JPG-files don’t show EXIF-data . When you export to JPG, have you checked ‘remove EXIF data’? – While PL4 says ‘RGB’ (of course it’s an RGB-file and not CMYK), ExifTool doesn’t show any colour space.
But when I do so and check ‘remove’, ExifTool still shows ‘sRGB’ (note: for web it’s recommended NOT to remove colour space tag). – Is this another difference between MAC and Windows?

Joanna and Mike are both on MayOS, I’m on Windows 10.
Wolfgang

The problem with missing profile is in the latest version of PL on Mac 5.1.1.52 still present… :frowning: