Luminous Landscape Forum
Raw & Post Processing, Printing => Colour Management => Topic started by: NAwlins_Contrarian 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 (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.
-
[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.]
-
[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.
-
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.
-
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 (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 (https://github.com/ellelstone/elles_icc_profiles/tree/master/profiles), and the specific file is LargeRGB-elle-V2-g18.icc.
-
Hi,
I was curious about this issue, since I performed some tests back with DxO optics Pro 7 (this thread (https://forum.luminous-landscape.com/index.php?topic=54284.msg442781#msg442781)), 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
"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
(https://www.frankdisilvestro.com.au/img/s/v-3/p3247366316-3.jpg)
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)
(https://www.frankdisilvestro.com.au/img/s/v-3/p3247366326-4.jpg)
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
(https://www.frankdisilvestro.com.au/img/s/v-3/p3247366317-4.jpg)
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
(https://www.frankdisilvestro.com.au/img/s/v-3/p3247366318-4.jpg)
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.
(https://www.frankdisilvestro.com.au/img/s/v-3/p3247366331-4.jpg)
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.
(https://www.frankdisilvestro.com.au/img/s/v-3/p3247366327-4.jpg)
Regards
-
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.
-
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!
-
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 ...
-
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.
-
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.
-
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.
-
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 (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.
-
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 (https://forum.luminous-landscape.com/index.php?topic=94169.0) 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
-
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.
-
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
-
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 (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.
-
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 (https://www.strollswithmydog.com/phase-one-iq3-100mp-trichromatic-linear-color-iii/).
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
-
If you want easy subjects with chromaticities outside of Adobe RGB try lemons or oranges in the shade, see for instance Figure 7 here (https://www.strollswithmydog.com/phase-one-iq3-100mp-trichromatic-linear-color-iii/).
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....
-
[Sorry, been away a few days because I thought this thread had died out.]
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.
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.
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.
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.
-
To be formal, when discussing color folks talk about 'spaces' often without realizing/remembering that the terminology is that of linear algebra. Conversion from one space to another is accomplished by multiplication by a 3x3 or 3x4 matrix. A neat insight into the process is understanding that the matrix in effect gives a different point of view of the same solid in 3D space. So it is always the same color 3D object but seen from different perspectives.
If we can shift the point of view of the captured raw data cube to that which gives us what we call an XYZ projection, and from there to sRGB's, we can just as easily shift the point of view back to XYZ's, then to Adobe RGB's, then to ProPhoto's, etc. indefinitely, without ever touching the raw data solid, which is what it is, what it was and what it will be. All captured 'colors' are present all of the time. They may be more or less squished or stretched but they are there nonetheless.
All these transformations are accomplished by floating point linear matrices that look like this. (http://www.brucelindbloom.com/Eqn_RGB_XYZ_Matrix.html) Because they are linear, they are 100% reversible. In other words, as long as you stick with floating point math, there will be no/zero/zilch practical penalty for moving between and/or working in any of these spaces. Limitations are only introduced when working with unsigned integers at lower bit depths (say 8 bits).
So given the fact that if one sticks with floating point one can effectively use any color space one wishes without any penalty of any kind whatsoever, what color space should one use in practice in such a case? What I do as a matter of course is to work with 14+ bit data and choose a color space that closely matches the output device that I am viewing the photo with while rendering, so that I will see what I am doing. My monitor does close to 100% Adobe RGB, so that's the working space I typically use*.
But that's me, to each their own of course.
Jack
* This doesn't stop me from using larger color spaces on some images that I want printed, although my experience is that in such cases more than one trip to the printer is often necessary before a satisfactory result is obtained.
-
((1/255)^2.2)x65535 = 0.3327...
Which tells us that 16bits are not enough to represent 8bit perceptual steps in 16bit linear space.
In this case we seem to need at least 2 more bits to discern the first step. If you subsequently want to allow out-of-gamut, you'd want two additional bits. One for negative values, one for overshoot. That's 20bits. If you then want to store intermediate values during multiplications (in registers for example), you'd need at least 40bits. That would be the absolute minimum required precision.
If you want to be able to discern a full 8bits in linear space for each step in 8bit perceptual space, it would require 28 and 56 bits. Doing the same for gamma 2.4 is left as an exercise to the reader.
Fortunately, these days everything is 64bit or higher, so the exercise is kind of moot but perhaps insightfull.
-
((1/255)^2.2)x65535 = 0.3327...
Which tells us that 16bits are not enough to represent 8bit perceptual steps in 16bit linear space.
In this case we seem to need at least 2 more bits to discern the first step. If you subsequently want to allow out-of-gamut, you'd want two additional bits. One for negative values, one for overshoot. That's 20bits. If you then want to store intermediate values during multiplications (in registers for example), you'd need at least 40bits. That would be the absolute minimum required precision.
If you want to be able to discern a full 8bits in linear space for each step in 8bit perceptual space, it would require 28 and 56 bits. Doing the same for gamma 2.4 is left as an exercise to the reader.
I am not sure I follow. Where do your comments fit in the following simplified sequence?
(0) scene -> (1) analog linear intensity -> (2) linear 14-bit raw -> (3) linear 16-bit RGB -> (4) gamma (1/2.2) 8-bit RGB -> (5) de-gamma (2.2) 8-bit linear intensity -> (6) analog linear intensity -> (7) eye
-
I am not sure I follow. Where do your comments fit in the following simplified sequence?
(0) scene -> (1) analog linear intensity -> (2) linear 14-bit raw -> (3) linear 16-bit RGB -> (4) gamma (1/2.2) 8-bit RGB -> (5) de-gamma (2.2) 8-bit linear intensity -> (6) analog linear intensity -> (7) eye
Between 3 and 4, especially where display is concerned, and in general colorspace conversions that require compression. (Out-of-gamut correction for example, or a smaller space stuffed in a larger space and vv.)
-
Going back OT on why a wide gamut color working space is useful, (and I've provided this elsewhere in the past):
One reason we need big RGB working spaces is that they are based on theoretical emissive devices (ProPhoto RGB being very theoretical when you look at what falls outside human vision). Necessary because of their simple and predicable shapes. So while there are many more colors that can be defined in something like ProPhoto RGB than you could possibly print, we have to deal with a significant disconnect between these simple shapes of RGB working space and the vastly more complex shapes of an output color space. Simple RGB working space matrix profiles when plotted 3 dimensionally illustrate that they reach their maximum Chroma at high luminance levels which makes sense since they are based on increased Chroma by the addition of more light. The opposite is seen with print (output) color spaces where this is accomplished by adding ink: a subtractive color model. One reason we need such big RGB working space like ProPhoto RGB is due to its simple size and to counter the disconnect between mapping to the output space without potentially clipping colors. There can be issues where very dark colors of intense Chroma (which do occur in nature and we can capture with many devices) don’t map properly with a smaller working space. Many of these darker colors fall outside Adobe RGB (1998). When you encode using a smaller color space, you clip the colors to the degree that smooth gradations become solid blobs in print, again due to the dissimilar shapes and differences in how the two spaces relate to luminance. I suspect this is why Adobe picked ProPhoto RGB primaries for the processing color space in their raw converters.
Shown here:
http://www.digitaldog.net/files/sRGBvsPro3DPlot_Granger.tif (http://www.digitaldog.net/files/sRGBvsPro3DPlot_Granger.tif)
-
(0) scene -> (1) analog linear intensity -> (2) linear 14-bit raw -> (3) linear 16-bit RGB -> (4) gamma (1/2.2) 8-bit RGB -> (5) de-gamma (2.2) 8-bit linear intensity -> (6) analog linear intensity -> (7) eye
Between 3 and 4, especially where display is concerned, and in general colorspace conversions that require compression. (Out-of-gamut correction for example, or a smaller space stuffed in a larger space and vv.)
I see, in that case I believe the first non-zero value in a 16-bit linear RGB space would correspond to
(1/65535)^(1/2.2)*255 = 1.65
in the same 8-bit gamma-encoded RGB space. Right?
Jack
-
I see, in that case I believe the first non-zero value in a 16-bit linear RGB space would correspond to
(1/65535)^(1/2.2)*255 = 1.65
in the same 8-bit gamma-encoded RGB space. Right?
Jack
Correct, where greyscale is concerned. May be aggrevated by: additional lut correction for display calibration, or, for example, smaller source space than destination space.
EDIT: or larger source space than destination space. (Camera profiles may have virtual primaries for example).
-
((1/255)^2.2)x65535 = 0.3327...
Which tells us that 16bits are not enough to represent 8bit perceptual steps in 16bit linear space.
It would be great if more people were aware of this. I have seen many discussion around bit depth in online forums where the participants don't have a clue of the difference between linear space and perceptual or gamma encoded.
Fortunately, these days everything is 64bit or higher, so the exercise is kind of moot but perhaps insightfull.
Are you sure current image editing software are using 64 bit for the math?
-
It would be great if more people were aware of this.
That would be unnecessary as such a situation does not typically occur with decent software thanks to the linear gamma toe used by well behaved color spaces and engines (including ACE).
-
Are you sure current image editing software are using 64 bit for the math?
None use 64-bit integer arithmetic that I know of. PS uses 8 bit unsigned and 16 bit signed, with a fair bit of FP thrown in here and there. Others here know these details better than I.
-
PS uses 8 bit unsigned and 16 bit signed, with a fair bit of FP thrown in here and there. Others here know the details better than I.
From: Marc Pawliger
Subject: RE: 16 bit and the info palette
Message:
The high-bit representation in Photoshop has always been "15 1" bits (32767 (which is the total number of values that can be represented by 15 bits of precision) 1). This requires 16 bits of data to represent is called "16 bit". It is not an arbitrary decision on how to display this data, it is displaying an exact representation of the exact data Photoshop is using, just as 0-255 is displayed for 8 bit files.
-
From: Marc Pawliger
Subject: RE: 16 bit and the info palette
Message:
The high-bit representation in Photoshop has always been "15 1" bits (32767 (which is the total number of values that can be represented by 15 bits of precision) 1). This requires 16 bits of data to represent is called "16 bit". It is not an arbitrary decision on how to display this data, it is displaying an exact representation of the exact data Photoshop is using, just as 0-255 is displayed for 8 bit files.
I'm pretty sure, and your quote from Marc is consistent with this, that the reason PS does this is that it allows 16 bit math using signed 16 bit ints. In the past this was much faster than floating point and there is a lot of really old, legacy code in PS. The loss of a bit using 15 instead of 16 bits (which would require unsigned like 8 bit RGB) has no material impact on color. In pretty much any colorspace the largest dE errors from the dropped bit would be under .02
-
((1/255)^2.2)x65535 = 0.3327...
Which tells us that 16bits are not enough to represent 8bit perceptual steps in 16bit linear space.
This would be true if RGB(1,1,1) was discernibly different from RGB(0,0,0). It's not. The L* difference between the two is .0046 and deltaE2000 is even lower at .003. It isn't perceptible and by a very large factor.
BTW, this is why some color spaces like sRGB have a linear ramp at the front. Pure gamma encoded spaces waste bits on the front end as they produce tiny changes. sRGB uses a gamma of 2.4 when past the linear ramp.
In this case we seem to need at least 2 more bits to discern the first step. If you subsequently want to allow out-of-gamut, you'd want two additional bits. One for negative values, one for overshoot. That's 20bits. If you then want to store intermediate values during multiplications (in registers for example), you'd need at least 40bits. That would be the absolute minimum required precision.
If you want to be able to discern a full 8bits in linear space for each step in 8bit perceptual space, it would require 28 and 56 bits. Doing the same for gamma 2.4 is left as an exercise to the reader.
Fortunately, these days everything is 64bit or higher, so the exercise is kind of moot but perhaps insightfull.
This just is not so.
-
This would be true if RGB(1,1,1) was discernibly different from RGB(0,0,0). It's not. The L* difference between the two is .0046 and deltaE2000 is even lower at .003. It isn't perceptible and by a very large factor.
The problem is like this:
16bit linear = 1 results in 8bit perceptual = 2
(2/255) = 0.78 which, considered as a delta E, is most definitely visible in a grayscale. You'd see posterisation in your blacks. For grayscale we used a maximum of delta E = 0.5 as limit, but a trained eye, I'm certain, would be able to notice trouble below that threshold since it results in structured errors. Dithering is necessary to overcome part of the problem, but then you obviously shouldn't map a lot of 16bit values into a single 8bit bucket first.
-
BTW, this is why some color spaces like sRGB have a linear ramp at the front. Pure gamma encoded spaces waste bits on the front end as they produce tiny changes. sRGB uses a gamma of 2.4 when past the linear ramp.
It's very important to understand that this is pure nonsense. The pure gamma encoding simply dictates a single precise number for the gamma. How the engine actually uses that number to do its conversions and whether they waste bits in incorrect lookup table implementations is entirely a fault of the engine, not of the space.
Adding actual lookup tables within the space definition to overcome incorrect computations under the hood of some engines, has just been a really bad workaround.
-
The problem is like this:
16bit linear = 1 results in 8bit perceptual = 2
It isn't clear exactl6y what you are saying. My interpretation is that you are saying that 1 (in 16 bit linear space) is about 2 in 8 bit RGB encoded with gamma=2.2. This is approximately right. But are they perceivably different? No.
Let's take the two cases, first a 16 bit linear space RGB of (1,1,1). The DeltaE1976 between RGB(0,0,0) and RGB(1,1,1) in 16 bit linear space is .0135. dE2000 is a bit smaller.
Now for the 2.2 gamma encoded 8 bit RGB space. The deltaE76 between RGB(0,0,0) and RGB(2,2,2) is .021. This is still an order of magnitude below your perceivability threshold of .5 dE.
Lastly, looking at the deltaE76 between RGB(1,1,1) in linear space, and it's converted cousin in gamma=2.2, 8 bit space we get a value of .008, so the impact of conversion at the low end is negligible.
(2/255) = 0.78 which, considered as a delta E, is most definitely visible in a grayscale. You'd see posterisation in your blacks. For grayscale we used a maximum of delta E = 0.5 as limit, but a trained eye, I'm certain, would be able to notice trouble below that threshold since it results in structured errors. Dithering is necessary to overcome part of the problem, but then you obviously shouldn't map a lot of 16bit values into a single 8bit bucket first.
.78 certainly isn't anywhere near representing a deltaE. What exactly do you mean by that?
-
It's very important to understand that this is pure nonsense. The pure gamma encoding simply dictates a single precise number for the gamma. How the engine actually uses that number to do its conversions and whether they waste bits in incorrect lookup table implementations is entirely a fault of the engine, not of the space.
Adding actual lookup tables within the space definition to overcome incorrect computations under the hood of some engines, has just been a really bad workaround.
Are you aware that the encoding algorithm for sRGB, unlike Adobe RGB, isn't a pure gamma function? I am not talking about whatever engine is calculating transforms, but the spec itself.
Here's why pure gamma 2.2 encoding wastes bits on the low side. And let's compare it to sRGB for grins. 8 bit RGB all.
Note the difference between L*=0 or L*=100, as appropriate, is exactly the deltaE1976
sRGB (1,1,1) L*=.27
sRGB(254,254,254) L*=99.65
AdobeRGB (1,1,1) L*=.0046
AdobeRGB (254,254,254) L*=99.67
You have to go all the way up to RGB(6,6,6) on gamma = 2.2 to get an L* of .24. Thus values between 1 and 6 effectively do nothing. The ramp on the front end of sRGB, which is in the sRGB specification, allows these to provide more meaningful steps and also allows the rest of the curve to be gamma=2.4 which is somewhat better perceptually than 2.2.
-
Indeed, sRGB is using a TRC, not a gamma curve. I don't know if any other 'common' RGB working spaces do this (certainly not ColorMatch RGB, Adobe RGB (1998) or ProPhoto RGB).
-
It isn't clear exactl6y what you are saying. My interpretation is that you are saying that 1 (in 16 bit linear space) is about 2 in 8 bit RGB encoded with gamma=2.2. This is approximately right. But are they perceivably different? No.
Let's take the two cases, first a 16 bit linear space RGB of (1,1,1). The DeltaE1976 between RGB(0,0,0) and RGB(1,1,1) in 16 bit linear space is .0135. dE2000 is a bit smaller.
Now for the 2.2 gamma encoded 8 bit RGB space. The deltaE76 between RGB(0,0,0) and RGB(2,2,2) is .021. This is still an order of magnitude below your perceivability threshold of .5 dE.
Lastly, looking at the deltaE76 between RGB(1,1,1) in linear space, and it's converted cousin in gamma=2.2, 8 bit space we get a value of .008, so the impact of conversion at the low end is negligible.
.78 certainly isn't anywhere near representing a deltaE. What exactly do you mean by that?
No, you can safely assume that the gamma 2.2 space is more or less perceptually uniform, since that is the exact idea behind gamma encoding. So, the first step in 8bit perceptual space = (2/255) = .78% thus about equivalent to a deltaE76 of .78
Please don't go overboard on the linear part of that L curve. First of all that RGB = 0 doesn't start in pure black, second that linear part was not about dark pixels in a sea of white for example.
All numbers aside: i've implemented a colormanagement engine for display purposes long ago which allowed adjustable out-of-gamut rendering. Digidog may remember, i've send him an example. I vaguely recall that too little bits gave visible posterisation up to the first 4 or 6 steps. And that's just allowing gamma 2.2, imagine allowing anything up to 3.0 or whatever photoshop allows one to save these days...
-
Are you aware that the encoding algorithm for sRGB, unlike Adobe RGB, isn't a pure gamma function? I am not talking about whatever engine is calculating transforms, but the spec itself.
Here's why pure gamma 2.2 encoding wastes bits on the low side. And let's compare it to sRGB for grins. 8 bit RGB all.
Note the difference between L*=0 or L*=100, as appropriate, is exactly the deltaE1976
sRGB (1,1,1) L*=.27
sRGB(254,254,254) L*=99.65
AdobeRGB (1,1,1) L*=.0046
AdobeRGB (254,254,254) L*=99.67
You have to go all the way up to RGB(6,6,6) on gamma = 2.2 to get an L* of .24. Thus values between 1 and 6 effectively do nothing. The ramp on the front end of sRGB, which is in the sRGB specification, allows these to provide more meaningful steps and also allows the rest of the curve to be gamma=2.4 which is somewhat better perceptually than 2.2.
I don't quite understand how you get to your values. The first step in a gamma encoded space should be brighter than L since they don't have the flat bit like L has. (i.e. the derivative in 0 is infinite for gamma spaces, not so for L, therefore the deltaE should always be larger than the Y <-> L relation.)
-
Indeed, sRGB is using a TRC, not a gamma curve. I don't know if any other 'common' RGB working spaces do this (certainly not ColorMatch RGB, Adobe RGB (1998) or ProPhoto RGB).
Exactly, with the TRC and the flat start, they try to overcome the problem that the values would look like for example 0, 0, 0, 1, 1, 2, 3, 5 which in turn creates really funky inversions as well.
They simply shouldn't have gone there and just store the gamma value as per the directive and then let the engine create proper tables and, not unimportantly, proper inversions.
-
No, you can safely assume that the gamma 2.2 space is more or less perceptually uniform, since that is the exact idea behind gamma encoding. So, the first step in 8bit perceptual space = (2/255) = .78% thus about equivalent to a deltaE76 of .78
The first step is (1/255), not (2/255) though the latter roughly corresponds to a single step in 16 bit, linear RGB space.
No, you can safely assume that the gamma 2.2 space is more or less perceptually uniform
That's just not true. For one thing L* for RGB(1,1,1) or (2,2,2) is not anywhere near .78. Heck, it's not anywhere near .1
Please don't go overboard on the linear part of that L curve. First of all that RGB = 0 doesn't start in pure black, second that linear part was not about dark pixels in a sea of white for example.
Let's stick with the ICC math please. RGB=0 is Y=L*=0. That is black. That monitors can't show black unless they are turned off in a dark room is a rather different issue.
All numbers aside: i've implemented a colormanagement engine for display purposes long ago which allowed adjustable out-of-gamut rendering. Digidog may remember, i've send him an example. I vaguely recall that too little bits gave visible posterisation up to the first 4 or 6 steps. And that's just allowing gamma 2.2, imagine allowing anything up to 3.0 or whatever photoshop allows one to save these days...
Your point about seeing posterization in low luminance situations where the background is also low luminance is a good one. L* deltaE's are meaningful only when looking at "colors" against an L* background of approximately 50, similar to a neutral gray card. I darker environments one can see posterization at low L* values. Hence things like motion pictures with verly large dynamic ranges benefit from things like 16 bit (small floats) spearheaded by Industrial Light and Magic. In movies one has time to adapt to a much larger dynamic ranges and encoding in floats, even 16 bit floats, provides the require range while still eliminating posterization.
-
Exactly, with the TRC and the flat start, they try to overcome the problem that the values would look like for example 0, 0, 0, 1, 1, 2, 3, 5 which in turn creates really funky inversions as well.
They simply shouldn't have gone there and just store the gamma value as per the directive and then let the engine create proper tables and, not unimportantly, proper inversions.
Kind of depends which sRGB you (and Doug) are referring to!
https://ninedegreesbelow.com/photography/srgb-profile-comparison.html (https://ninedegreesbelow.com/photography/srgb-profile-comparison.html)
The author agrees with you:
From a programming point of view, it would be nice if the sRGB TRC just vanished, to be replaced with the much more tractable gamma=2.2 TRC. From a pragmatic point of view, that is not going to happen any time soon, if ever — there are just too many untagged sRGB images floating around that require the sRGB profile TRC, not to mention legacy software and all the cameras that produce sRGB jpegs.
-
I don't quite understand how you get to your values. The first step in a gamma encoded space should be brighter than L since they don't have the flat bit like L has. (i.e. the derivative in 0 is infinite for gamma spaces, not so for L, therefore the deltaE should always be larger than the Y <-> L relation.)
Perhaps we can resolve this if you specific two specific values in a defined colorspace (e.g., Adobe RGB 8 bit), then calculate the Y value and L* value from that. I've done that above (except for the Y) , what are your numbers?
I get my values from two places which I've crosschecked. MATLAB and http://www.brucelindbloom.com/ The formulas are also in the specs at www.color.org.
-
Kind of depends which sRGB you (and Doug) are referring to!
https://ninedegreesbelow.com/photography/srgb-profile-comparison.html (https://ninedegreesbelow.com/photography/srgb-profile-comparison.html)
The author agrees with you:
From a programming point of view, it would be nice if the sRGB TRC just vanished, to be replaced with the much more tractable gamma=2.2 TRC. From a pragmatic point of view, that is not going to happen any time soon, if ever — there are just too many untagged sRGB images floating around that require the sRGB profile TRC, not to mention legacy software and all the cameras that produce sRGB jpegs.
I quite agree. The changeover from a linear ramp to gamma 2.4 on the standard IEC sRGB (the one Adobe uses) is only of minimal value in 8 bits and provides nothing of value in larger bit spaces. Also, sRGB suffers from shifts in chromaticity when scaled. For instance RGB (10,75,100) will have a different chromaticity than RGB (20,150,200) while Adobe RGB and ProPhoto RGB will not see any shifts in chromaticity.
-
Indeed, sRGB is using a TRC, not a gamma curve. I don't know if any other 'common' RGB working spaces do this (certainly not ColorMatch RGB, Adobe RGB (1998) or ProPhoto RGB).
at least:
ProPhoto
ROMMRGB
RIMMRGB
scRGB
EBU3213
SMPTERP145
Rec709
Rec2020
-
No, you can safely assume that the gamma 2.2 space is more or less perceptually uniform, since that is the exact idea behind gamma encoding. So, the first step in 8bit perceptual space = (2/255) = .78% thus about equivalent to a deltaE76 of .78
"More or less" is right. In practice intraocular glare and adaptation makes it not such a neat mathematical property.
-
The problem with a simple gamma function is that it is 'not invertible at the origin'. This causes a whole lot of practical issues including the massive amplification of small intensity values, aka noise, exactly where one does not want it, in the darkest portions of an image (take the derivative of the function to understand why). Hence the practical need for a linear toe in sRGB and any other non-noise-adding color space (Melissa anyone?).
Thankfully for those of us who do not like color spaces that add noise, PS does introduce linear toes in Color Space gammas whether they specify them or not, through ACE (the previously mentioned Adobe Color Engine). Yes, including in Adobe RGB.
Jack
-
at least:
ProPhoto
ROMMRGB
RIMMRGB
scRGB
EBU3213
SMPTERP145
Rec709
Rec2020
TRC or true gamma?
-
The problem with a simple gamma function is that it is 'not invertible at the origin'. This causes a whole lot of practical issues including the massive amplification of small intensity values, aka noise, exactly where one does not want it, in the darkest portions of an image (take the derivative of the function to understand why). Hence the practical need for a linear toe in sRGB and any other non-noise-adding color space (Melissa anyone?).
Thankfully for those of us who do not like color spaces that add noise, PS does introduce linear toes in Color Space gammas whether they specify them or not, through ACE (the previously mentioned Adobe Color Engine). Yes, including in Adobe RGB.
Jack
Color spaces that add noise? I'm lost. ;D Got visually image examples?
If you are referring to Melissa RGB, it is only used for the Histogram and RGB readouts.
-
The problem with a simple gamma function is that it is 'not invertible at the origin'. This causes a whole lot of practical issues including the massive amplification of small intensity values, aka noise, exactly where one does not want it, in the darkest portions of an image (take the derivative of the function to understand why). Hence the practical need for a linear toe in sRGB and any other non-noise-adding color space (Melissa anyone?).
A pure gamma function isn't technically invertible at 0 since the function x^(-2.2) isn't defined for negative or zero values. Thus, (x^2.2)^(-2.2) isn't defined. However, it is defined if one takes the limit and that value, for x=0, is 0. This is how Adobe converts from a 2.2 gamma to 1.0 gamma.
Thankfully for those of us who do not like color spaces that add noise, PS does introduce linear toes in Color Space gammas whether they specify them or not, through ACE (the previously mentioned Adobe Color Engine). Yes, including in Adobe RGB.
Adobe ACE does not introduce a toe in pure gamma colorspaces. Easily tested in Photoshop. Zero and low values convert as expected (zero converts to zero) from one colorspace to another with no evidence of a toe outside of the sRGB.
-
Here's a graph of delta E 2000's for 8 bit colorspaces. Included are sRGB, Adobe RGB, ProPhoto RGB, and a linear RGB space.
Gamma of the colorspaces:
sRGB: linear with gamma=2.4
Adobe RGB: 2.2
ProPhoto RGB 1.8
Linear RGB: 1.0
The graph shows the Delta E 2000 for adjacent steps in the 8 bit colorspaces from (0,0,0),(1,1,1),...(255,255,255). For 16 bit images just divide the Delta E's by 256, or 128 in the case of Adobe Photoshop which scales 16 bit images to 15 bits.
There simply is no issue where accuracy at low luminance needs more than 15/16 bits and 8 bits is right at the threshold of observability except for the linear gamma which gets pretty bad at low luminance.
sRGB does a decent job in 8 bits. At least for the tone curve. sRGB's big weakness is it's really narrow gamut. Something that's well explored by many. In particular, Andrew Rodney has extensively gone into sRGB's printing.
All of these, even with Adobe's 15 bit limit, work fine in "16" bit RGB spaces. Even linear, gamma=1.0 spaces which have a max dE00 of .023.
-
A pure gamma function isn't technically invertible at 0 since the function x^(-2.2) isn't defined for negative or zero values. Thus, (x^2.2)^(-2.2) isn't defined. However, it is defined if one takes the limit and that value, for x=0, is 0. This is how Adobe converts from a 2.2 gamma to 1.0 gamma.
Adobe ACE does not introduce a toe in pure gamma colorspaces. Easily tested in Photoshop. Zero and low values convert as expected (zero converts to zero) from one colorspace to another with no evidence of a toe outside of the sRGB.
This info came from a discussion with Adobe cognoscenti quite a while ago. I am currently on the road, I'll see if I find it once I get back in a few days. In the meantime one could try switching a dark noisy image patch back and forth from sRGB to Adobe RGB to linear gamma a number of times in Matlab vs PS ACE and see if one gets the same result.
Jack
-
This info came from a discussion with Adobe cognoscenti quite a while ago. I am currently on the road, I'll see if I find it once I get back in a few days. In the meantime one could try switching a dark noisy image patch back and forth from sRGB to Adobe RGB to linear gamma a number of times in Matlab vs PS ACE and see if one gets the same result.
Jack
No problem. For anyone interested in experimenting, I've attached an untagged 16 bit tiff image that contains all 65536 neutral values (R=G=B). When loaded into Photoshop, half the values are tossed as it rounds to 32768 values when converting to 15 bits. If you save it, it will save rounded with 32768 values.
Not all Adobe cognoscenti are equal. :)
-
Back in the day (2006-ish) Photoshop allowed asymmetric CMM conversions from which I could derive the following:
ACE was well behaved (high precision)
The Apple CMM was not (low precision)
ACE properly inverted high precision conversions from another CMM, and certainly didn't resort to flatlining the luts.
I have no idea what's state of the art in today's world with everything native 64bit and some of it handed to the graphics card at 128bit, although handing this stuff down to the graphics card black box is prone to even more variations. The whole thing started all over with the introduction of Tablets, and now Apple introducing yet another colorspace while they don't exactly dictate standards. I pretty much stopped caring to be honest, which, I have to admit, is a bit of a defeat considering I spend longer than I care to remember in digital premedia and colorimaging. I guess it all turned out to be merely a long winded path of realisation toward the idea that the artistic content of your images is just infinitely more important than the technical merits of its representation. You can be ever so meticulous in preparing your images for future consumption, only to find that your superseded by an iphone dominated world with continuously deteriorating standards of quality.
(No, I have nothing against the next generation, I have something against the planned obsolescence throw away society and its corresponding reduction to mediocrity.)
-
Back in the day (2006-ish) Photoshop allowed asymmetric CMM conversions from which I could derive the following:
ACE was well behaved (high precision)
The Apple CMM was not (low precision)
I agree ACE has been and remains well behaved on my Win 10 machine. Microsoft's ICM is not. It can significantly shift colors just doing a sRGB->Adobe RGB and back. It also has an old school view of Absolute Col. conversions using matrix profiles and doesn't adapt to D50. The ICC was ambiguous at the time ICM was created and clarified their intent over 15 years ago but Microsoft hasn't adapted.
ACE properly inverted high precision conversions from another CMM, and certainly didn't resort to flatlining the luts.
I have no idea what's state of the art in today's world with everything native 64bit and some of it handed to the graphics card at 128bit, although handing this stuff down to the graphics card black box is prone to even more variations. The whole thing started all over with the introduction of Tablets, and now Apple introducing yet another colorspace while they don't exactly dictate standards. I pretty much stopped caring to be honest, which, I have to admit, is a bit of a defeat considering I spend longer than I care to remember in digital premedia and colorimaging. I guess it all turned out to be merely a long winded path of realisation toward the idea that the artistic content of your images is just infinitely more important than the technical merits of its representation. You can be ever so meticulous in preparing your images for future consumption, only to find that your superseded by an iphone dominated world with continuously deteriorating standards of quality.
(No, I have nothing against the next generation, I have something against the planned obsolescence throw away society and its corresponding reduction to mediocrity.)
It has been always so. And it's a good thing.
-
I agree ACE has been and remains well behaved on my Win 10 machine. Microsoft's ICM is not.
Microsoft ICM is rubbish.
-
Microsoft ICM is rubbish.
You're too kind!
-
TRC or true gamma?
The specs say straight line + power curve for all those spaces.
-
The specs say straight line + power curve for all those spaces.
IOW a simple gamma curve, as such, is sRGB the only WS without?
-
The specs say straight line + power curve for all those spaces.
What "specs?"
ICC profiles (V2) allow for 3 variations:
1. A linear (gamma=1)
2. A pure gamma curve (no toe) which is what Adobe RGB (1998) uses
3. A TRC, which is a set of points that are interpolated, this is used by sRGB: IEC 61966-2-1:1999
The latter has a linear ramp followed by a roughly, gamma = 2.4. The overall effect is similar to gamma=2.2.
Adobe RGB (1998) uses a pure gamma curve of 2.199.
-
What "specs?"
ICC profiles (V2) allow for 3 variations:
1. A linear (gamma=1)
2. A pure gamma curve (no toe) which is what Adobe RGB (1998) uses
3. A TRC, which is a set of points that are interpolated, this is used by sRGB: IEC 61966-2-1:1999
The latter has a linear ramp followed by a roughly, gamma = 2.4. The overall effect is similar to gamma=2.2.
Adobe RGB (1998) uses a pure gamma curve of 2.199.
Specs are specs, practice is practice. Graeme knows, he is one of the cognoscenti.
Back home on Wednesday, in due time I'll be able to fire up PS/Matlab and see what comes out of it then
Jack
-
Specs are specs, practice is practice. Graeme knows, he is one of the cognoscenti.
Yes, Graeme certainly is. He has done great work. He also corrected an error I made that I was quite certain about. I wrongly believed the I1Pro 2 spectro read with a uV cut filter, then a uV LED and generated M0,M1,M2 profiles from those two measurements. This is the way i1iSis does things. But not the I1Pro 2 as Graeme pointed out, quite correctly, that it measured M0 (no uV cut), then did a uV LED measurement and generated the M's from those.
I found what may be the source for Adobe RGB (1998) generating a linear ramp which merges into a gamma curve. It's in an Adobe PDF document titled "Adobe RGB (1998) Color Image Encoding" here:
https://www.adobe.com/digitalimag/pdfs/AdobeRGB1998.pdf
At then end of the colorspace description, is this in Annex C:
Annex C. Implementation notes (Informative)
Slope limits in a color converter
Many color converters and products impose slope limits on gamma curves found in the rTRC, gTRC, and bTRC tags of ICC profiles. For an arbitrary slope limit of x (where x < 1), the effective gamma curve as used in the color converter has a slope of x or greater. When used with the Adobe RGB (1998) ICC profile, the slope limit should not be greater than 1/32. A slope limit of 1/32 affects 8-bit integer values 1 to 14. At the time of writing, the Adobe color conversion engine, ACE, included with Adobe Photoshop and other products from Adobe Systems, imposes a slope limit of 1/32. The effective inverse transfer function for Adobe RGB (1998) when used with ACE thus becomes:
- see graphic equation in PDF - my one line equiv: max(pow(C,2.19921875), C/32) for C[0:1]
Note that the above slope limit is an implementation aspect, not an attribute of the Adobe RGB (1998) color space encoding. Different implementations may use different slope limits.
However, Adobe ACE in current versions of Photoshop do not do this. It's easy to test with the image posted above of all 64k 16 bit neutrals. Just assign Adobe RGB (1998) and convert to any linear RGB space using Photoshop's ACE. There is no slope limiting. Perhaps it did do this at the time the document was written. I've found no indication anyone has noticed that ACE doesn't now do what is stated in the pdf let alone when/if Adobe changed it.
Back home on Wednesday, in due time I'll be able to fire up PS/Matlab and see what comes out of it then
Jack
Jack,
I'm interested to see what background info you can dig up. Test my posted image and whatever else you come up with.
Should be interesting. I've found nothing on the web referring to Annex C and any discussion of what Adobe's ACE actually does in that regard. It may be that other imaging apps implement the discussed slope limiting, I have no idea, but ACE does not. I find that rather odd.
-
What "specs?"
The relevant colorspace specifications for all those spaces (i.e. the definitions I used when creating ICC profiles for them.)
I found what may be the source for Adobe RGB (1998) generating a linear ramp which merges into a gamma curve. It's in an Adobe PDF document titled "Adobe RGB (1998) Color Image Encoding" here:
I'd forgotten that Annex, probably because it applies to their CMM not the profile. Not mathematically the same as the usual straight line + power curve either, since a slope limit generates a smoothness discontinuity (i.e. the power curve is not offset).
-
The relevant colorspace specifications for all those spaces (i.e. the definitions I used when creating ICC profiles for them.)
Are you saying you created Adobe RGB (1998)? Then why is it using a pure gamma curve and Adobe ACE is not implementing a slope limit contrary to their spec's Annex C? Is Adobe now doing it wrong?
I'd forgotten that Annex, probably because it applies to their CMM not the profile. Not mathematically the same as the usual straight line + power curve either, since a slope limit generates a smoothness discontinuity (i.e. the power curve is not offset).
Well, since Photoshop's ACE neither currently implements Annex C nor does the Adobe RGB (1998) profile they install, which has a pure gamma of 2.19921875 without a ramp, is this something you are doing elsewhere?
Edit:
I looked at the rec2020 profile you made and see that it uses a TRC with a linear ramp, so I presume your other profiles do as well. Any idea why Adobe doesn't do that? Also ProPhoto RGB uses a pure gamma and ACE doesn't modify it. I assume some apps use ramps while others (Adobe) don't. Is that your understanding?
-
Any idea why Adobe doesn't do that? Also ProPhoto RGB uses a pure gamma and ACE doesn't modify it. I assume some apps use ramps while others (Adobe) don't. Is that your understanding?
I wouldn't assume PS 'doesn't do that'. It used to do it and I would be surprised if it didn't do it any more. There are good reasons why they do it.
The test is not PS to PS. ACE is well behaved, so if it does do whatever it probably does it throughout. The test is ACE vs a literal interpretation of the spec (e.g. Microsoft ICM or similar).
Jack
-
I wouldn't assume PS 'doesn't do that'. It used to do it and I would be surprised if it didn't do it any more. There are good reasons why they do it.
The test is not PS to PS. ACE is well behaved, so if it does do whatever it probably does it throughout. The test is ACE vs a literal interpretation of the spec (e.g. Microsoft ICM or similar).
Jack
Microsoft ICM is not as well behaved as ACE and produces larger errors. Particularly with sRGB conversions.
A good approach is to compare a linear to Adobe RGB (or inverse) conversion in ACE to the same conversion in Matlab or any other good math package using a pure, floating point gamma and the two match within 33 parts per million. There is no ramp and the miniscule differences are because ACE uses scaled fix point, 16 bit (15 bits and a sign bit) math while Matlab uses a double precision pure gamma.
-
Are you saying you created Adobe RGB (1998)?
I'm saying I created an ICC profile ("ClayRGB1998.icm") to implement Adobe RGB (1998) based on the Adobe specification.
Then why is it using a pure gamma curve and Adobe ACE is not implementing a slope limit contrary to their spec's Annex C? Is Adobe now doing it wrong?
No idea - you'd probably have to ask Chris Cox of Adobe that question.
Edit:
I looked at the rec2020 profile you made and see that it uses a TRC with a linear ramp, so I presume your other profiles do as well. Any idea why Adobe doesn't do that?
No - I haven't heard anything about how Adobe RGB(1998) came to be.
Also ProPhoto RGB uses a pure gamma and ACE doesn't modify it.
ProPhoto RGB implemented according to the specifications should have power curve with straight line slope limit. It is based on ROMM RGB (http://www.color.org/rommrgb.pdf), and the spec says:
If Rr, Gr, or Br are less than 0.001953
R = Rr*16
G = Gr*16
B = Br*16
If Rr, Gr, or Br are greater than or equal to 0.001953
R = Rr1/1.8
G = Gr1/1.8
B = Br1/1.8
I assume some apps use ramps while others (Adobe) don't. Is that your understanding?
All I know is that (mainly from testing Marti did some time ago, as well as my own testing) that Adobe ACE, littleCMS and ArgyllCMS are in very good agreement in the interpretation of ICC profiles, while other CMM (i.e. Microsoft) are less reliable. I'm not sure about Apples CMM.
-
I'm saying I created an ICC profile ("ClayRGB1998.icm") to implement Adobe RGB (1998) based on the Adobe specification.No idea - you'd probably have to ask Chris Cox of Adobe that question.No - I haven't heard anything about how Adobe RGB(1998) came to be.ProPhoto RGB implemented according to the specifications should have power curve with straight line slope limit. It is based on ROMM RGB (http://www.color.org/rommrgb.pdf), and the spec says:
If Rr, Gr, or Br are less than 0.001953
R = Rr*16
G = Gr*16
B = Br*16
If Rr, Gr, or Br are greater than or equal to 0.001953
R = Rr1/1.8
G = Gr1/1.8
B = Br1/1.8
All I know is that (mainly from testing Marti did some time ago, as well as my own testing) that Adobe ACE, littleCMS and ArgyllCMS are in very good agreement in the interpretation of ICC profiles, while other CMM (i.e. Microsoft) are less reliable. I'm not sure about Apples CMM.
Chris is long gone from Adobe :-X
Adobe RGB (1998) resulted from a mistake (they, Adobe thought they were specifying SMPTE-240M; got it wrong). Doug will have to ping SMPTE.
-
I'm saying I created an ICC profile ("ClayRGB1998.icm") to implement Adobe RGB (1998) based on the Adobe specification.No idea - you'd probably have to ask Chris Cox of Adobe that question.No - I haven't heard anything about how Adobe RGB(1998) came to be.ProPhoto RGB implemented according to the specifications should have power curve with straight line slope limit. It is based on ROMM RGB (http://www.color.org/rommrgb.pdf), and the spec says:
If Rr, Gr, or Br are less than 0.001953
R = Rr*16
G = Gr*16
B = Br*16
If Rr, Gr, or Br are greater than or equal to 0.001953
R = Rr1/1.8
G = Gr1/1.8
B = Br1/1.8
All I know is that (mainly from testing Marti did some time ago, as well as my own testing) that Adobe ACE, littleCMS and ArgyllCMS are in very good agreement in the interpretation of ICC profiles, while other CMM (i.e. Microsoft) are less reliable. I'm not sure about Apples CMM.
Thanks Graeme, much appreciated.
I checked the ProPhoto RGB profile Adobe uses as well and it is also a pure gamma profile! But I also recall ROMM had a linear ramp as well so I don't know why that has filtered into Adobe stuff.
I haven't found a good rationale for a linear ramp on the front or matrix spaces. but it seems to have been more in common a decade or so ago than now. Hard to find much on it now. It is quite a small effect and only at really low luminance.
Perhaps high dynamic range stuff and Hollywood is a factor. Their (Academy of motion picture arts and sciences) 16 bit small float storage of video allows for a good dynamic range where a pure gamma fits better.
Added:
I've found a few discussions of Adobe's "Slope Limiting CMM" and the original ROMM paper. There is even a discussion that the Kodak copyrited ProPhoto RGB does not do it in the ICC profile in the expectation Adobe's CMM does it. See here:
http://www.photo-lovers.org/pdf/color/romm.pdf
It seems quite apparent that, at some point in time Adobe ACE did slope limiting but everything I've tried with Photoshop does not produce slope limited results. Very weird.
The rationale for slope limiting is cleaner inversions of near black colors from linear back to the gamma encoded space. This makes sense for a lot of the cpu tech that existed >10 or 20 years ago where small, lookup tables were used. But inversions using floating point have become faster on CPU's than lookup tables when working with higher precision data because of cache/memory latency.
I'm beginning to think Adobe ACE at one time did do slope limiting using older coding practices and at some point modernized it and eliminated slope limiting for efficiency as there is no invertability issue with modern processors.
I'm like a dog on a bone about this for some reason. Hi Andrew :)
-
I've found a few discussions of Adobe's "Slope Limiting CMM" and the original ROMM paper. There is even a discussion that the Kodak copyrited ProPhoto RGB does not do it in the ICC profile in the expectation Adobe's CMM does it. See here:
http://www.photo-lovers.org/pdf/color/romm.pdf
I could ask Geoff Woolfe if he recalls any of that detail if you like.
-
I wouldn't assume PS 'doesn't do that'. It used to do it and I would be surprised if it didn't do it any more. There are good reasons why they did it.
The test is not PS to PS. ACE is well behaved, so if it does do whatever it probably does it throughout. The test is ACE vs a literal interpretation of the spec (e.g. Microsoft ICM or similar).
So the Adobe Color Engine does indeed use a linear toe near the origin when dealing with Adobe RGB, at least in CS5, which is the version of PS I use. In fact it uses two distinct linear sections. This is what the curves look like in 16-bit DNs:
(https://i.imgur.com/5VYyGdw.png)
Note how the conversion from sRGB linear to sRGB gamma performed by adhering to the spec in Matlab and by CS5's Adobe Color Engine independently track perfectly - and are well behaved near the origin, thanks to the linear toe.
However, Matlab's perfect 'spec' Adobe RGB gamma conversion results in some junk near the origin (can we call it noise Andrew?) and then follows the trajectory of a 1/2.2 exponential. On the other hand the smarter Color Engine in CS5 introduces two linear sections near the origin and avoids such messes, in a win for practicality vs unattainable perfection.
Cheers,
Jack
-
So the Adobe Color Engine does indeed use a linear toe near the origin when dealing with Adobe RGB, at least in CS5, which is the version of PS I use. In fact it uses two distinct linear sections. This is what the curves look like in 16-bit DNs:
(https://i.imgur.com/5VYyGdw.png)
Note how the conversion from sRGB linear to sRGB gamma performed by adhering to the spec in Matlab and by CS5's Adobe Color Engine independently track perfectly - and are well behaved near the origin, thanks to the linear toe.
However, Matlab's perfect 'spec' Adobe RGB gamma conversion results in some junk near the origin (can we call it noise Andrew?) and then follows the trajectory of a 1/2.2 exponential. On the other hand the smarter Color Engine in CS5 introduces two linear sections near the origin and avoids such messes, in a win for practicality vs unattainable perfection.
Cheers,
Jack
That's the first I've seen mentioned of 2 linear ramps with Adobe RGB. The paper on Adobe RGB linked previously would only have 1 ramp slope. Do you have the protocol that generated the second graph? I don't have CS5 but can test it against the current ACE.
The ramp I get, using PS CC, and converting the posted 16 bit tif with 65536 pixels (256x256) assigned to a linear gamma, shows the 2.2 "perfect" curve. It matches MATLAB.
The searches I've done on this strongly suggests that Adobe's ACE initially implemented a ramp but I see no indication it's in the current product.
The oldest PS I have is CS6 which I will install and test.
-
That's the first I've seen mentioned of 2 linear ramps with Adobe RGB. The paper on Adobe RGB linked previously would only have 1 ramp slope. Do you have the protocol that generated the second graph? I don't have CS5 but can test it against the current ACE.
The ramp I get, using PS CC, and converting the posted 16 bit tif with 65536 pixels (256x256) assigned to a linear gamma, shows the 2.2 "perfect" curve. It matches MATLAB.
The searches I've done on this strongly suggests that Adobe's ACE initially implemented a ramp but I see no indication it's in the current product.
The oldest PS I have is CS6 which I will install and test.
That's what ACE does in CS5, glad for you to double check it on a more current version of PS.
I think you don't see it because from what I understand of your comments you are not forcing PS to do the conversion. The protocol I use is very simple:
1 ) Generate a plausible XYZD65 read noise 'black' frame
2 ) Project it into linear Adobe RGB via matrix multiplication
3 ) Write the file to tiff
4 ) Open the tiff with CS5
5 ) Assign a previously prepared linear Adobe RGB (1998) profile to the open image
6 ) Convert to the standard Adobe RGB (1998) profile with its gamma
7 ) Save the newly converted Adobe RGB image to tiff
8 ) Load this last tiff into Matlab and compare it to 3) raised to 'spec' aRGB gamma.
Code snippet attached. If you PM me your email address I can send you scripts and xyz data.
Jack
-
That's what ACE does in CS5, glad for you to double check it on a more current version of PS.
I think you don't see it because from what I understand of your comments you are not forcing PS to do the conversion. The protocol I use is very simple:
1 ) Generate a plausible XYZD65 read noise 'black' frame
2 ) Project it into linear Adobe RGB via matrix multiplication
3 ) Write the file to tiff
4 ) Open the tiff with CS5
5 ) Assign a previously prepared linear Adobe RGB (1998) profile to the open image
6 ) Convert to the standard Adobe RGB (1998) profile with its gamma
7 ) Save the newly converted Adobe RGB image to tiff
8 ) Load this last tiff into Matlab and compare it to 3) raised to 'spec' aRGB gamma.
Code snippet attached. If you PM me your email address I can send you scripts and xyz data.
Jack
Got it, your process is perfectly fine. The difference is that you start from a noisy linear source then convert to Adobe RGB and compare the mapping of linear RGB values to the converted, Adobe RGB ones so, for instance, a histogram of the result shows the noise distribution from the camera. You should see exactly the same linear to Adobe RGB plot with the tif16all.tif file I posted since it has all 64k, 16 pit pixels in it. Just load the tif1ll16.tif image at step 4 and run through the rest of the steps.
Confirmed! I installed CS6. PS CS6 exhibits exactly the same 2 linear ramps! PS CC 2018 doesn't.
Somewhere between CS6 and the current CC (V20.0.n), Adobe dropped the slope limit in ACE conversions. sRGB is unchanged which is to be expected since the sRGB TRC has a longer slope limit than where the earlier ACE cuts in.
-
Yep, CS6 has the linear ramp. Actually 2 of them as Jack noted.
Jack,
CS6 exhibits exactly the same ramp you see. No idea when Adobe ACE dropped the slope limiting. Here's the image and code.
% AdobeRGB_toe_test
imag_CC=reshape(imread('tif16all_aRGB_CC.tif'), 65536,3);
imag_CS6=reshape(imread('tif16all_aRGB_CS6.tif'), 65536,3);
plot(imag_CC(:,2)); hold on
plot(imag_CS6(:,2)); hold off
title('PS CC v CS6, ACE Toe')
legend('PS CC', 'PS CS6'); grid on
-
It could also indicate linear interpolation of some internal lut.
Does it make any difference if you enable/disable gpu?
-
It could also indicate linear interpolation of some internal lut.
Does it make any difference if you enable/disable gpu?
No difference. GPUs presence doesn't affect the conversion.
It's technically possible for Adobe to use LUTs but more likely they used to use LUTs and dropping the linear ramp was a consequence of converting to SSE math. Back in the old days of processors, floating point math was slow relative to memory access so LUT solutions provided the best performance. But floating point and multiple core processors rapidly changed the tradeoff. Implementing a ramp would, these days, incur a small performance hit compared to just calculating the gamma. sRGB and a few others like L* based spaces still require LUTs. But Adobe RGB and ProPhoto can calculate gamma faster than using LUTs.
-
CS6 exhibits exactly the same ramp you see. No idea when Adobe ACE dropped the slope limiting.
Huh, interesting Doug.
Since I had the stuff out, here is a histogram to support my earlier obvious point on floating point: if you stick with floating point, the original luma Y is all there and the same after a round trip to Adobe RGB and back (the two histograms overlay each other) - while of course that's not the case if the same trip is performed via 16-bits. The chart shows what happens near the origin, of course the same would hold true at the other end, the edges of the cube where clipping occurs.
Jack
-
Since I had the stuff out, here is a histogram to support my earlier obvious point on floating point: if you stick with floating point, the original luma Y is all there and the same after a round trip to Adobe RGB and back (the two histograms overlay each other) - while of course that's not the case if the same trip is performed via 16-bits. The chart shows what happens near the origin, of course the same would hold true at the other end, the edges of the cube where clipping occurs.
Jack
Hi Jack!
Where do the negative numbers come from. The histogram shows for the floating point. Was this created by adding noise to your data set? Negative numbers, by definition, represent out of gamut colors in an RGB space. Does this relate to the title of the histogram? 16 bit numbers in tiff files are unsigned and Adobe PS drops the low bit but still treats the numbers as unsigned which explains the right side of the histogram.
That aside, I'm not sure what the import of this is? Could you explain more how the dataset was generated and processed. Matlab, where applicable, is fine and a lot shorter than words.
-
Hi Doug,
That's just me thinking floating point vs unsigned integers. It appears that many folks over-think the in/out of working gamut issue, which is instead pretty simple both in principle and to understand: start by visualizing a cube, end by visualizing a cube, what image information falls outside of the ending cube is out of gamut. That's it.
Some free-wheeling thoughts. Assuming linearity for the sake of simplicity, image information:
1) is originally in a plane of raw data (say rggb);
2) it is assembled in the form of an initial rgb cube which, after white balance and demosaicing, has origin at [0,0,0]; and
3) it's still the same cube, albeit viewed from a different perspective, when it is stored in the file to be displayed. The final point of view is specified by the relevant spec (e.g. Adobe RGB)
So how can image information end up falling out of the final cube? There are only two ways (they can actually be considered one and the same):
i) White balance
ii) The change of perspective matrix multiplication.
White balance multipliers are what they are given the sensor and the illuminant. For my 5DSR ISO100 example above they were
1 / [0.45819,1,0.65374]
for r, g and b resp. This means that, absent some brightness manipulation, image information from the red CFA channel greater than 45.8% of full scale will be out of gamut (also greater than 65.4% blue and 100% green).
After white balancing (so the initial cube will have origin at [0,0,0] and normalized vertex at [1,1,1]) only positive normalized values between 0 and 1 are part of the color space cube, everything else is out of gamut. The wbraw->aRGB compromise color matrix for this case happens to be:
[ 1.4047 -0.3878 -0.0169
-0.2301 1.7805 -0.5504
0.0043 -0.4620 1.4577 ]
This matrix will project all rgb image data in the initial cube 2) to the final cube 3) above. Note for instance that the origin of the initial cube [0,0,0] maps to also [0,0,0] in the final cube; and the initial normalized vertex [1,1,1] maps to [1,1,1] in the final cube. Black to black, white to white, so far so good.
But it is also obvious that the projection may push some image data out of the final RGB cube. For instance a full green CFA input signal with no red and blue in the initial cube [0,1,0] will result in a tone outside of the final cube: [-0.3878 1.7805 -0.4620]. Those coordinates are not between zero and one, so the tone is out of gamut. Many more like that near there.
That's all there is to it, no magic. Just in or out of the final RGB cube, which in this example is Adobe RGB.
My earlier point was simply that if one sticks to floating point and retains all values (less than zero, greater than one and all) until the final conversion, it really does not make any difference whatsoever to tone 'accuracy' what the matrix (hence the working color space or its gamut size) is. No need to work in PP for instance. Even so I would want a working color space to have a gamut similar to that of the monitor on which the image being adjusted is viewed, so that one can see what they are doing. For most of us these days that means at best a true 8-bit video path to an Adobe RGB monitor.
Cheers,
Jack
-
Is that a round about way of saying your workingspace is unlimited XYZ?
I implemented that at some point. Used a perceptual XYZ space (which is obviously an RGB space, just with virtual primaries) as a workingspace to do additional processing. Because technically you just want to stay in source space as long as possible for exposure- and whitebalance compensation.
For creative adjustments however, one may opt for an independent workingspace which should at least operate relatively predictably. Perceptual XYZ seemed to work fine on modern hw.
-
Hi Doug,
That's just me thinking floating point vs unsigned integers. It appears that many folks over-think the in/out of working gamut issue, which is instead pretty simple both in principle and to understand: start by visualizing a cube, end by visualizing a cube, what image information falls outside of the ending cube is out of gamut. That's it.
Sure. Any RGB space, represented in floating point (including negatives) will cover the entire human gamut. There is even a spec for signed sRGB. The notion was that the negative digital values would just be clipped when going to a sRGB like monitor but larger gamut monitors could display more saturated colors.
Some free-wheeling thoughts. Assuming linearity for the sake of simplicity, image information:
1) is originally in a plane of raw data (say rggb);
2) it is assembled in the form of an initial rgb cube which, after white balance and demosaicing, has origin at [0,0,0]; and
3) it's still the same cube, albeit viewed from a different perspective, when it is stored in the file to be displayed. The final point of view is specified by the relevant spec (e.g. Adobe RGB)
So how can image information end up falling out of the final cube? There are only two ways (they can actually be considered one and the same):
i) White balance
ii) The change of perspective matrix multiplication.
White balance multipliers are what they are given the sensor and the illuminant. For my 5DSR ISO100 example above they were
1 / [0.45819,1,0.65374]
for r, g and b resp. This means that, absent some brightness manipulation, image information from the red CFA channel greater than 45.8% of full scale will be out of gamut (also greater than 65.4% blue and 100% green).
After white balancing (so the initial cube will have origin at [0,0,0] and normalized vertex at [1,1,1]) only positive normalized values between 0 and 1 are part of the color space cube, everything else is out of gamut. The wbraw->aRGB compromise color matrix for this case happens to be:
[ 1.4047 -0.3878 -0.0169
-0.2301 1.7805 -0.5504
0.0043 -0.4620 1.4577 ]
This matrix will project all rgb image data in the initial cube 2) to the final cube 3) above. Note for instance that the origin of the initial cube [0,0,0] maps to also [0,0,0] in the final cube; and the initial normalized vertex [1,1,1] maps to [1,1,1] in the final cube. Black to black, white to white, so far so good.
But it is also obvious that the projection may push some image data out of the final RGB cube. For instance a full green CFA input signal with no red and blue in the initial cube [0,1,0] will result in a tone outside of the final cube: [-0.3878 1.7805 -0.4620]. Those coordinates are not between zero and one, so the tone is out of gamut. Many more like that near there.
That's all there is to it, no magic. Just in or out of the final RGB cube, which in this example is Adobe RGB.
Absolutely! Camera sensors don't have a gamut. At least in the normal sense of the word. They do have a response. Sensors, in combination with the CFAs, being quite linear. To the degree the combination meets L/I, the sensor's channels will map perfectly to XYZ (positive numbers only) and any other RGB space if negative numbers are allowed. L/I is an unmet ideal so the mapping is not one to one. If one goes around the wavelengths of 400nm to 700nm the xy transform will move in and out of the human xy horseshoe for linear curve fits.
My earlier point was simply that if one sticks to floating point and retains all values (less than zero, greater than one and all) until the final conversion, it really does not make any difference whatsoever to tone 'accuracy' what the matrix (hence the working color space or its gamut size) is. No need to work in PP for instance. Even so I would want a working color space to have a gamut similar to that of the monitor on which the image being adjusted is viewed, so that one can see what they are doing. For most of us these days that means at best a true 8-bit video path to an Adobe RGB monitor.
Of course.
Cheers,
Jack
Check your PM for email.
-
“Human gamut”? May I suggest something like simply “human perception of color”? Humans (like cameras) do not have a color gamut. Considering the forum and a lack of quotes around human gamut, I hope no one is upset by the clarification.
-
“Human gamut”? May I suggest something like simply “human perception of color”? Humans (like cameras) do not have a color gamut. Considering the forum and a lack of quotes around human gamut, I hope no one is upset by the clarification.
Yeah. Probably a much better term is the CIExy gamut, which is the physical limit of single wavelength chromaticity response modeled through the color matching functions. A specific xyY defines a stimulus, but not the perceived apparent color which depends strongly on adaptation state and the current surround.
-
start by visualizing a cube, end by visualizing a cube, what image information falls outside of the ending cube is out of gamut. That's it.
Beware - the cube assumption is good for many situations, but not all. Move to CMYK and you get a hyper cube. Add in ink limits and the hyper cube gets cut plains-taken out of it. When you map a hyper cube into 3 dimensions (especially with non-linearity) there is no guarantee that planes remain well ordered - different surface can inter-penetrate, so that no simple geometry describes the surface. Real world devices and inks can behave non-monotonically (i.e. especially the maximum end may fold back), so that in general, you can't simply assume that the gamut surface corresponds to the maximum device value.
-
It appears that many folks over-think the in/out of working gamut issue, which is instead pretty simple both in principle and to understand: start by visualizing a cube, end by visualizing a cube, what image information falls outside of the ending cube is out of gamut. That's it.
Beware - the cube assumption is good for many situations, but not all. Move to CMYK and you get a hyper cube. Add in ink limits and the hyper cube gets cut plains-taken out of it. When you map a hyper cube into 3 dimensions (especially with non-linearity) there is no guarantee that planes remain well ordered - different surface can inter-penetrate, so that no simple geometry describes the surface. Real world devices and inks can behave non-monotonically (i.e. especially the maximum end may fold back), so that in general, you can't simply assume that the gamut surface corresponds to the maximum device value.
Right. To further clarify my simple visualization was aimed at the choice of a working color space facing the OP and the typical raw-conversion operator when adjusting his/her capture by viewing it on a monitor: from demosaiced white-balanced raw data to the file to be shared/output, typically sRGB, Adobe RGB or ProPhoto RGB (I guess we'll have to add Rec2020 in the near future to that list).
Jack
-
Is that a round about way of saying your workingspace is unlimited XYZ?
More like white-balanced and demosaiced raw 'space', the normalized 'gamut' of which is a cube - though I know some purists would object to some of these words.
-
More like white-balanced and demosaiced raw 'space', the normalized 'gamut' of which is a cube - though I know some purists would object to some of these words.
Right, so what would be the objectives?
I'd presume:
1. Keep the data in capture space as long as possible
2. Some kind of consistency when editing
3. A useful representation of output limitations
Regarding 1:
That would be useful for editing exposure, whitebalance, and, very importantly, lenscorrections. Exposure and white balancing within capturespace allows one to edit while maintaining (in)consistency of capture device. Chromatic Aberration corrections are best done before anything introduces crosschannel talk. (Including demosaicing).
Regarding 2:
When editing images creatively, it is useful if the data is controllable and operates predictably. This requires a controllable colorspace, which is to say: perceptual, not too large, and equal for different input devices. (It may allow negative values and overshoot, which has consequences for user controls).
Regarding 3:
There are obviously different ways of representing the limitations, usually out-of-gamut colors. Most oog colors are primarily oversaturated colors. An interesting problem would be capture colors with one or two negative coordinates. No amount of exposure compensation will bring those colors back in outputspace.