This is getting ridiculous: for as long as I can remember, Photolab does not embed any ICC profile specified by the user in the disk output options. I have tried all options available: sRGB, AdobeRGB, or an explicit path to an ICC profile elsewhere on the disk
Thus the user has to use another software to correctly embed the ICC profile.
Surely the developers understand that wide-gamut monitors that exceed the sRGB are common on desktops, tablets, and mobile devices, thus an image converted and exported into any color space without an embedded profile will be displayed inaccurately?
Some examples: an image exported in the sRGB space will display with over-saturated colors on a device with a gamut exceeding sRGB, while a 16-bit TIFF exported in the AdobeRGB or (even worse) ProPhoto space will be undersaturated displayed on a device with a gamut less than either of those. (Yes, it depends on the color numbers actually present in the image file, but it’s the general principle.)
And let’s not even think about the wasteful consequences for professionals who print on expensive large-format printers (I’m not in that category, just barely amateur.) and find that the transformation from image color space to printer paper color space may not be performed correctly, due to lack of an
embedded profile of the former.
What is the rationale for not embedding the profile?
In Photolab 6, DxO has made the effort to widen the internal working color space and to provide a variety of ways to show gamut limits for images displayed or output. It’s certainly useful to know what colors are affected by the rendering intent on screen or on output, and determine if highly saturated parts of the image may possibly lose a bit of texture, but to not embed color space information in the output makes these new features less useful. (It is a loss of metadata in the image as well.)
I confess I haven’t read all of the info about these new features. Nor am I expert in how color processing is implemented. Maybe I can ask these questions:
-
Is the new internal working color space somehow parametrized for each image by the measured color response to “real colors” by the camera sensor that the image comes from and that DxO has characterized in their Photolab camera profiles? In my limited understanding, this might ensure that Photolab’s working decoded image data created before any editing operations are applied fully represent the range of color data present in the undecoded raw file.
-
Am I right in thinking that the ICC display profile on Windows or Mac is used with a “relative colorimetric” intent on those operating systems: in-gamut color numbers will be mapped to the equivalent destination device color, while out-of-gamut numbers will be altered to the nearest in-gamut destination device color? Or does the “perceptual” rendering intent somehow get involved in the Photolab display processing, bringing all colours proportionately within the destination display device gamut, thus altering all colors, in or out of the display’s gamut?
Anyway, I’m not complaining, I’d just like to understand the choices DxO has made and mitigate my confusion as a user of the software.