Why does Photolab not embed ICC profiles in output?

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:

  1. 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.

  2. 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.

For printing, I simply export to a resized TIFF with the working colour space and tell the printer driver what paper/ink profile to use. In over a5 years, I have never needed to embed a printing profile

I was only talking about embedding device independent profiles such as sRGB, AdobeRGB or ProPhoto in exported JPEG or TIFF files intended to be used by other applications.

If that’s not done, how will an application in which such a file is opened and printed know the assumed color space of the file in order to do the necessary transformation to the chosen paper/ink profile? (Assuming the application manages all the color.)

Presumably none of that is necessary if the final image in Photolab is transferred directly within Photolab to another application via a plugin that sets up all the parameters of the image information (image depth, color profile, etc.) so the target application deals with it sensibly.

Sorry not to have been clear about this.

As far as I am aware PL does do this.


I just exported 3 images to disk using PL6, one as a tiff/Adobe 1998, one as jpeg/Adobe 1998, and one as jpeg/aSRG. I then opened all of them in Photoshop CS5 and the profiles were imbedded and Photoshop recognized them and used them etc.

So, this works perfectly with my PL6

1 Like

Ooops, you are right in respect to embedding all ICC profiles other than sRGB (I use sRGB output all the time).

Any sRGB output files don’t have an embedded sRGB profile. Even if no EXIF metadata is specified in Photolab’s disk output option, some EXIF metadata remains, including the “Color Space” and “Interoperability Index”, both referring to sRGB.

The assumption seems to be that any color managed application will treat the sRGB EXIF tag as equivalent to an embedded sRGB profile. But this isn’t the case for some applications I’ve used: they query the user what color space the image file should be converted from.

So I still think that embedding sRGB profiles should be a user option. “Belt and suspenders”, so to speak…

Edit: here’s the ExifTool output for a PL6 sRGB JPEG produced with no metadata in output options:

ExifTool ExifTool Version Number 12.50
EXIF Orientation Horizontal (normal)
EXIF X Resolution 300
EXIF Y Resolution 300
EXIF Resolution Unit inches
EXIF Software DxO PhotoLab 6.0.1
EXIF Modify Date 2022:11:26 00:19:07
EXIF Offset Time -05:00
EXIF Color Space sRGB
EXIF Exif Image Width 3110
EXIF Exif Image Height 4227
EXIF Interoperability Index R98 - DCF basic file (sRGB)
EXIF Compression JPEG (old-style)
EXIF X Resolution 72
EXIF Y Resolution 72
EXIF Resolution Unit inches
EXIF Thumbnail Offset 370
EXIF Thumbnail Length 15578
EXIF Thumbnail Image (Binary data 15578 bytes, use -b option to extract)
XMP XMP Toolkit XMP Core 5.5.0
XMP Modify Date 2022:11:26 00:19:07-05:00
XMP Metadata Date 2022:11:26 00:19:07-05:00
XMP Creator Tool DxO PhotoLab 6.0.1
XMP Orientation Horizontal (normal)
Composite Image Size 3110x4227
Composite Megapixels 13.1

I tried calling his with some different profiles.
All sRGB profiles like Nikons as well as my own for my monitor was embedded - except the IEC sRGB one.
The exported jpeg with IEC sRGB was only tagged with the profile. Not embedded.
But in the other hand I believe that’s one of the standard profiles and should be included on all systems.

1 Like

May I suggest some reading about DxO handling colour spaces and such

as a general note

  • PL6 allows to work in Classic-Legacy working colour space, which acts similar to PL5, and is limited to AdobeRGB colour space (maximum) – also for any export. When you have been happy so far, stay with PL6 CL. Other than PL5, in PL6 you now can softproof, but of course effectively limited by your monitor’s colour space.
    Provided you are on a (calibrated) sRGB monitor, you can edit, softproof & export
    e.g. to AdobeRGB colour space, but you will not see the full result.
    The area with (out-of-gamut) colours your monitor cannot show,
    can be indicated by the Monitor gamut warning (blue overlay).
    The area with (out-of-gamut) colours where the chosen target exceeds your monitor’s capability,
    can be indicated by the Destination gamut warning (red overlay).
    [ softproofing on a sRGB type monitor to sRGB IEC61996-2.1 the overlays cover the same area ]
    While in PL5 you may or may not have been happy with (close to) WYSIWYG,
    now in PL6 CL you can use the softproof for more precise judgements.

  • PL6 DxO Wide Gamut working colour space is by far wider and you can softproof & export e.g. to ProPhotoRGB (maximum). – If that is useful for you, depends e.g. on your monitor’s capability, your chosen output and/or what you intend to do further.
    → Usually you want to see & control (at least some of) what you are doing, while recent inkjet printers in conjunction with certain papers then allow to reproduce colours beyond AdobeRGB / DCI-P3.
    PL6 WG handles (out-of-gamut) colours differently → see DxO’s recommendations
    – also to reduce surprises.

last note


Thanks for answering me at such length, very appreciated.

Yes, I had observed that on my second monitor which almost exactly covers the sRGB gamut, the two types of gamut warnings, for the display and when soft-proofing with the sRGB profile, were pretty much the same areas of the image, which is what I expected. No problem with that, and knowing where those areas are is what I wanted.

I’d missed the difference in rendering intent treatment between the “standard” color spaces, which get some kind of custom DxO perceptual rendering, and soft-proofing with custom profiles, which get the standard ICC rendering intent choices.

Still don’t understand why Photolab does not offer the option to embed the official sRGB profile in output images, but maybe I can switch to embedding one of the sRGB equivalent profiles (e.g. the “tiny” sRGB used by Facebook). Anyway, it’s a small issue which irritated me when I opened Photolab images in other editors.

1 Like

This is not an area where I have a lot of expertise but I do recall someone else explaining why PL doesn’t embed an sRGB ICC profile - in this post here:

Assuming the post is correct then, strictly speaking, any issues arising downstream from PL6 due to the lack of an sRGB ICC profile would appear to lie with the downstream software. It’s a separate question as to whether PL6 could (helpfully) embed the profile to reduce the incidents of such issues.

1 Like

Some of our posters have a clear interest and need to embed ICC profiles. Others don’t. Either way, that’s OK. DxO PL6E can accommodate.

It’s a bit maddening, however, that the gist of the OP’s question keeps popping up again and again in this forum. Can I embed an ICC profile when exporting files from DxO PLE? Yes. How do I do that? Well, it depends.

Why does this question keep resurfacing? For starters, look at the DxO PL6E Export to Disk user interface. Select As Shot, Same as Soft Proofing, or sRGB IEC61966-2.1, and any exported image file destined for sRGB-land gets a color tag at export, but not an embedded profile.

Make any other selection, Display P3, etc., and the corresponding color profile is embedded. But you want to embed a sRGB profile? Uh-oh, OK, but you’ll need the workaround that’s been discussed in earlier threads. So, it depends.

There are no clues about any of this behavior in the DXO PL Export to Disk user interface or in the User’s Guide. That is a genuine problem, and a seemingly endless source of confusion. While streamlining and some automation can be great, taken too far it’s just dumbing down the product.

As pointed out above by Paul (in the “PL7 wish list” link), PhotoLab is conforming to the EXIF standard. Applications that can’t see that the ColorSpace tag is set to “sRGB” and thus insist on an embedded profile are not conforming to the standard. Why does DxO need to document this? I agree that it’s a problem, and it would be nice if PhotoLab provided an option to embed the color profile for sRGB, but it shouldn’t be necessary because that’s what the ColorSpace tag is for!


The last two posts have explained in black & white the standards justifying PL’s seemingly inconsistent behaviour with color profile embedding, information somehow I never found on my searches on this topic.

Thank you everyone!

Is it true to say that if an image does not have an embedded profile then software always assumes sRGB?

1 Like

The pure technical answer is 'depends on the software '. But often , yes.
Irfanview enables you to pick which profile to assume for instance.

And photoshop and affinity photo may use the profile selected as working profile , or some other default from the settings . But if you never touched those settings , they are set to sRGB so ‘yes’.

So, it’s a safe assumption. But some software does allow you to override it or use a setting in deciding what to do with it.

For the record , i have never had issues with embedding a profile. I remember this being a Mac thing where it didn’t work ok. It’s fine for me in PL5 and PL6.

I export my images in linear rgb or linear rec2020, and use a custom resize and convert script to resize + sharpen it , and that converted to normal sRGB on the output (so the resizing is done in linear space ).

So PL6 export is set to a custom icc profile, in my case the one from Elle’s profiles for linear rec2020. Something like elle-rec2020-g10 it’s called.

Anyway, it’s working fine because its embedded and programs like affinity photo, irfanview show the image correctly .

The image could also be tagged with a profile without have it embedded. Which is the case with sRGB IEC profiles.
In such cases the CMS will use that profile - if it have it since before.