The quote was written by dxo staff.
What he means to say ( i think) is that a WB change in edit room will be activate a CA correction adjustment which is done before the actual demosiacing to pixels.
Fwiw i just tried to add some backloop info which shows that working space effects some earlier made corrections in the first stage of raw to preview.
But yes maybe it’s good not to complicate the flowchart.
This backloop system prevent dxo to show in preview the full rendered included denoising image. Same with the 75% zoom and the CAcorrection and microcontrast kick in.
Too much processing power needed.
But it definitely will show you how an image with saturated colors will actually look when exported to disk (and the result then viewed on the same monitor - which is the typical case).
I recommend have Soft Proofing activated at all times … it does no “harm”.
Soft proofing contains two conversions: 1 to the soft proof gamut and then 1 to the monitors gamut. I think that’s essential to understand what’s going on. The oog colors are based on the first conversion and what you see is based on the second conversion. To me that’s an essential part of color management.
@George, sorry but I totally disagree. Doing the double conversion as you suggest would accomplish nothing as you will be back where you started with your monitor gamut.
Soft proofing converts your image from the Working Colour Space to the soft proof profile and displays it on your monitor. You may end up with out of gamut colors if the SP hasn’t is larger than your monitor gamut but the idea is to stimulate what it would looks like in the SP profile and there must be NO further conversions otherwise you will not be simulating the SP profile.
As an aside, soft proofing to a gamut larger than your monitor gamut cannot simulate what the final output will be using the SP profile.
Yep that’s the Detail part.
It are just calculated RGB values for one “pixel” the interpretation of those values are done in the color rendering which uses a selected colorrendering algoritm (camera profile or neutral or…) to map the values in the selected colorspace. (workingcolorspace
Same as the luminance part. (amount of brightnes applied)
By the aplication and the monitor driver.
Lots of things are having influence in how the color will be look/seen by the viewer, even your own eye’s.
See my post in the other link and the image from that book Soft Proofing - #26 by George.
That’s why you have also a monitor oog. That’s showing the oog colors due to the conversion from soft proof to monitor. The soft proof gamut shows the oog due to the conversion from working gamut to soft proof gamut. It’s all really part of the color management of pl and other programs.
From what I can see, the monitor OOG is from WCS (working color space) to Monitor gamut and the soft proof gamut is what you say, WCS => Soft Proof. I base this on setting my destination (soft proof) profile to sRGB and having a 97% sRGB calibrated monitor managed by an ICC profile (Not the same one as set in Soft Proofing which is a standard ICC reference profile) at the OS level. The two gamut warnings are nearly identical.
The working gamut image is converted to the soft proof gamut. That image is send to the monitor and gets its standard conversion to the monitor gamut.
The monitor oog warnings are only available with soft proof on. Well I thought so in 6.0. I don’t have it anymore maybe somebody with 6.0 can tell us.
A general comment on 'intents" and DxO PSCA. Firstly, the ICC profiles come in two basic types, Matrix (3x3) and LUT (lookup tables). Both are intended to describe the the conversion from one color space to another. In addition one can specify one of 4 intents: relative colorimetric, absolute colorimetric, perceptual and saturation. The RGB color working spaces (or reference spaces) editing software use are matrix based, that means you can’t use an ICC profile to achieve perceptual and saturation intents when going to another RGB matrix space, i.e. I specify sRGB as my output color space (or Adobe RGB or ProPhoto RGB or Wide Gamut RGB). I found this easy to understand graphic from the argyll cms here.
So, it seems to me that DxO PSCA is a way doing either or both of perceptual and saturation intents when converting between RGB (matrix) color spaces, which ordinarily would not occur.
And yes, the GUI’s of lots of image software allow you to select perceptual when converting between matrix color spaces, but it just ends up being colorimetric clipping.
During soft proofing there is NO conversion from SP profile to monitor profile, even in the diagram you provided so I don’t know where you get that false idea from.
Step 3 and 4.
There is always a conversion , otherwise you will see wrong colors. That’s just the idea of color management. A certain color with the pixel values rx,gx,bx in color gamut x is a different color in color gamut y. So the values has to be converted to ry,gy,by to show the equal color.
Conversion is done through the ‘profile connection space’. https://www.color.org/profile.xalter. Every gamut references to that color space.
It’s a bit tricky when we uses different names and wordings for different or same things and processes.
One often uses the wording conversion when doing a hard change from one space to another for a file.
What soft proofing and any other color space changes does is a transformation of the space matrix, luts or tone curves from one to another.
Photo-DKO
(Dirk Offringa, Windows 10, RX570, PL6E-VP3-FP6, Fujifilm shooter)
183
PL6 (nor PL5 for that matter) doesn’t do correct colormanagement. I use a wide gamut monitor, calibrated and profiled, and I see SUBSTANTIAL difference in color (the reds, what else) between Classic colorspace and Wide Gamut colorspace, EVEN if I’m in softproof-to-sRGB mode.
I shouldn’t see any SUBSTANTIAL differences by switching workspaces. They should translate to the output device’s gamut (using the monitor profile and a connection space) so that the rendering is globally similar. A workspace is invisible (unless it’s ridiculously small, smaller than sRGB). A bigger workspace is useful for smoother gradients, higher latitude for editing. It doesn’t change the output. On my system, it does. As is, I can’t rely on PL6’s previews.
Yes, it can be irritating. A wide gamut pic is handled differently in PL5 / PL6 CL than in PL6 WG.
In the first case everything is limited to AdobeRGB working color space and further processed from that ‘starting point’. – With PL6 WG there is no such limit, that is, any conversion has to take in account the wider color space … resulting in some colour differencies and also visible in softproof, which indeed mirrors the output. *)
Well the classic color space is smaller than the wide gamut space. So there’s a larger space and wider range of colors which are to be compressed into a smaller matrix with a perceptual rendering.
If the result would be identical would be worse.
That said - please post some photos to compare the two results - this does not mean that there’s not a bug in the management anyway.
I don’t think your assumption is quite correct. If you change the colour processing pipeline then you would expect to see differences in output. The legacy workspace used AdobeRGB and on opening the file there was an automatic conversion of the raw colour space into AdobeRGB. Further editing is then carried out and you output an image into your defined colour space using whatever rendering intent you choose. In WG you are starting from a different place and so would expect a different result.This is why Legacy is still available for backward compatibility.
1 Like
Photo-DKO
(Dirk Offringa, Windows 10, RX570, PL6E-VP3-FP6, Fujifilm shooter)
187
This is already a very long thread which I didn’t read in it’s entirety, since I noticed not everone participating uses a fully colormanaged wide gamut workflow, which makes everything very confusing.
I should not see colors that weren’t there in the first place when switching from Classic to Wide Gamut workspace. The Classic workplace was too small, but also had the same issue, and I have filed tickets with support over a year ago, with example files to download and step-by-step instructions how to reproduce the issue. I hoped (and at first believed) that PL6 had adressed this major issue, but unfortunately it’s even more confusing. We now have to empirically shift back colors manually were they belong, especially when using the film simulaltions from DxO.
I have the impression that the notion of “working color space” is wrongly interpreted here on the forum, and that many confuse it with the “outputdevice color space”, presuming that the working color space is something “real” which it isn’t.
You get correct colors in Lightroom or Photoshop anytime, whatever your screen profile is when using the Profoto colorspace. The only issues you get are slight shifts due do the remapping of OOG colors into the output device colorspace according to the intent method employed (relative, perceptual…). IF THE OUTPUT DEVICE SPACE IS SMALLER THAN WHAT THE IMAGE CONTAINS. In no case ever should we get coulours that are more saturated than what they were originally, or hue shifts. This is the case here. Colormanagement is not there to invent colors that weren’t there.
Also lots of confusing between “color space” and “profile”.
The diagram everyone is talking about misses the most important element of a colormanagment system which is the Profile Connection Space (PCS)
.
I’m not posting images here because I noticed that the forum software has issues with color rendering as well. It’s all a bit ridiculous for a company that has such a great reputation in color science. I can hardly believe it! But I will if asked.
