I doubt that if you had used PL5 and before, or the legacy colorspace in PL6, that any colors outside of the Adobe RGB colorspace have been exported, even if you selected ProPhoto RGB, as internally all colors have been restricted to Adobe RGB by Photolab. Whether the difference is visible in practice is another story.
3 Likes
Rendering back from AdobeRGB to prophoto does nothing to my knowledge.
Rendering doesn’t stretch everything to the edge of a colorspace if the source is smaller.
It would be like exporting a jpg image as 16-bit tiff.
…makes sense if that JPEG is the beginning and not the end…
1 Like
What my small test showed is that using WGCS as working space does help but you need to understand that sun and moon(clippingwarning) not quite work for you as good as Legacy is the Histogram setting.
To use those clipping and use them to get close to export’s colorspace it’s best to set it to legacy. (AdobeRGB.)
When your done editing switch to WGCS so the rendering intent( wgcs to jpegs export version) is only once when you export.
(i assume that export is done through working colorspace and not from rawcolorspace straight to export colorspace.)
Stil the advise to alway’s use softproofing before export is a bit of a riddle to me.
Rendering intent is rendering nicely all colors near full saturation bringing the jpeg image to it’s full contrasty view.
Maybe only for flowers suitable i donlt know yet.
Using softproof and tune down inside, no red warning, does flatteb the image alot.
Hi Peter …
The interesting point about that is; you’re making informed choices about whether or not to go with WG as your standard WCS … with good knowledge and understanding of color gamuts, soft proofing, etc
Whereas, the “Average-Joe” user is very unlikely to have that understanding … and, yet, for all newly encountered images, PLv6 will automatically set his/her WCS to Wide Gamut.
Before that’s fair to “innocent” users, I reckon DxO first needs to deal with issues such as;
Request/Suggestion: Fix to avoid being caught-out if NOT using Soft Proofing
John M
3 Likes
RAW development starts with the camera’s internal color gamut (the sensor). PhotoLab has to convert that RAW data to Adobe RGB if the Classic/Legacy WCS is used. Sometimes there’s very little lost in that step. Using DxO Wide Gamut leaves more room for processing saturated colors but that still ultimately has to be rendered correctly in the output. Between the Color Rendering palette and export options, PhotoLab provides some options for doing that more or less for you - and Soft Proofing lets you analyze the resulting transformation a bit. That’s all simple enough for me. Some understanding of color management is needed for RAW development, but as Joanna points out the presets in PL with FilmPack use a recipe that might be dependent on one working color space or the other.
And this is what I find most annoying. I am far from the “average Joe (or Janet)” and have been used to everything “just working” - to the point of producing stunning exhibition prints from the previously “limited” colour space. Why? because screens are not inherently wide gamut and neither is printing paper.
So, the question remains, why bother with wide gamut when the source (RAW file) is only usually AdobeRGB and the paper.
Here is a comparison of AdobeRGB (the larger grey space) and the Canon profile for Fotospeed Lustre paper that I use…
Because, the RAW file (from modern cameras) describes a color-space much wider than AdobeRGB.
The setting that we might assign in-camera applies only to the JPG created by the camera - it has no impact on the “raw” data that’s transferred from the camera’s sensor into the RAW file.
@KeithRJ has posted a link to an excellent article on all this (here) … At first glance, it seems quite dense - but it’s actually not too long and is a relatively easy read.
John M
I suppose my point was that the target, whether that be screen or paper is rarely larger than that, so what is the point of processing for larger, only to have to limit stuff for output?
2 Likes
Hi,
please take a look at the links of the post Using Lab Color in DXO
And I can see a little shift in colours on my sRGB Monitor when switch to wide gamut
But I also believe that it doesn’t change so much, for me is more important that the colours/tonality/brighness I see on screen will be nearest as possible to the colours I will get on paper…so I use soft proof
2 Likes
There is an easy fix.
Sun and moon are kind of softproofing tools.
What do we want?
1 a as wide as possible workingcolorspace of the demosiaced rawdata. (no loss of colordata by the first conversion.
2 a control over the colors in saturation and lumination which is
A) converted by monitor driver, icc, to show the virtual image for your eye’s so you can edit. (we want this as close as it should be looking when we export.)
B) the export colorspace and bithdepth and file container. Jpeg, tiff, dng.
So what would be sensible as gauges and viewing this data?
Example.
Multimeter. When i want to measure mA i set the multimeter to mA but then the meter can’t handle big numbers of Ampere. This is physics. In software this isn’t a restriction.
So why not the choice of having Wide Gamut as working space and a choice how the histogram displays the black point and whitepoint(left and right) and how the sun and moon react? (like the monitor out of gamut choice.)
Why?
Wel you are editing for a sRGB or AdobeRGB export mostly.
I assume that when you use Legacy the Rawdata conversion is realtime adjusting from camera colorspace when we work in the Legacy CS. (think we have virtual all colors of the raw file but the gauges are only showing the colors fitting in AdobeRGB.(the rest is out of gamut and activate SCP, sun and moon.
Thus very important question is:
Why do i need WideGamut if i am never use export bigger then AdobeRGB?
Edit: Adding, display P3 is Same size as AdobeRGB , so in the future this still stands.)
1 Like
Exactly. And, when you look at how much smaller than AdobeRGB the average paper profile is, the question gets even more insistent.
3 Likes
Did anybody watch the third linked video Tutorials zu Affinity Photo für Desktop-Computer from beginning to end 
He tells exact the same story.
No use to edit in a bigger colorspace then the supposed export size.
My test shows this bleeched image he tells about.
1 i edit colors inside WG. (so dxo renders all colors of the rawfile in WG or shows out of gamut warning with scpt, sun and moon and the histogram.)
2 when i just export in sRGB, dxo’s rendering intent convert this WG-image as they find suitable to jpeg sRGB. (same as v5 but then from WG.)
3 when i want control of this action i use softproofing. (turn it on and i see by red later which parts of the image will be touched by this rendering intent. Do nothing and just hit export same as 2 happens.
The problem start when you alter your image accoording to that red warning layer.!!
Desaturate in working space means your shifting the colorvalue distribution of the rawfile to work image. That’s why you images turn up pale.
By overruling the relative and perceptual compression and change the hole range of the color distribution your image has all color values inside but it’s not the captured color distribution any more.(that was based on the latent image of the rawfiles sensorcolorspace.)
So to put this is perspective:
Legacy: Sun moon, histogram and SCPT react on all colors out of gamut based on AdobeRGB. YOU are more in control of this out of gamut color section. Leave it outside Adobe or squeeze it inside by using the visiualisation of sun moon, histogram and SCPT.
Closer to your screen sRGB so much more what you see is what you get. Use monitor tab to see difference of AdobeRGB and your screen srgb gamut.
Wide gamut?
Sun and Moon and such are quite useless and blunt as gauges because export rendering intent is dealing with a much larger piece of the imagecolors when export is sRGB.
What’s the point in living in a house, only to have to end in a coffin?
The bigger space allows manipulations that could lead to lost colours in a smaller space.
4 Likes
This is the main question.
Do we?
Lets assume we have one conversion (demosiacing) from raw file to working file.
Yes then your correct.
But as we think we know dxo does realtime adjusting from the start file.(sensorcolorspace)
So changing highlight, shadow, tonality and WB does “work” with the complete colordata.
(see the SCPT reacting when you play with contrast and saruration.)
Turning down saturation shows that SCPT value gets less, so more colors outside the working space are usable inside.
That’s the first statement I believe…I think in my coffin I will have a lot of lost colours, maybe I will plan LED light inside 
2 Likes
mmmuaahh!
( just fell of my chair – and sorry to be disrespectful )
1 Like
Dear Peter,
I’ve watched the video 4 time and I unterstand it this way
it’s better to work in RGB 16 bit Format and with the colour profile ROMMRGB to take advantage of all the colours
Display has to be capable to show this colours
then develop your Photo
because not all devices are colour managed or colour space aware>
- exporting in ROMMRGB the color information could not be handled and the colours will look desaturated
- so the best is to export in sRGB