Re: [csswg-drafts] [css-color] Discussion of Conflicts & Resolutions: D50/D65, LAB/LUV, ICC/OCIO (#6061)

Hey Chris @svgeesus 

# Regarding D50
Something I wanted to add in here. I'm concerned I am not explaining my position well, and it's not being received as intended. I have some additional experiences to share.

Some years ago I was working on the film, "The Fourth Kind" and I was using AfterEffects as there was a substantial load of motion graphics, and AE was well suited to that. Adobe had introduced ICC profiles to AE, and also came out with a workflow manual that resulted in issues that certainly shaped my opinions. As I had used ICC profiles for all of my print related work for over a decade, it "sounded like" a good idea, being a typically optimistic early adopter.

Adobe defined a workflow for feature films which was to use the ProPhoto ICC profile in linear 32 bit floating point as the working space, and use the "Universal Film" ICC profile they provided to output to 10bit integer DPX log (standard Cineon), using display soft proofing. The cursory early tests seemed okay, round trips worked so didn't "seem" to be a concern. But as work progressed into the full range of shots, and deliverables to the DI house, PacTitle, this workflow turned out to be a _very_ bad idea. 


## Round Trips in Square Spaces... Or something.
I don't think I've adequately conveyed my concerns here and why I am taking this issue on. And it's not about round trips, not really even the performance issue I've been mentioning. I realize that I have not emphasized some important considerations.

Following the above approach on T4K resulted in a slew of issues. Investigating into what was wrong:

### Problems Experienced:
- Color channel wrap. This was a crazy and unexpected side effect. There were no negative colors in the working space, but through the PCS to output transform, color channels would go negative which would then wrap around and become the brightest pixels.
    - Most notable was red channel wrap, as I recall it was the blue channel going negative, wrapping around and ending up in the red channel of the next pixel on the DPX file.
    - The black point to the DPX was set at code value 90, nevertheless a combination of factors including the profiles and WP still caused negative excursions,  particularly in noisy areas of the image.
- Substantial desaturation. I believe this was more an artifact of using ProPhoto than D50 per se. By the time the DPX files got to DI, the look was very desaturated from how it appeared in my working space.
- Unexpected shifts in density and gradients.
- Some banding artifacts which I didn't have time to investigate as they appeared just before I changed the workflow, this being the only time I've ever had to change a workflow mid-film.
- Unexpected blue/purple shifts, which is unexplained as none of the profiles used the LAB PCS space, all were XYZ, though reflecting back on this, it occurs to be that since the 1931 2° observer under-represents blue, this could have been a factor with this shift.

### Take Aways
That was a long time ago, when workflows were still using DPX and there were still emerging workflow changes. Today, these things are more settled, and the industry has largely adopted EXR (finally!) But in essence, best practice is keeping the same illuminant for working space and destination space, and when possible work in the same space as destination. Doing work in a different space or reference illuminant than destination _will_ have different results.

It's not about round trips. Yes, a floating-point trip through a different space for a given color with no gamut mapping and nothing clamped, should result in a near lossless result, with the output-color being less than 1 ∆E (except dark blue).

#### BUT
It's not always about round-tripping an unchanged color... Working in or choosing colors or gradients or whatnot will result in a demonstrable difference.

### EXAMPLES
The easiest way to illustrate this is with some examples using a simple gradient. The gradients are being created in LAB and LCh<sub>ab</sub> using a simple averaging between the start and end for each axis. 

#### Method
The start and end colors are selected in D65, and the D65 version does everything in D65. The D50 version first transforms the D65 sRGB colors to XYZ using the piecewise sRGB TRC, then in XYZ Bradford CAT to D50 using the matrix listed in CSS 4 color, and using the D50 convert to LAB and LCh<sub>ab</sub>, then do the gradients using the same method for the two versions, then back out from LAB to XYZ, then Bradford CAT to D65, then back to sRGB using the piecewise.

Then use the basic LAB color difference formula (square root of the sum of the squared differences). Everything is floating point except of course the hex values for the two start colors, and the final hex values for the displayed gradient. The ∆E is done with the floating point values in LAB space. The ∆E for the LCh was also performed on the L<sup>*</sup>a<sup>*</sup>b<sup>*</sup> values.

**LAYOUT:**
- TOP: Cartesian L<sup>*</sup>a<sup>*</sup>b<sup>*</sup> D50 left, D65 right
- BOTTOM: Polar L<sup>*</sup>C<sup>*</sup>h D50 left, D65 right

#### RESULTS:
You'll notice the start and end colors make it through the round trip okay. But the _work_ done in D50 has different results from the identical work done in D65. Also, the LCh version suffers more than the LAB version.

**COLORS: `00F` to `FF0`**
<img width="790" alt="Screen Shot 2021-09-10 at 8 57 25 PM" src="https://user-images.githubusercontent.com/42009457/133172485-f569cd57-7183-47f3-91bb-87b14746554d.png">

A greyscale ramp had no issues:    
**COLORS: `010101` to `F0F0F0`**
<img width="790" alt="Screen Shot 2021-09-10 at 6 48 26 PM" src="https://user-images.githubusercontent.com/42009457/133171408-6f87a402-538e-4d0d-8cf4-87ec6a532a81.png">

And a monochromatic ramp was not a problem for LAB, but was still for LCh.    
**COLORS: `010101` to `FFAA22`**
<img width="790" alt="Screen Shot 2021-09-10 at 6 49 45 PM" src="https://user-images.githubusercontent.com/42009457/133171501-937a9580-9f8c-4b1a-8a6c-0e7de3042005.png">

As a side note, not related to D50, sometimes the blue/purple shift is not a problem in the LCh but is apparent in LAB.    
**COLORS: `D0E0F0` to `0101FF`**
<img width="790" alt="Screen Shot 2021-09-10 at 8 29 25 PM" src="https://user-images.githubusercontent.com/42009457/133171828-0bae4571-044c-41ba-ab95-a32b6445d888.png">

And other times, the LCh is having problems with a purple shift even more so, and is noticably different in the4 D50 vs D65 version.    
**COLORS: `0000DD` to `FCFCFC`**
<img width="790" alt="Screen Shot 2021-09-10 at 7 28 28 PM" src="https://user-images.githubusercontent.com/42009457/133171652-8620471e-cf7e-4a2f-a198-7e87c8e2f013.png">

Additional examples:    
**COLORS: `F00` to `0FF`**
<img width="790" alt="Screen Shot 2021-09-10 at 9 04 44 PM" src="https://user-images.githubusercontent.com/42009457/133171259-4d548b5a-3e26-4565-980c-e42c888aa771.png">


## TL;DR
What i am hoping to convey here is that round trips are not a definitive assessment of these transforms, it is the work being done in a given space. With these simple examples I am hoping to demonstrate that there are many aspects of a given space's illuminant that impact the ultimate results. More complicated work such as gamut mapping or color grading may have more complicated consequences — imagine going from Rec.2020 D65 to Rec.709 D65, but doing the gamut mapping in D50 LAB. Such a workflow would not make sense. 


Thank you,

Andy


-- 
GitHub Notification of comment by Myndex
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6061#issuecomment-918700990 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 14 September 2021 00:48:02 UTC