[argyllcms] Re: cctiff output colorspace and the consistency of appearance
- From: "Wire ~" <wire@xxxxxxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Thu, 28 Apr 2022 17:49:44 -0700
On Thu, Apr 28, 2022 at 4:17 PM Graeme Gill <graeme@xxxxxxxxxxxxx> wrote:
Depends on the pixel depth. L*a*b* is more efficient in encoding, but
these bits
are spread slightly wider in gamut compared to sRGB or AdobeRGB. It's
about equal
for the same bit depth,
I am not an expert on any of this, so please regard the following as food
for thought...
Per Lindbloom's RGB Working Space Information:
http://www.brucelindbloom.com/index.html?WorkingSpaceInfo.html
Common Colorspace Coding efficiency:
- Lab space: *35*% (most of Lab space are not colors)
- ProPhotoRGB : *87*% (most of are colors, 0.9 of Lab)
- Adobe RGB: *100*% (all codes are colors, 0.5 of Lab)
- sRGB: *100*% (all codes are colors, 0.35 of Lab)
As has been discussed here for years, "gamut" is a challenging word, and
the way that Lindbloom is using it for his write-up suggests a distinction
between Lab Gamut as CIE math for visual phenomena and Lab Gamut as a coded
space. Note that in Lindblom's chart, "Lab Gamut Efficiency" of "Lab Gamut"
(presumably coding) is listed as 97%.
Lindbloom writes:
//The first entry in the table is the Lab Gamut. This is the set of Lab
color coordinates for which there could possibly be a physical sample.
These are the "real colors." Lab color coordinates that lie outside this
gamut can never exist in nature, and therefore it is not important that
these coordinates be represented in a working space definition...//
I read his chart and explanation as follows: Due to the nature of Lab value
coding, it has poor numerical efficiency, as only 35% if codes get mapped
to actual colors.
If so, 16-bit integers per channel or small floats preserve precision, so
this poor coding efficiency doesn't matter outside of storage costs.
The next points I want to make are based on the above reading; if I
misunderstand, then these points may go out the window:
If, for sake of argument, your device under consideration is never going to
produce more than sRGB, then the effective efficiency in a move to Lab
looks like around 25% or less (big hand wave). If your coding scheme is
floats or 16-bit per channel RGB, you are still safe to target conventional
web and video representation re quantization noise.
But if you moved to 8-bit per channel integer Lab, then into web (or worse
into video YCbCr) you are heading for a quantization noise disaster. The
move might look OK for a static image, but it's combed so much precision
out of the image that if you try any further editing, it's going to fall
apart.
After a lot of goofing around with Photoshop (I am not an expert) I suspect
PS internally keeps Lab as floats and gives you a 8-bit integer info
palette on the fly. It also appears that PS Lab TIFF may bit high-bit. I've
never tried to hex-edit the data, I just tried to contrive some experiments
where if 8 bpc Lab was being saved, errors should compound to point of
noticeable artifacts, but I found the image not degrade as I expected.
My approach and results were too ham-fisted and contrived to be worthy of a
post, but I am sticking my this thinking.
Please destroy these arguments as I will learn something. Thanks
/wire
Other related posts:
