I don’t think that this can be an Affinity bug because:
A raw file converted in Affinity and assigned a ROMM RGB profile displays as expected (very saturated) regardless of which working colour profile is set in Affinity (whether sRGB or ROMM).
A raw file converted in Canon DPP, with embedded sRGB profile, displays the expected colour regardless of the working colour profile set in Affinity.
The same applies to a Fuji raw file with embedded sRGB profile, converted in Silkypix.
A Canon raw converted in DPP, and with the ICC profile removed, displays like an sRGB file when the Affinity workspace profile is set to sRGB, but shows the oversaturated colour of ROMM RGB if that is set as the workspace colour. And Affinity warns correctly that the file had no attached profile and that one has been applied.
It is only the sRGB TIFFs exported from PL2 which seem to be the problem, and even then, NOT those exported directly into Affinity. It is almost as if there is something about the normally-exported TIFFs which is preventing Affinity from seeing the profile, which is actually embedded in the file, and which Affinity CAN see when the TIFF is opened from PL2. And this issue was not confined to Affinity, as the previous poster found the issue with an entirely different program.
The problem is definitely in the PhotoLab2. After a debate here in the forum a few months ago, it was found that the PhotoLab2 marked the sRGB color space in the EXIF but did not attach the profile when exported to the sRGB. Two months later, I received a formal response to my ticket from the support team and they confirmed that this was the programmed behavior of a PhotoLab2. I expressed my disappointment with this decision in an email to the support team and they confirmed that they passed my opinion to the developers. However, they did not commit to anything.
A surefire way to work around the problem is to use the custom option in the export menu and select the desired sRGB profile.
I think that if more users open a ticket to the support team asking for this to be corrected, we have a better chance of making a change.
PhotoLab2 exports sRGB files with the sRGB profile tag in them, but the profile is not embedded, so some programs have an issue with that. In this sense I agree that PhotoLab should both tag the output sRGB jpegs/tiffs, and embed the profile – this is actually the correct behaviour when using the Adobe RGB profile in PhotoLab.
Personally I export 16-bit Adobe RGB tiffs out of PhotoLab when I intend to work on them in Affinity Photo. This works fine. Then I can do a web export out of AP.
I’m assuming that what you are referring to in your last paragraph is the “Export to application” function, and I find that works fine and is how I’ve normally worked with PL converted TIFFs in Affinity. I only really became aware of the sRGB issue when I came to open several photos from within Affinity in order to create a panorama, when the “Export to application” route can’t be used. I can work around that easily enough now but agree that DxO should rectify the problem.
I recently checked to see if the issue was fixed in the latest version (4.0.2).
Unfortunately, after so long, the problem persists.
I’m disappointed that the developers don’t understand the priority of color management in a professional image processing software.
If I have to be objective, in photo lab 4 they have worked on much less important things (for example, the change in the organization of the palettes).
Yes, this is the way around the problem that we found here in the forum for PhotoLab 2.
The poor implementation of the “Оriginal” and “sRGB” options in the export menu, in turn, raises doubts in me about the confidence in color management in the PhotoLab.
After all, I always verify the result of the export in other software before passing it on to my clients.
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.
