I noticed that sRGB exported raw files (Nikon NEF) were way more saturated than the preview of the image in PL3. The only way to achieve jpgs that look like the preview is to set the ICC profile in the export settings. Is this setting meant to be used this way?
Thank you!
Hello @geno,
Could you, please, also play with Display ICC settings in Preferences (as it can influence the preview):
And one more: when doing the comparison, please zoom to 100% because some of the corrections are not reflected under 75%:
Regards,
Svetlana G.
Hi Svetlana, setting regarding the monitor is like you have shown. Which setting do I have to choose here?
Thank you,
Gerrit
Hello Gerrit,
For the processing you can select any custom ICC you want to apply but if you do not want to apply custom, I’d suggest you to leave the default one (which is Original).
Regards,
Svetlana G.
Question 1: Which color profile has the source image? (Also RAW may be set to Adobe RGB in camera, and PL will use this as the working color space.)
Question 2: Which program do you use the look at the exported file? Is it color managed?
Question 3: Are you working on a wide gamut monitor?
Question 4: Which ICC profile do you select at export to fix this?
There was some issue IIRC about the sRGB profile not being embedded by PL at export and some other software choking on this. If you work on a wide gamut monitor and the sRGB colors are not interpreted correctly then colors may end up oversaturated.
I would like to put it simple:
I have a cailibrated screen. So which setting is to chose here:
Which setting is to chose here to get a corresponding jpg export:
Thank you,
Gerrit
Hello Gerrit,
Color management has 2 elements in EXIF that it works with. One is a simple string that indicates the space itself (sRGB or AdobeRGB). The second is a table that determines the correspondence between the numeric values ​​in the file and the exact colors. This table is called a color profile. Without its presence, exact colors are impossible.
Half a year ago, I raised this issue in the forum and after testing with other colleagues from the forum we came to the following conclusions:
I use the “Custom” option and would recommend it.
This information was tested on PhotoLab2. I do not know PhotoLab3 has added any change to the export function.
Regards,
Koko 
Thanks Koko,
that’s what I figured based on my trials to get matching colours. Appreciate your detailed and profound explanation 
Thank you,
Gerrit
Hey, guys, do you understand that RAW files have no colorspace? That’s part of why it’s called “raw”—it is the raw sensor data.
I haven’t looked at Nikon raw files. It’s possible that it stores “sRGB” or “AdobeRGB” depending on how the camera was set, but this is just an advisory. The sensor values are converted to a colorspace by PhotoLab using algorithms specified by the “Color rendering” panel. The target colorspace is always AdobeRGB, because that is the internal colorspace of PhotoLab.
As with any program, the internal colorspace is converted to the monitor’s colorspace for display. Ideally, you have a calibrated display and you would always choose “Current profile of the display device” for the display preference. With a calibrated display, what you see (as long as it falls within the display’s gamut) is what you should get. You won’t see colors that fall outside the display’s gamut—it’s not possible.
I tried exporting a JPG with an ICC profile of “sRGB” and it does look like the sRGB option does not write out the color profile. Perhaps this reflects my ignorance—maybe files without color profiles are treated as having an sRGB color profile, so no color profile is needed.
I tried the “Original” option and, despite what kokofresha said, it wrote out no more than when I chose “sRGB”. My camera setting is “sRGB” which I completely ignore since I shoot only RAW files.
Selecting “AdobeRGB” or a custom profile embeds a profile.
I wrote out my image using the ProPhoto colorspace. I then viewed it using a program that honors the color profile. All versions of my JPG looked identical—the sRGB version with no profile, the AdobeRGB and the ProPhoto.
As one final experiment, I read the ProPhoto JPG and saved it in Photoshop as an sRGB JPG. Photoshop did include the profile information, so I’m not sure why Photolab has decided to not include it.
Geno, I don’t know why you were having a problem, but perhaps you were viewing with a program that didn’t know how to handle a file without the full profile. Choosing an ICC profile for output is a good choice. But I did want to clarify that:
Do you use a custom ICC profile for your monitor, say, is your monitor calibrated?
Yes.
(Filler text, because I’m this forum doesn’t allow me to respond with less than 10 characters)
Your first question: pick “Current profile of the display device”. Make sure in your system Color Management settings that your monitor is associated with the correct monitor ICC profile.
Your second question: if you intend to output to web, pick the sRGB option. Also make sure that when you view the exported photo, you use a colour-managed application which knows about your monitor ICC profile, and is able to read the Exif colour tag (PhotoLab doesn’t embed the sRGB profile).
Well, if I use “sRGB” for export, then the exported image looks quite over saturated, as I described initially, regardless which display or application I use.
I figured that I have to use “Custom” in the export settings to achieve a result that looks like expected. @kokofresha stated the same, so 
I can’t reproduce that behaviour on my end when I use colour-managed applications. Are you sure you use a properly set-up viewer? It sounds like you use a wide gamut monitor, so setting up your application is crucial. Also, you mentioned “regardless which display” – do you use a two-monitor set-up?
Also, when I use the “Custom” option in the export settings and point it to the default sRGB profile shipped with my OS, the resultant jpeg behaves the same way as when I pick the sRGB export option in PhotoLab, i.e. the Exif Color Space tag reads sRGB, but the file doesn’t contain the embedded sRGB profile (which can fool some applications).
I just added a request for enhanced color management when exported to sRGB. If you work significantly in the sRGB you could vote for her. I find it more correct to ask for this feature than to return to this problem in a few months.
The problem here is that it is not clear whether DxO is doing anything wrong. Maybe they are. Maybe they aren’t.
From Wikipedia: “In color management, an ICC profile is a set of data that characterizes a color input or output device, or a color space, according to standards promulgated by the International Color Consortium (ICC). Profiles describe the color attributes of a particular device or viewing requirement by defining a mapping between the device source or target color space and a profile connection space (PCS). This PCS is either CIELAB (Lab*) or CIEXYZ. Mappings may be specified using tables, to which interpolation is applied, or through a series of parameters for transformations.”
Is any profile information is actually needed when a file is declared (or assumed) to be in the sRGB space? If DxO converts the color values to the matching sRGB equivalents, then I don’t know why any further tables would be needed. Each (R,G,B) triplet would exactly specify a color in sRGB space. Of course, one could make the same argument for AdobeRGB. The mappings from both to a PCS should be well-known.
One hint from Wikipedia: “A profile might define several mappings, according to rendering intent. These mappings allow a choice between closest possible color matching, and remapping the entire color range to allow for different gamuts.” Since PL doesn’t allow you to select a rendering intent during export, then transformation tables would seem useful.
There are tons of disussions, arguments and feature requests already on this forum regarding color management. Improved color management and soft proofing are already on the list for future enhancements, so a new feature request regarding colorspaces might be a wasted vote.
Getting back to the OP, it’s difficult to determine the problem without having access to the original RAW file and the converted JPG. But if you believe the JPG is more saturated, you should file a bug report rather than make a forum entry, because it sounds like a bug. If DxO considers this not to be a bug, they might explain why in response to a bug report—they are less likely to comment on a forum thread.
If you don’t want to file a bug report, you could post a RAW image and JPG that demonstrates the problem, as I was unable to reproduce it. You might also want to describe your system (PC? Mac?) and the viewing program you use for viewing the JPG. Or since you found an easy workaround, you may no longer really care.
Color management is a broad and complex matter. But there are steps that are more important for one type of software and others that are not important. Sorry, but the soft proofing is not vital to a RAW processor. This is a feature that is mandatory for prepress, and PhotoLab is not such software. Introducing the soft proofing before improving the treatment of the sRGB workspace is an example of poorly defined priorities for me.
@freixas: I found if I have a question regarding a software which I have just purchased, it might be suitable to place a question in the forum. Guess I was wrong.
But anyway, we can stop this here as the setting described above works for me and obviously for other, too.
Please note that I am reporting DxO’s statement, not setting priorities. I don’t have any problems with soft-proofing, because I believe it’s an outcome of straightening out the color management, but in this case, my opinion is not relevant. DxO claims that both are on their to-do list, and so I was just pointing out that another enhancement request for color management would be a wasted vote. Usually when a feature gets on DxO’s roadmap, they close out the enhancement request to free votes, but it doesn’t prevent people from creating new requests for the same thing.
No, you were right, but the answer might be that it may be a bug, in which case you should report it as one (if you want a fix). The symptoms you describe, if reproducible, sound like a bug to me.
Another possible answer is that the system may be operating correctly. I spent some time trying to reproduce your problem and failed (it looks like sankos also tried and failed). I also spent some time discussing why Photolab’s behavior (leaving out profile tables for sRGB) might not be a bug. However, the behavior you observed (and sankos and I didn’t) would be a bug.
If you want an answer to your original question from forum members, you’ll have to put up some files for the members to try to help you. If you see a problem and some of us can’t reproduce it, there must be another factor at play (besides the missing sRGB profile tables). Seeing your actual files might clarify whether you have a bug or not.
If what you’re saying is that you thought DxO would answer forum queries, well, sometimes they do but mostly you get help from other forum users. If you want an answer from DxO itself, it’s best to submit a bug report.
Not saying you should pursue this if you don’t want to, just trying to tell you how I think the system works.
