[Openicc] L* ... (please move topic to ECI-EN mailinglist)

[Chris Murphy]

My apologies to the list. This topic was closed and moved to ECI-EN.  
However, given that several mischaracterizations of statements I've  
made have been posted, I felt it appropriate to respond. As I  
indicated some weeks ago on this subject, the likely best venue for  
discussion is on the ECI-EN mailing list.

On Mar 8, 2008, at 1:13 AM, Scott Geffert wrote:

> Unlike theory guys like Chris I focus 100% in the field since pre  
> photoshop days.

and

>  As a supposed scientist Chris is incredibly closed minded on this  
> topic, but I don't know why.


My interest has always been about image quality, given the limitations  
of devices we have, while always looking to the future for new  
advancements.

There are at least a few real color scientists on this list and I  
think they will find it amusing to hear me referred to as a theory  
guy, and a scientist. My entire background in this industry is based  
on working directly with end-users. While I have admitted to being a  
color geek, I've never claimed to be either a scientist or a  
theoretician. Where are these assertions of yours coming from, Scott?

Those making claims of quality deficiencies or improvements in  
existing encodings are burdened with demonstrating such claims.  
Nevertheless, I have asked numerous questions about this issue on  
lists, to color scientists, and to engineers, expressly because I am  
open minded. I have found merit in the first version of ECI RGB for  
reasons stated here and on the ECI list. To date I have not read a  
compelling explanation for why eciRGBv2 is needed, what exactly it  
solves, what exactly the problems are with v1 or other encodings, and  
where the data is that demonstrates this.

>  Users are not stupid, but the industry treats them as such by  
> avoiding the fact that that all computer displays can be configured  
> to the same standards, and frankly L* is the most agnostic approach  
> as it is based on human tonal perception.

What does that mean? How is L* agnostic? And it's the most agnostic  
compared to what? What are the alternatives?

It's derelict to claim that all computer displays can be compelled to  
have a TRC defined by L*, and not also state the potential quality  
loss due to a limited bit path at various stages in the display  
system. L* is applicable to humans (in rather specific situations).  
It's not a descriptor of the tone reproduction curve of our devices.  
Relevancy of L* in this discussion is lacking.

> The ECI adoption of the L* based working space has an impact that  
> makes digital capture crystal clear. 50L=128. Ask 100 photographers  
> to photograph a gray card today using three of the leading image  
> processing apps and you will get completely random results. Why? the  
> industry has allowed itself to run out of control when it comes to  
> standard practices. Each tool presents the user with different gamma  
> gradations,rgb readouts, percentage readouts, and none are documented.

The results are not random. When I provide a particular Raw file to a  
particular Raw processor with particular settings, I will get the same  
result each time. That is not random. If I process that file with  
three Raw processors, I do get different renderings.

And these differences are hardly as pronounced as the differences seen  
with different kinds of positive film exposure and development, let  
alone negative film exposure, development and print making. It seems  
you're suggesting that there is some recent crisis in users getting  
what they want, and in a Raw workflow it is vastly more controllable  
and consistent than with film.

Why and how are RGB values in an interface relevant to the user? Do  
they need to see actual encoded RGB values? Why?

> 	The L* and ISO standards are going to prove to be critical for  
> digital imaging to mature.


Well there are a lot of important issues to address in digital  
imaging. I don't consider this a top contender.

> Chris is correct in that in a 16 bit workflow ICC takes care of the  
> gamma mess, but he fails to understand the bigger picture. Not  
> everyone wants of needs to have a color consultant to have a  
> repeatable process, or to go to a photo lab or printer and expect a  
> consistent result. For my worldwide museum clients it is absolutely  
> essential that ISO standards can help preserve cultural history for  
> future generations. Right now, legacy shortcomings in the imaging  
> field are being propped up by ICC alone.

This paragraph is not clear. What is the bigger picture I fail to  
understand?  What is "the gamma mess"?

> 	I recently posted an article that actually laid out very a very  
> specific international case study comparing calibrated digital  
> captures processed to AdobeRGB, ProPhotoRGB, eciRGBv2, and  
> ProStarRGB (a proposed wide gamut RGB space with L* TRC-it's  
> literally ProPhotoRGB modified to L*).

A ProPhoto gamut necessarily implies a 16bpc workflow. As you've  
already suggested that 16bpc workflows resolves the issues of  
encoding, how is "ProStarRGB" relevant? In what context is suddenly L*  
such an important issue that thousands of workflows successfully using  
it should be modified?

In exactly what way are the merits and faults of existing encoding  
compared to L* based encoding going aid in the maturation of digital  
imaging compared to other needs? Why is the encoding even relevant? Is  
L* based encoding only relevant for 8bpc workflows? 16bpc workflows?  
32bpc workflows? Why or why not?


> Chris has seen this document, so I don't know why he can say that no  
> one has tested it.

Fair enough, I will qualify that. I have yet to read anything  
indicating eciRGB, or any other L* defined TRC based color space, has  
been tested to a level that makes it even remotely compelling.

The claims of significant quality improvements are unproven. There's  
no working hypotheses that I've read regarding the problems with  
existing encoding, and exactly how L* encoding should resolve those  
problems, in what ways it cannot resolve those problems, what the  
alternatives are, and proposals of a number of tests demonstrating  
these hypotheses.

And further what impact this has on the market and on workflows, to  
have yet another RGB space being thrust upon users, and having them  
hear how yet another magical new color management tinker toy is now  
available and they absolutely must have and use it. Sorry to rain on  
the parade and actually ask "why?!" Well except I'm not sorry. I'm  
ultimately an end-user advocate. Is this thing really necessary? So  
far I do not find it compelling.


> By the way, the results on screen and in print are better!

Better in what way? How much better? What's the metric?

In what viewing conditions? What devices? What media? What images?  
What was their capture source? How were conversions performed? How  
many CMM's were tested? Is it always better? When is it not better?  
What's the explanation for this?

> Chris and a select group of "color experts" have personally attacked  
> this article which was only presented as a field test of existing  
> and proposed standards.

What are you talking about? I certainly haven't attacked it, and I  
don't know anyone who has attacked it. I read this article for the  
first time a few weeks ago and have made no public statement about it  
whatsoever. And the number of people I've privately discussed it with  
I can count on one hand.

> The intent of my article was to encourage thoughtful discussion, and  
> frankly to push Adobe and camera manufacturers to get behind ISO  
> standards. The statement that Chris made regarding ISO standards  
> should "Just Die" are incredibly short sighted and unprofessional.

What I wrote was: "So quite frankly I wish ECI-RGBv2 would die a fast  
painless death." Whereas you have falsely stated that I oppose ISO  
standards - plural.

What I wrote was hyperbole. However, the crux of the matter is that  
there's a distinct lack of compelling data on what real world problem  
eciRGBv2 is supposed to solve. Or does it simplify something that is  
in great need of simplification? What alternatives were proposed? Why  
do we need yet another flavor of RGB floating out in the world? How do  
the alternatives stack up on their merits or failures in comparison to  
ECI-RGBv2? I haven't seen these questions asked, or their answers.  
Merely lots of supposition.


Chris Murphy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/openicc/attachments/20080311/877039bf/attachment.htm