IMHO, the problem is with both Affinity Photo (mainly) and DPL (marginally). I just made a few tests, exporting images as sRGB-TIFFs and opening them in various applications. Only Affinity Photo has a problem (by the way, I get the same results when exporting to application AND when exporting to disk). My colorspace in Affinity Photo is set to ROMM RGB and the “Convert opened files to working space” and “and warn” options are checked. Nevertheless, there’s no warning and no conversion when loading the file.
The metadata in the TIFF file clearly indicate that the image profile is sRGB. Normally, if no profile is embedded, the loading application should assume that the profile is sRGB, even more so if there’s a metadata entry indicating that this is actually the case. This is obviously what many applications are doing (all the applications I have on my system) except Affinity Photo.
So, the problem is mainly with AP. However, DPL is also a bit faulty because normally, the file should contain the CMM flag indicating that the advertised profile is not embedded. This flag is normally set to 0 if the advertised profile is not embedded and set to 1 if it is. This information is missing in the sRGB-Tiff files exported by DPL. However, I’m not sure that AP is looking at this flag in order to make a decision. In any case, since no profile is embedded, AP should assume sRGB as any other application and that’s it.
As we have repeatedly discussed in this forum, the problem is in the missing profile, not in the EXIF tag. The policies of different software are different - some generate an error, others do not. But this does not change the fact that the table that associates a particular value with a particular color is missing. Professional color management is not only a gamut, but also accurate color reproduction.
Most likely the difference between the colors corresponding to a value of 200,200,200 (for example) in the profiles of Nikon, Canon and the widely used sRGB IEC 61966-2.1 is small, but still exists.
Please re-read my post. What I’m trying to explain, is that embedding the sRGB profile can legitimately be considered as not mandatory (or useless), even if the file is tagged as sRGB, since the recommended application behavior (W3C/ICC) is to consider that if the profile is missing, sRGB should be assumed. This is what most applications and web browsers are doing. Even MS Word is loading these files correctly. Affinity decided to not follow this recommendation. Their problem. If you know any other application not following this recommendation, please tell me. I’m interested. I’m not aware of a single one.
So, I think that this request should be primarily be sent to Serif.
I wanted to check what AP would do if this tag was present but unfortunately, the CMMFlags entry is not writable. So, I can’t add it after the fact.
Here we are talking about professional photographic software, not browsers.
Pixellu Smart Albums is one of the software that correctly warns of a missing profile. This is software that many professional event photographers use in their work.
This flag you are talking about indicates the color space. Color profile is something radically different.
I’ll explain it simply: Every device needs a profile to convey colors as accurately as possible (monitors, cameras, etc.). This profile is a type of dictionary that translates a numeric value into a specific color. This is the reason to profile monitors and printers. If one marker was enough, we wouldn’t buy photo spectrometers.
During the time we have been leading this discussion (more than a year), I have noticed a poor knowledge of the subject matter of a large number of photographers. Therefore, I constantly urge developers to pay attention to this aspect of the PhotoLab and to minimize the possibility of unintentional mistakes by photographers.
I am not blind and I see that a huge number of images are taken for the Internet and there first-class color management is not a priority. But when your work involves printing, underestimating profiles causes problems and unforeseen costs.
I will be even more honest. I’m getting more and more tired of talking about color profiles. The reason I do it is that in this forum I was helped by 1-2 colleagues to find a temporary solution when I faced reality. I kind of pass on the good done to me later. But after more than a year without any progress on this issue, I am close to simply ceasing to devote time to this problem.
You initially identified the cause of the problem with Affinity as the sRGB profile not being embedded by DPL when exporting. OK, it is not. I just checked with an sRGB-Tiff file created with PS. Affinity displays it correctly. If I strip the profile out of this file, Affinity no longer displays correct colors although the file is still marked as sRGB. So, we know why Affinity Photo has a problem.
Now, the discussion is about DPL and whether this is a bug or a design mistake to not embed the sRGB profile when exporting such files. I explained that, IMHO, according to the W3C/ICC recommendations, this is certainly not a bug, at most a lack of consideration for the peculiarities of Affinity Photo.
That’s all. I do know what profiles are and how they are used. I just notice that except AP (and Pixellu Smart Albums), not many applications have a problem handling the colors of an sRGB-Tiff file not having the sRGB profile embedded because they all know what to do in that case. Even the small-brained Windows Image Viewer has no problems with this.
I have asked Serif about this issue and I’ll let you know what they think.
You are wrong!
I never said anything about Affinity photo. I have never used this software, and I do not plan to do so.
When I bought the PhotoLab 2 I didn’t check if it attached the profile or not. All the other professional software I use does so unless I explicitly forbid it. That’s why I had no doubts about what a PhotoLab does.
One fine day, however, I decided to add an additional photo to a photo book directly from a PhotoLab 2 (without going through Capture NX2 or Photoshop) and I was immediately warned. From there, the debate with colleagues started a year and a half ago.
The answer from the technical support was that this is the programmed behavior of the software … and this answer took 2 and a half months.
Please note 2 facts:
The behavior of a photolab when exporting to Adobe RGB is radically different and correct. The color profile is attached there. Because errors in a wider color space are more visible.
Although the underestimated, sRGB is a widely used color space by professional photographers - all event photographers work exclusively in it.
I end the discussion with a link to the topic with the requested function, which I initiated 1 year ago. I really have nothing more to say. Nor can I do more. To help, someone needs to hear.
Your shared experience further reinforces my view that PhotoLab exports need to be reworked in line with best photographic practices.
I can only guess where the problem is, but most likely at one stage one export was updated while the other was not.
As for histograms, when exported to the same color space (defined by the same color profile), the same rendering intent and the same as the black point compensation, they must be the same.
Note, however, that histograms are statistics about the number of pixels of a given value. They do not guarantee color. With different color profiles, the same color may be displayed differently on the histogram.
Unfortunately, English is not my first language and I may not be able to explain it as well as I would like.
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.
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 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.
Affinity Photo set to Adobe RGB working profile pops up this notification when opening a tif (but not jpeg) with no embedded profile.
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.
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.
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
