I now realise that a matter I posted on recently seems to be the same as that on which another user posted in June (kokofresha: sorry, not sure how to link to that post).
If I export a file as an sRGB TIFF to my photo files, that TIFF seems to have a colour profile attached when I open the file details panel. However, if I open it with Affinity Photo when that is set to ROMM RGB, Affinity says that the file has no assigned profile, and assigns ROMM RGB (awful colour). But in Affinity, the profile attached to the file normally determines the profile, as indeed it does when I export from PL2 as Adobe RGB, when the photo looks fine.
However, if I use “Export to application” to open the same photo (sRGB TIFF) in Affinity from within PL2, it opens correctly. (Files opened in Affinity which I’ve processed in other raw converters (DPP, Fuji/Silkypix) behave normally).
Why does this issue affect the same file depending on how it is opened in the same software? I might have suspected that Affinity were at fault, but clearly the user who found this issue previously, was using another editor, not Affinity. And is the sRGB profile really missing when it actually seems to be there in the file info?
It looks like an Affinity Photo bug – they no longer use ExifTool to read Exif info for speed reasons so it somehow skips the info. I can reproduce the behaviour with sRGB tiff files (8-bit, 8-bit compressed and 16-bit). Those files have an sRGB profile embedded in them (I can confirm that with two image viewers and ExifTool), yet Affinity Photo doesn’t see the profile. One workaround is to set the colour working space in Affinity to sRGB. Or simply re-assign sRGB to the file in Affinity (Document/Assign ICC profile). This doesn’t happen with jpegs or Adobe RGB tiffs. I’d lodge this as a bug with Affinity.
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.
