Pages: [1] 2 3 ... 5   Go Down

Author Topic: DxO PhotoLab 2 working space tests  (Read 5371 times)

NAwlins_Contrarian

  • Full Member
  • ***
  • Offline Offline
  • Posts: 150
DxO PhotoLab 2 working space tests
« on: December 28, 2018, 12:43:24 am »

Contrary to popular perception / some reports, my recent tests suggest that DxO PhotoLab 2 appears to use an internal working color space significantly wider than Adobe RGB—but apparently it is not ProPhoto RGB. Also, even though older DxO software let you export images in ProPhoto RGB (if you separately installed that profile, downloadable at http://www.color.org/chardata/rgb/rommrgb.xalter), PhotoLab 2 gave me an odd error when I tried to export images in ProPhoto RGB. PhotoLab 2 did allow me to export in Wide Gamut RGB, which differs from, but is nearly as large as, ProPhoto RGB.[FN 1]

My tentative practical conclusion is that PhotoLab 2 has an internal working space that is wide enough to not meaningfully limit normal photographic content, but apparently is not as wide as ProPhoto RGB, and can limit some content at the gamut extremes. Also, PhotoLab 2 generates an odd error when attempting to export in the official ProPhoto RGB profile, but the almost-as-large Wide Gamut RGB (which is not a native PhotoLab option, but may be used if installed on your system) may be used as an alternative.

I started with Bill Atkinson’s printer test file, for reference this one (clipped to sRGB for browser viewing):
[IMG 1]
which he has made freely available as a huge TIFF (IIRC, with some sort of L*a*b color representation) and exported it from Lightroom 6.14 as a 16-bit TIFF in ProPhoto RGB. Then I opened the ProPhoto RGB TIFF in PhotoLab, and made sure that all of the adjustment controls were turned off (not merely zeroed). Then I exported the image from PhotoLab as a 16-bit TIFF in Wide Gamut RGB (which is not natively a PhotoLab option, but PhotoLab ostensibly lets you use any profile on your system). When I tried to likewise export the image in ProPhoto RGB (likewise not natively a PhotoLab option, but installed on my system), and it gave me this error message:
[IMG 2]
So much for that!

I used Serif Affinity Photo 1.6.5 to make the actual comparisons. I opened the Lightroom-exported ProPhoto RGB TIFF, opened the PhotoLab-exported Wide Gamut RGB TIFF, converted the latter to ProPhoto RGB, inverted it, copied it, pasted it into the former as a new layer, changed the mode of dealing with the multiple layers from Normal to Add, flattened the image, and added a Threshold Adjustment. With the threshold set to 99%, I did not see any [EDIT: upon closer inspection, there are a few] black dots, which would indicate areas where the Lightroom ProPhoto RGB TIFF differed by 1% or more from the PhotoLab Wide Gamut RGB TIFF:
[IMG 3]
However, when I increased the threshold to 99.5%—which is near the limits of what an 8-bit printer driver could deliver[FN 2]—there were a few small areas of differences:
[IMG 4]

[Continued in next message so I can post more attachments.]

[FN 1] Compare among, e.g., https://en.wikipedia.org/wiki/Adobe_RGB_color_space#/media/File:CIExy1931_AdobeRGB.png, https://en.wikipedia.org/wiki/Wide-gamut_RGB_color_space#/media/File:CIExy1931_AdobeWGRGB.png, and https://en.wikipedia.org/wiki/ProPhoto_RGB_color_space#/media/File:CIExy1931_ProPhoto.svg.

[FN 2] The use of 8-bit precision means 256 possible values for each RGB channel. A change of 1 in 256 is a change of 0.39%, so a threshold of 99.61% should be right at the limit of 8-bit precision.
« Last Edit: December 28, 2018, 11:00:06 am by NAwlins_Contrarian »
Logged

NAwlins_Contrarian

  • Full Member
  • ***
  • Offline Offline
  • Posts: 150
Re: DxO PhotoLab 2 working space tests
« Reply #1 on: December 28, 2018, 12:47:29 am »

[Continued from previous message so I can post more images.]

How do I know it isn’t simply that the Atkinson test image has almost no content outside of Adobe RGB? Because when I did the same test but exported from PhotoLab in Adobe RGB (instead of Wide Gamut RGB), the resulting comparison showed much larger areas with differences of 1% or more:
[IMG 5]

But when the test image is deliberately chosen for extreme of gamut, there are some. I repeated the same test procedure with Andrew Rodney’s gamut test file (made available as a 16-bit TIFF in ProPhoto RGB), for reference this one (again in sRGB for browser viewing):
[IMG 6]

With the threshold set at 99%, there were significant areas that differed:
[IMG 7]
And even at 95%, there were differences:
[IMG 8]

[Continued to next / third message so I can post another image.]
Logged

NAwlins_Contrarian

  • Full Member
  • ***
  • Offline Offline
  • Posts: 150
Re: DxO PhotoLab 2 working space tests
« Reply #2 on: December 28, 2018, 12:49:33 am »

[Continued from second message.]

During my testing I found one other PhotoLab oddity / error: TIFFs exported from PhotoLab in any working space other than sRGB were read by Affinity Photo correctly, but TIFFs exported from PhotoLab in sRGB were read by Affinity Photo as untagged with a working space:
[IMG 9]
This was visually obvious, and easy to change with an Assign Profile.

So my tentative conclusions are that (1) PhotoLab 2 has an internal working space that is substantially wider than Adobe RGB, but is not ProPhoto RGB; (2) this difference will rarely be significant for practical purposes with normal pictorial content, but can be significant for a few images that really push the limits of gamut (assuming they are ultimately to be printed or displayed on a device that can output that extra gamut!); and (3) PhotoLab has some new (i.e., not in previous DxO products) problem or error with actually exporting in ProPhoto RGB for those who want to use that working space, but works fine with the almost-as-large (but less common) Wide Gamut RGB.
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 15746
    • http://www.digitaldog.net/
Re: DxO PhotoLab 2 working space tests
« Reply #3 on: December 28, 2018, 09:15:24 am »

Thanks for the testing and the report. I’ve downloaded a demo and may buy, it looks like a very nice product and I like the .DCP support in this version. The NR is quite impressive.
Logged
Andrew Rodney
Author “Color Management for Photographers"

NAwlins_Contrarian

  • Full Member
  • ***
  • Offline Offline
  • Posts: 150
Re: DxO PhotoLab 2 working space tests
« Reply #4 on: December 28, 2018, 11:13:11 pm »

After a further test, I now think that DxO PhotoLab 2.1 has an internal working space at least as wide as Lightroom's linear version of ProPhoto RGB. At this point the only real issue with DxO appears to be that it does not have a native option to export in ProPhoto RGB, it produces an error when I try to use the official ICC file of ProPhoto RGB, and so I'm forced to some other file for a very wide space, like Wide Gamut RGB or an unofficial variant of ProPhoto RGB (or else accept export in Adobe RGB).

At the suggestion of some posters in a parallel thread at DPR, I downloaded Elle Stone's home-built ICC profile that she claims is the same as ProPhoto RGB, but which she calls Large RGB 1.8 for fear of copyright issues.* As before, I opened in PhotoLab 2.1 the original Rodney gamut test file and the Lightroom-exported ProPhoto RGB Atkinson test file. I made sure all adjustments were turned off, then I exported each in Large RGB 1.8. As before, in Affinity Photo 1.6.5 I opened the original files, opened the DxO-exported versions, inverted the latter, copied it, pasted it into the former, changed the layer mode to Add, flattened the file, and added a Threshold adjustment layer.

First the Atkinson printer test page with a 99% threshold:
[IMG 10]
I don't see any black dots = differences of 1% or more; do you?

Even the much more stringent test of the Rodney gamut test file with 99.7% threshold appears to show no differences:
[IMG 11]
Again, I see no differences, even at 100%. Did I miss any?

This limited test appears to suggest that DxO PhotoLab 2's internal working space is at least as wide as Lightroom's (and also that Elle Stone's Large RGB 1.8 is at least equal to the official ProPhoto RGB).

* Her website has a page on this at https://ninedegreesbelow.com/photography/lcms-make-icc-profiles.html, the GitHub page where her files actually reside is https://github.com/ellelstone/elles_icc_profiles/tree/master/profiles, and the specific file is LargeRGB-elle-V2-g18.icc.

Logged

FranciscoDisilvestro

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1503
    • Frank Disilvestro
Re: DxO PhotoLab 2 working space tests
« Reply #5 on: December 28, 2018, 11:26:33 pm »

Hi,

I was curious about this issue, since I performed some tests back with DxO optics Pro 7 (this thread), and here are my conclusions, with support gamut graphs to support them, but first a couple of notes:

1)  I would like to note that I had no issues exporting images out of PhotoLab2 using ProPhoto.icm as the icc profile, and

2) It was not a "Popular perception", DxO support actually confirmed this in response to forum user Ligament

Quote
"Bonjour Ligament.

DxO Optics Pro uses Adobe RGB as its internal working color space.

As I pointed out in my previous email, you need 32-bit TIFFs for Prophoto color space. Adobe RGB is about right for 16-bit TIFFs and 16-bit TIFFs are far too small for Prophoto RGB. 32-bit TIFFs do not exist yet.

A Nikon D800E is about high resolution not about capturing huge color spaces.

Did you read and understand the article that I sent you?

Best Regards,

Andy"


My conclusions:

- Rendered images (as the Bill Atkinson's test image used by the OP). Photolab2 will use the image color space and you can export to Prophoto.
- Raw Images: Process module uses AdobeRGB for histogram and presentation. If you render raw images to tiff or jpeg they will be AdobeRGB limited, even if you specify ProPhotoRGB
- How to work on raw images and ProphotoRGB? Perform only optical / noise reduction adjustments in Photolab2, export them as DNG* and colmplete the edits in LR / ACR

*The DNG produced by Photolab2 are "Linear DNG", not Raw, which means they have been demosaiced but not color space encoded. You can still apply the DCP profile of your choice in LR/ACR.


Support material:

Raw images: I started with a .NEF file with fairly saturated colors and exported as a tiff with Prophotorgb. I then opened the tiff in PS and converted the image to AdobeRGB. in the following image you may see that the histogram shown on Photolab2 in the process module is identical to the PS histogram of the image converted to AdobeRGB





I then applied a ridiculous amount of saturation to the image and exported it to tiff with Prophotorgb. I generated a 3d gamut view with Argyllcms and compared to the gamut of ProphotoRGB (Note: for the following graphs, the working space as ProphotoRGB is in wireframe and the image gamut is solid)





Then compared the gamut of AdobeRGB with that of ProphotoRGB and it is very similar to the previous graph, concluding that the tiff image in ProphotoRGB does not have any color outside of AdobeRGB





I then did a similar test using ACR, plotted the gamut and compared to Prophoto and can see an area in the reds where the colors of the image extend far than the limits of AdobeRGB. This is unachievable from a rendered image from Photolab2





After this test I was intrigued about the OP and the Bill Atkinson's test image, so I decided to test it. I downloaded the original, which is in Lab mode, converted to ProphotoRGB using PS and saved as tiff. I opened this tiff in Photolab2 and turned off any adjustments (as the OP) and exported as tiff in ProphotoRGB. I then plotted the gamut and compared to ProphotoRGB, where it is clear that the colors extend beyond AdobeRGB.





Finally I compared the gamuts of the original test image converted in ProphotoRGB in PS with the exported from Photolab, and they have the same gamut.




Regards

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 15746
    • http://www.digitaldog.net/
Re: DxO PhotoLab 2 working space tests
« Reply #6 on: December 28, 2018, 11:26:46 pm »

Stone has nothing to worry about because Adobe has allowed us to build these simple RGB Working Space profiles directly in Photoshop for nearly 20 years. In the Color Settings. You can even easily build a ProPhoto RGB Gamma 1.0 profile there by simply loading the original, clicking on Edit RGB and altering the gamma, save out the profile, name it.
Logged
Andrew Rodney
Author “Color Management for Photographers"

NAwlins_Contrarian

  • Full Member
  • ***
  • Offline Offline
  • Posts: 150
Re: DxO PhotoLab 2 working space tests
« Reply #7 on: December 29, 2018, 12:52:43 am »

Frank, thanks for the extensive and interesting response. Going in order:

First, I had read your prior thread (about Optics Pro 6 and/or 7)--and also gotten similar responses from DxO about (as I recall) Optics Pro 10 or 11 Elite. I thought I'd posted about that somewhere, but can't find it at the moment.

Second, I take it what you are reporting here are all-new tests using PhotoLab 2?

Third, as a FWIW: "in the following image you may see that the histogram shown on Photolab2 in the process module is identical to the PS histogram of the image converted to AdobeRGB"
To me, although those look similar, they do not appear identical. E.g., in DxO (left) the second cyan spike almost hits the limit of the blue, but in ACR (right) it does not.

If I'm understanding correctly, you took a raw file that had very saturated colors, processed it in PhotoLab 2, further increased saturation there, exported it as a TIFF in ProPhoto RGB, and compared the gamut of that TIFF to the gamuts of Adobe RGB and ProPhoto RGB, finding that none of the colors exceeded the gamut of Adobe RGB?

If so, then that would appear to support the view that PhotoLab does not process raw files in a working space wider than Adobe RGB. But why would it handle just fine TIFFs in a wider space, and not convert them to Adobe RGB? Or if it doesn't need to convert TIFFs to Adobe RGB to process them, why does it limit raw conversions to Adobe RGB? That would seem an odd set of circumstances / software design choices.

Last and least, I'm glad to hear that you replicated my conclusion that PhotoLab 2 did not reduce the gamut of a ProPhoto RGB version of Atkinson's printer test image.

Thanks!
Logged

NAwlins_Contrarian

  • Full Member
  • ***
  • Offline Offline
  • Posts: 150
Re: DxO PhotoLab 2 working space tests
« Reply #8 on: December 29, 2018, 12:56:31 am »

Stone has nothing to worry about because Adobe has allowed us to build these simple RGB Working Space profiles directly in Photoshop for nearly 20 years. In the Color Settings. You can even easily build a ProPhoto RGB Gamma 1.0 profile there by simply loading the original, clicking on Edit RGB and altering the gamma, save out the profile, name it.

As I read it, her stated worry was about Kodak's intellectual property over the name ProPhoto RGB. She says the substance is the same, but the name is different.

Also, she is an open-source sort who evidently does not use Photoshop, and wrote (IIRC) a C++ program to build the ICC working space profiles. I admire her knowledge and resourcefulness even while questioning the value of so much effort for something already so widely available.

Now if I could just figure out why--evidently unlike Frank's experience--my copy of PhotoLab 2 will not play nicely with the official ProPhoto RGB file from the ICC ...
Logged

FranciscoDisilvestro

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1503
    • Frank Disilvestro
Re: DxO PhotoLab 2 working space tests
« Reply #9 on: December 29, 2018, 01:22:21 am »

Second, I take it what you are reporting here are all-new tests using PhotoLab 2?

Hi,

- Yes, What I am reporting here are results based on DxO Photolab 2

Third, as a FWIW: "in the following image you may see that the histogram shown on Photolab2 in the process module is identical to the PS histogram of the image converted to AdobeRGB"
To me, although those look similar, they do not appear identical. E.g., in DxO (left) the second cyan spike almost hits the limit of the blue, but in ACR (right) it does not.

I agree that they migh not be identical, but look in the attached image how different is the histogram in PS when the file is in ProPhotoRGB (as it was exported from DxO)

If I'm understanding correctly, you took a raw file that had very saturated colors, processed it in PhotoLab 2, further increased saturation there, exported it as a TIFF in ProPhoto RGB, and compared the gamut of that TIFF to the gamuts of Adobe RGB and ProPhoto RGB, finding that none of the colors exceeded the gamut of Adobe RGB?

If so, then that would appear to support the view that PhotoLab does not process raw files in a working space wider than Adobe RGB. But why would it handle just fine TIFFs in a wider space, and not convert them to Adobe RGB? Or if it doesn't need to convert TIFFs to Adobe RGB to process them, why does it limit raw conversions to Adobe RGB? That would seem an odd set of circumstances / software design choices.

That is what I can conclude from my tests. Previous versions of DxO Optics Pro (6 and below) were not color managed for rendered files (jpg & tif) and then they added it. I suppose that they have invested many hours and resources in the raw converter and profiles which were calibrated for AdobeRGB and it would cost a lot to change to ProPhotoRGB. When you consider rendered images, it is just a few mathematical transformations, but this is my wild guess.

NAwlins_Contrarian

  • Full Member
  • ***
  • Offline Offline
  • Posts: 150
Re: DxO PhotoLab 2 working space tests
« Reply #10 on: December 30, 2018, 10:50:47 am »

To address the facially odd but seemingly possible situation where DxO PhotoLab 2 may handle already-rendered (TIFF or JPEG) files in ProPhoto RGB just fine, but limit its own raw conversions to some smaller-gamut working space (Adobe RGB or other), I did a quick look for some raw files that might tax the gamut, at least if really pushed. These may very well not be the ideal choices; I'll admit having spent more time yesterday watching college football than looking for raw files. For reference, reproduced below are small versions of the files I chose, as sRGB JPEGs for web viewing. One is of the basic X-Rite ColorChecker Passport [IMG 12] and  the other is of some tulips [IMG 13] (especially because glancing at gamut plots suggested that red might be the easiest area to push color outside of Adobe RGB). Basically, I opened each raw file in PhotoLab 2.1, dialed in my usual basic starting settings, then pushed the Vibrancy and Saturation sliders to maximum. Then I exported each file twice, both times as a 16-bit TIFF, once in Elle Stone's Large RGB (evidently the same as ProPhoto RGB--see above about that issue) and once in Adobe RGB. Then in Affinity Photo 1.6.5, I opened each pair of TIFFs, converted each to ProPhoto RGB (using the official ICC file), inverted the file that had started in Large RGB, copied it, pasted it as a layer over the other version, changed the layer mode to Add, flattened the file, and added a threshold adjustment layer with a 99% threshold. The ColorChecker comparison [IMG 14] showed some differences (black areas), but not in saturated colors, instead in the deep shadows. The tulips showed no differences, even after I increased the threshold to 99.6% [IMG 15].

No doubt that (1) there are other raw files that are better testing candidates, and (2) many of you are more expert at interpreting these conclusions than I am. But it concerns me that maybe DxO has made PhotoLab 2 work properly with TIFFs and JPEGs in wider color spaces, but its own limits raw conversion function to Adobe RGB.

One other thought: As I get ready to his Post, I wonder whether my leaving the "Protect saturated colors" control on, and on auto, may have been a methodological problem. In help says it "[r]ecovers details in very saturated colors." I figured that was about details, not about large, detail-less areas like the ColorChecker patches--but maybe I'm wrong.

Logged

NAwlins_Contrarian

  • Full Member
  • ***
  • Offline Offline
  • Posts: 150
Re: DxO PhotoLab 2 working space tests
« Reply #11 on: December 30, 2018, 11:19:59 pm »

And here's another test, of another image with saturation and vibrancy boosted to the maximum in DxO PhotoLab 2.1, again showing that there are detectable differences between PhotoLab-exported 16-bit TIFFs output in Elle Stone's version of ProPhoto RGB versus ones output in Adobe RGB--but again, the differences are all in the deep shadows, albeit mostly of areas that are relatively saturated colors. As before, for web viewing the reference image as an sRGB JPEG is posted as IMG 16. The same sort of threshold comparison is IMG 17. Note that although some differences showed up at lower thresholds like 99%, here is it 99.7% to fully show the extent of areas with small differences.

This shadows-only set of differences makes me wonder whether the differences are due mostly and maybe entirely to the profiles' respective gammas. I seem to recall that ProPhoto RGB's gamma is mostly 1.8 but linear over some range, while Adobe RGB's is IIRC 2.2 over the entire range.

ALSO: I took the prior two raw files in Lightroom, developed them in a basic / neutral way, then likewise maximized the saturation and vibrancy controls, the output them as 16-bit TIFFs in both ProPhoto RGB and Adobe RGB, then compared them. The results are posted as IMG 18 (the ColorChecker) and IMG 19 (the tulips). The ColorChecker appears to have exceeded Adobe RGB's gamut mostly in the orange patch, and then just a bit in other small areas; the tulips only exceeded Adobe RGB's gamut in the red-violet area at right, a bit red at the very top, and some dark green at bottom left. These relatively modest areas of difference between what Lightroom exported at ProPhoto RGB versus what it exported as Adobe RGB suggests to me that I probably need better test files--and more importantly, if Lightroom lets you increase saturation and vibrancy a little more than PhotoLab does, that might possibly explain why PhotoLab shows little to no difference between exports in Adobe RGB and those in the 'Large' / ProPhoto-ish RGB.

Last but not least: I tried with PhotoLab's Protect Saturated Colors control minimized, but it made very little if any difference.

And so the tests continue. If anyone wants to post a raw file that will readily push outside of Adobe RGB's gamut, that could be very helpful. Thanks for your comments and interest.
Logged

NAwlins_Contrarian

  • Full Member
  • ***
  • Offline Offline
  • Posts: 150
Re: DxO PhotoLab 2 working space tests
« Reply #12 on: January 04, 2019, 12:21:08 am »

A final (?) update:

(1) in a parallel thread, user sankos linked to a reply from today in DxO support from "wolf" a "DxO staff" member, who stated directly, "When you import the RAW file into PhotoLab, PhotoLab will apply demosaicking [sic] and convert the RGB values from the 'native color space of the camera' into AdobeRGB," and that although it is possible to export from PhotoLab in ProPhoto RGB, "The ProPhotoRGB export will only contain colors that already existed in AdobeRGB." See https://feedback.dxo.com/t/dxo-on-calibrated-screen-eizo/6114/25?u=sankos.

(2) My own tests continue to show that DxO exporting raw conversions as 16-bit TIFFs in Elle Stone's 'Large RGB' (supposedly the same as ProPhoto RGB) can produce color that is slightly different from exporting in Adobe RGB. The differences I have found in testing are mostly in dark blues and dark purples, in some oranges, and a little in reds. As an example, this image (clipped to an sRGB JPEG for web browser viewing), IMG 20, shows these differences between DxO exports in the different color spaces at the just-detectable-at-8-bit-precision level (threshold of 99.6%) shown by black areas in IMG 21. Obviously the source image has some slightly unnatural-colored clothing, lit in part by the plasma ball, and then with saturation and vibrancy maxed out for testing. But note the changes in the shadowed areas of his dark blue shorts, and also a little in the darkest parts of her red headband.

And for my own personal use and conclusions, I will continue to use PhotoLab because I think this limitation is minor compared to the product's considerable advantages, but I think users need to continue to hammer on DxO to lift this limitation. In fact, given modern computing power and memory, I think all serious image editing software ought to use an internal working space even wider that ProPhoto RGB, one wide enough to hold all colors visible to humans--even the ones that are not printable and/or monitor-viewable today, but may be in the future.
Logged

Jack Hogan

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 795
    • Hikes -more than strolls- with my dog
Re: DxO PhotoLab 2 working space tests
« Reply #13 on: January 07, 2019, 10:05:35 am »

I am sure that most people here know that working color space/gamut is immaterial if the data is floating point, limitations only come in at lower bit depths.  Jim Kasson did a number of tests a few years ago where he showed that cycling back and forth 100 times between color spaces at 15/16 bits induces aggregate color errors of the order of 1/10 of a deltaE.  In other words don't worry, be happy.  And stay away from 8 bits.

Jack
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 15746
    • http://www.digitaldog.net/
Re: DxO PhotoLab 2 working space tests
« Reply #14 on: January 07, 2019, 12:29:49 pm »

I am sure that most people here know that working color space/gamut is immaterial if the data is floating point, limitations only come in at lower bit depths. 
I don't see how that is material; a processing color space that may clip captured 'colors' is the issue, not how the data it can't contain is or the bit depth. Bit depth and color gamut are utterly separate attributes.
Logged
Andrew Rodney
Author “Color Management for Photographers"

Jack Hogan

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 795
    • Hikes -more than strolls- with my dog
Re: DxO PhotoLab 2 working space tests
« Reply #15 on: January 07, 2019, 02:49:04 pm »

I don't see how that is material; a processing color space that may clip captured 'colors' is the issue, not how the data it can't contain is or the bit depth. Bit depth and color gamut are utterly separate attributes.

Hi Andrew,

It's material because if one works in floating point one can retain all data, clipped, negative or otherwise.  And, staying linear for simplicity, one can go back and forth 100 (thousand) times from, say, sRGB to ProPhoto to Lab to LCH to whatever without losing color information, so the working color space for a raw converter becomes effectively immaterial.

It does of course make sense to have the working space as large as that of the monitor one works with - so that one can at least see the colors changing when sliders are pushed - but since 99% of current monitors are Adobe RGB or smaller one can typically not get one's knickers in knots and rest easy whether one's raw converter works in ProPhoto or (gasp!) Adobe RGB under the hood. As you no doubt know ACR/LR does all color profiling in HSV space (colorimetric corrections, look tables, Color profiles etc.).  How large is HSV's color gamut? ;)

With a few provisos it turns out all of the above holds pretty well when working with 16/15 bit data from raw images, as Jim has demonstrated.

Jack
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 15746
    • http://www.digitaldog.net/
Re: DxO PhotoLab 2 working space tests
« Reply #16 on: January 07, 2019, 02:56:40 pm »

It's material because if one works in floating point one can retain all data, clipped, negative or otherwise. 
ONLY if the color space's gamut is sufficiently large to avoid clipping. Again, this has absolutely nothing to do with encoding or math. The color space is a container of a certain size. That's what's being discussed here**. You can have an sRGB sized container using any bit depth or using any math to define and process what fits inside it, it's still too small a color gamut to avoid clipping colors we can capture and then process.
You beautifully illustrated this yourself here:
https://www.dpreview.com/forums/post/59559609
How then does the bit depth or math used (floating point or otherwise) change this condition?
Now PRIOR to the data finding it's way into a container, sure, anything is possible. But this discussion is about the working space (I'd suggest processing color space) of a raw converter. That container has a gamut.
That 99% (or any other made up value) of displays have this or that gamut is moot. We're talking about processing data that may or may not end up on a monitor who's output gamut could very easily exceed the gamut of Adobe RGB (1998). If you don't have that data in the container, you can't output that data.

**
Contrary to popular perception / some reports, my recent tests suggest that DxO PhotoLab 2 appears to use an internal working color space significantly wider than Adobe RGB—but apparently it is not ProPhoto RGB.
Logged
Andrew Rodney
Author “Color Management for Photographers"

Jack Hogan

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 795
    • Hikes -more than strolls- with my dog
Re: DxO PhotoLab 2 working space tests
« Reply #17 on: January 07, 2019, 03:10:20 pm »

In fact, given modern computing power and memory, I think all serious image editing software ought to use an internal working space even wider that ProPhoto RGB, one wide enough to hold all colors visible to humans--even the ones that are not printable and/or monitor-viewable today, but may be in the future.

If you want easy subjects with chromaticities outside of Adobe RGB try lemons or oranges in the shade, see for instance Figure 7 here.

The concept of using a large raw conversion working space, say Pointer's, may be appealing but it is in my opinion premature.  What's the point of working on an image whose colors one cannot see?  Those never-seen out-of-gamut colors are just as likely to look weird on Rec2020 whenever output devices with that wide gamut will show up in the future - or on uncalibrated monitors today. 

My approach is that we already have the full color information in the raw file.  Get the best out of the file based on the gamut you can see now. For me that's Adobe RGB.  When and if you will have a wider gamut monitor, should you wish to produce a wider gamut version, render it then from raw again: you will at least be able to see what you are doing.

Of course that's just me, to each their own.

Jack
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 15746
    • http://www.digitaldog.net/
Re: DxO PhotoLab 2 working space tests
« Reply #18 on: January 07, 2019, 03:16:06 pm »

If you want easy subjects with chromaticities outside of Adobe RGB try lemons or oranges in the shade, see for instance Figure 7 here.

The concept of using a large raw conversion working space, say Pointer's, may be appealing but it is in my opinion premature.  What's the point of working on an image whose colors one cannot see?  Those never-seen out-of-gamut colors are just as likely to look weird on Rec2020 whenever output devices with that wide gamut will show up in the future - or on uncalibrated monitors today. 
Premature but then consider the history of (just alone) the ACR engine and Thomas Knoll's selection of ProPhoto RGB sized gamut. And the harm?
There are of course "colors" (device values) cameras can capture we can't see and colors we can see it can't capture. I can see no reason to work with a processing color space that can clip colors we can see and output today or in the future. Yes, there are chromaticities outside of Adobe RGB (1998) and that's why it's not a very good working space.
Short of going into Photoshop, making a document in ProPhoto RGB and specifically creating numbers that are not colors (G255/R0/B0), where and when would this present an issue?
Those colors shouldn't look 'weird' in a color managed application. G255/R0/B0 in ProPhoto doesn't.
Seems we're getting further off topic of the color gamut of the processing color space in Dx0....
Logged
Andrew Rodney
Author “Color Management for Photographers"

NAwlins_Contrarian

  • Full Member
  • ***
  • Offline Offline
  • Posts: 150
Re: DxO PhotoLab 2 working space tests
« Reply #19 on: January 10, 2019, 12:33:45 am »

[Sorry, been away a few days because I thought this thread had died out.]

Quote
I am sure that most people here know that working color space/gamut is immaterial if the data is floating point, limitations only come in at lower bit depths.

Perhaps this shows my ignorance, but I cannot see how the quoted statement is correct. The issue of integer versus floating point should make no difference to whether the working space effectively clips off or crushes down certain colors. It seems to me that the key issue for what I think you are getting at is whether the color values are 'unbounded'. In other words, does the system allow and retain representations greater and/or less than the maximums defined by the working color space? Normal 16-bit representations for red, green, and blue values go from 0 to 65536. What each RGB triplet set of values means is defined by the color space; what the RGB triplet of 57204, 3812, 25624 means differs (somewhat) depending on the color space--it may be a medium-bright red to somewhat purplish in all of them, but not the exact same color. But suppose the raw converter internally uses (to make the numbers not too large to write and read, only) 18 bits per channel, and represents and accounts for the range of -131072 to 131071. The extra range of those values would represent colors or in many cases quasi-'colors' outside the gamut of the working space (and maybe not visible). If you (1) retain enough data for image editing to well above the working color space's 'maximum' and well below its 'minimum' and (2) maintain enough mathematical precision (bit depth), until you export into some chosen color space, then how the internal working space defines colors doesn't matter. And whether that sufficient precision comes from using integer representations with more bits or floating point representations with enough bits does not matter. Floating point precision, like integer precision, depends on how many bits are used to represent the number.

I have actually read claims that DxO in fact uses internally an 'unbounded' version of Adobe RGB. If that were true, and the degree to which it is effectively unbounded were sufficient, then exporting DxO raw conversions in (for example) ProPhoto RGB would preserve colors outside of Adobe RGB. But DxO's representative appears to have disclaimed this, within the last week or two.

Quote
if one works in floating point one can retain all data, clipped, negative or otherwise.

As far as I know, no floating point calculation ever retains "all data". There are inevitable rounding and/or truncation errors. At some point they may be immaterial, and even well below the threshold of creating any difference in output even as, say, a 16-bit TIFF. But I bet that a 24-bit integer working space that allowed for negative values would probably be just fine, and an 8-bit floating point working space would often be inadequate.

Quote
If you want easy subjects with chromaticities outside of Adobe RGB try lemons or oranges in the shade.

Thanks, I really appreciate the suggestion. Indeed, my tests suggested that orange shadows were one of the places where Adobe RGB's gamut most quickly becomes insufficient. But my tests were pretty crude, and I am not confident in their value.

Quote
What's the point of working on an image whose colors one cannot see?

Putting aside the issue of one editing operation pushing a 'color' outside what we can see and then a subsequent editing operation pushing it back inside (making it visible), the point is that a working space capable of representing all of the colors that we can see (which ProPhoto RGB cannot) would be either much more mathematically complex than necessary or else would also be capable of representing 'colors' we can't see.

Also, just because the printer I have now cannot print a particular visible color doesn't mean that a decade from now I won't have a printer that can print that color. IMO there's no sense in throwing away information before we have to.

But hey, I could be wrong--by all means, please tell me what you think.
« Last Edit: January 10, 2019, 12:37:03 am by NAwlins_Contrarian »
Logged
Pages: [1] 2 3 ... 5   Go Up