Not to my knowledge. I have a 27" Apple Cinema Display which, from what I can find, it is an 8bit display that supports around 75% of AdobeRGB.
If you export for printing using sRGB you are going to get problems. If you export for web use using wider gamuts you are going to get problems.
The colour space of your screen doesn’t affect printing.
Thank you. Definitely going to check it out.
I hope you will give consideration to the system used in C1. Effectively DXO is already soft proofing in aRGB. Simply selecting another profile, usually for print, and then adjusting the image to match the profile is a really simple way of working and I would have thought very easy to program?
You do not get the ability to compare aRGB and Printer profile as in LR but do you actually need it?
By using a filled (and labelled) local adjustment layer (when you give us this option) when soft proofing, you can effectively embed the print adjustment in the DXO file.
Turning the soft proof layer on/off allows you to compare soft proof print to aRGB screen image, if you must 
Turn off the soft proof layer and export to Tif to get your image for printing through, for example, Qimage.
@StevenL Does Joanna have it “right”? I ask because I’m confused how DXo can transform an image to a wider color space.
Thanks.
DXO has a RAW image. It has the widest available color space for the image in question. It is the starting point.
Images in a narrower space can be transformed into a wider space but you don’t get new colors through the transformation.
It’s like transforming an 8-bit image in photoshop to 16-bit. You don’t suddenly get more dynamic range.
Thanks Mike. That all makes sense, but I’m wondering what happens to that RAW file when PL starts working on it in ARGB? Doesn’t it lose any colors that are out of the ARGB Gamut? If there ARE more colors kept, then we aren’t seeing everything when we edit in PL with our ARGB display. If there aren’t then I don’t see any advantage to exporting in ProPhotoRGB.
Steven, I think I can speak from everyone commenting here that we all really appreciate your participation in this thread.
I have one remaining question.
First, I agree.
Ok, so RAWs won’t have color profiles. Theoretically they do have some limited gamut, but that’s another story.
There is no “preference” for color space when we are editing. We choose an output “ICC Profile” when we export an image. So, AT LEAST, the image conforms to that color space after all corrections are applied and the image is output.
While the image data is being manipulated through the processing pipeline in photo lab, is any color profile applied? Does DXO utililize the maximum color gamut available during each step of processing between raw, debayer/Deepprime, exposure, color, rotation, cropping, etc, etc, Or are the pixel calculations constrained by some profile? (And by the way I presume that math is all 16-but, or is it float data? Okay geek question, sorry.)
I think it would help us to understand if there are any constraints applied before the final output.
Does the question make sense? Appreciate any insight you can provide without divulging company secrets.
I thought I had seen an older reply from DXO staff that the PL working space is AdobeRGB This is from Wolf - DXO Staff. I hope this will shed some light on our topic. For me it has confirmed that AdobeRGB is the PL working color space and that there is no advantage to exporting in ProPhotoRGB.
The image sensor contains color filters, typically RGB ones. The exact nature of that red, green and blue depends on the chemicals used to make these filters, and it is slightly different for each camera manufacturer and camera model. That’s what I call “native color space of the camera”. It is not intended for display, it’s what the sensor “sees”.
Most cameras allow setting a color space in their settings, typically either sRGB or AdobeRGB. This setting impacts the JPEG images produced, but it does not impact the data in RAW files. The setting is still reported in the EXIF data of the RAW file.
If I remember correctly, we already had a thread with colour management, colour spaces, etc.
I had posted this video at that time Affinity Photo for desktop tutorials
and we have discussed this and other things
But no matter where and how you search and read, somehow you always remain a little uncertain afterwards.
In the end, however, I am satisfied with my workflow and the results, even if the professionals among you throw their hands up in horror.
I don’t have to be a vehicle engineer to travel comfortably by car, bus, train or plane and arrive relaxed at my destination.
I personally would love to see such feature one day!
@nwboater do you agree that the saturation warningcolors arn’t adjusted to the screen capable colorspace? Nor the set export colorspace or icc?
And that soft proofing adjustment is done by default when you export to a 8bitjpeg sRGB or any other 16bit container in sRGB?
(workingspace is AdobeRGB. After all.)
My simple test shows that the warning is triggert by the colorchannel numbers/values which from raw to preview are always based on AdobeRGB. (inclines larger steps in the colorhue. More distance between bleeched and full saturated in the same steps (0-255) )
A exported file in the saruration warning is clipped or squeezed in sRGB colorspace.(don’t know if it’s compressed( which means recalculated for sRGB hue) or simply cut off at the 255 marker.)
In the present working the warning colors of saturation are useless if you want to end up in sRGB because of well i did show in my former post.
Peter, I’m in Kindergarten on ColorSpace. Most of what you and others discuss here is way above my knowledge level. So I just can’t answer your questions. However from what you post it certainly seems there are some issues re sRGB and I hope that DXO will resolve them.
There was some debate on the working color space and I recalled seeing what I reposted. For me it answered that AdobeRGB IS the working color space for PL. I also couldn’t see any advantage to Exporting in a wider color gamut than the PL color space and that also was confirmed in the post.
@OXiDant ,
Do you know what rendering intent is used?
George
That explanation is crystal clear. Thank you for confirming.
export to Original (= camera setting), AdobeRGB, sRGB or Custom w/ perceptual rendering intent
( different to DxO’s print module )
i didn’t know but it’s answered by @Wolfgang
explanation of Relative Colorimetric and Perceptual
https://www.cambridgeincolour.com/tutorials/color-space-conversion.htm
what i find struggling is for most people is a straight forward color management mostly enough.
clear if 's => then’s and some check modes to see if it’s in or out.
[in] means no futher action needed => print or export to jpeg done.
[out] means warning must be shown. like the warning colors of the sun and moon ikon.
So if i would like to check if my AdobeRGB preview image would fit inside any choosable ICC or sRGB 8 or 16bit it should be shown in the preview of the export modes.
development to jpeg or tiff or lineair DNG (not rawDNG) is the same as printing in essence.
So my ideal kindergarten modes would be:
Hi Peter,
I’ve read your posts a couple of times …
Your screen is 100% sRGB capable, which means the display also plays back in AdobeRGB colour space – but only to a certain degree (roughly as far as sRGB is contained) → see graphic
I do not understand your explanation about “Protect saturated colors” (below your camera’s Color Rendering), while of course OFF with an exported TIFF-file.
The blueish complementary colour is nothing else than an overexposure warning and the clipping indicates some overload in the red colour channel → too bright.
Similar to when taking a photo from an object with a brigthly lit, predominant colour.
There also might be oversaturation, but there is neither a gamut warning nor a softproof capability
– if not introduced ‘secretly’.
Did some experiments with my ColorChecker and adjusted the raw-file’s (black &) white point
with the Tone curve, just shy of the clipping warning.
Export as 16bit TIFF-file w/ AdobeRGB colour space didn’t show clipping
inspite of the histogram moving slighty when compared to the adjusted raw-file.
Export as 16bit TIFF-file w/ sRGB colour space showed some clipping (as your example)
and a slightly expanded histogram, ‘touching’ the (black &) white point.
To solve that ‘issue’, I just took down the Tone curve by 1 point (255 → 254).
.
BTW, all exports were done with monitor set to AdobeRGB as well as sRGB colour space
(changed custom profile preset & restarted PL) → no display profiles involved !
note
When exporting a file, at present DxO uses the rendering intent perceptual.
– Say, you have a file in AdobeRGB colour space with some colours, which when exporting to sRGB colour space would land outside the target’s range. The perceptual rendering intent takes care of that and all (not overexposed) colours are moved into the target’s colour range, so that the perception of the present colour renditon is kept. – While simple and userfriendly, all colour values change to some degree, depending on how much ‘outlandish’ has to be stored in.
As already said, with a screen like yours the ‘best’ solution is to export in sRGB colour space
– and even better when your screen is properly set / calibrated.
Should you have a special project, you export as AdobeRGB and reduce to sRGB later.
→ The way back doesn’t work, as you don’t get the ‘extra’ colours back.
And do yourself a favour and try some of the mentioned test pics.
have fun, Wolfgang
addendum
The above test was done with “Protect saturated colors” ON.
After digging into that topic (and some understanding), I switched “Protect saturated colors” OFF and repeated the test (5) – but no change w/ the clipping indication, independent if the monitor was set to AdobeRGB or sRGB colour space → no display profiles involved !
Comparing the histograms of the equivalent output files, I could see the influence of that saturation protection switch, now leading to some ‘sligthly’ higher saturation values in the 3/4 tones (the bright side).
If you have the magic want active this slider starts to clime, from 0 til 100%, if the saturation of colors are passing the boundery’s of AdobeRGB. It "protect’s your image from clipping colors due desaturation of the full saturated colors in that image when you change contrast and such.
So in order to have saturation warning in AdobeRGB. I just pushed saturation until i saw the protection starting to be active. Just for the test not as editing skill.
3 and 4, i was earlier in a search about the color indication’s and dxo doesn’t have that specific explanation as FRV has,
It’s over brightning or over exposure of the rawfile and saturation of one or more of the channels. I think they used this:
About gamutwarning, it’s as far as i can detect pure based on there working colorspace AdobeRGB. And fixed on that. Soft proofing is adjustable between colorspaces.
So dxo has no softproofing.
I know and agree.
Which test pics?
The perceptual intent rendering give DxO the wiggling space to let the warnings just be done in AdobeRGB. Workingcolorspace. During export all colors are squeezed inside sRGB equally spread out giving a natural look.
My proposal is creating a easy userinterface with some softproofing capability’s.
A side by side image view one in working colorspace as always AdobeRGB and one depending on the choosen export colorspace.
Marking the oversaturated/clipped colors with colors and maybe the same kind as FRV has a channel separated underexposed and over exposed Percentage.
Peter.
I always have fun working in dxo. It’s a hobby 
I think what you see on your screen is in the color space defined in the preferences. In my case sRGB. So also the clipping warnings.
If you want to see the underlying pixel values of your clipping warnings, set the mouse pointer on a warning and switch with Ctrl-W or Ctrl-B. You’ll also see that clipping warnings for highlights start at a value of 254.
George
