<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div apple-content-edited="true"><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><font class="Apple-style-span" face="Verdana"><span class="Apple-style-span" style="font-family: Helvetica; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="font-family: Verdana; ">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.</span></div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><font class="Apple-style-span" face="Verdana"><br class="webkit-block-placeholder"></font></div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="font-family: Verdana; ">On Mar 8, 2008, at 1:13 AM, Scott Geffert wrote:</span></div></span></font></div></span></div><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Unlike theory guys like Chris I focus 100% in the field since pre photoshop days.</div></div></blockquote><div><br class="webkit-block-placeholder"></div>and</div><div><br class="webkit-block-placeholder"></div><div><blockquote type="cite"> As a supposed scientist Chris is incredibly closed minded on this topic, but I don't know why.</blockquote></div><div><br class="webkit-block-placeholder"></div><div>My interest has always been about image quality, given the limitations of devices we have, while always looking to the future for new advancements.</div><div><br class="webkit-block-placeholder"></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div> 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. </div></div></blockquote><div><br class="webkit-block-placeholder"></div><div>What does that mean? How is L* agnostic? And it's the most agnostic compared to what? What are the alternatives?</div><div><br class="webkit-block-placeholder"></div><div>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.</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>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.</div></div></blockquote><div><br class="webkit-block-placeholder"></div><div>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.</div><div><br class="webkit-block-placeholder"></div><div>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.</div><div><br class="webkit-block-placeholder"></div><div>Why and how are RGB values in an interface relevant to the user? Do they need to see actual encoded RGB values? Why? </div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; "><span class="Apple-tab-span" style="white-space:pre"> </span>The L* and ISO standards are going to prove to be critical for digital imaging to mature. </span></div></div></blockquote><div><br class="webkit-block-placeholder"></div><div><br></div><div>Well there are a lot of important issues to address in digital imaging. I don't consider this a top contender.</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">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.</span></div></div></blockquote><div><br class="webkit-block-placeholder"></div><div>This paragraph is not clear. What is the bigger picture I fail to understand?  What is "the gamma mess"? </div><div><br></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><span class="Apple-tab-span" style="white-space:pre"> </span>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*).</div></div></blockquote><div><br class="webkit-block-placeholder"></div><div>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?</div><div><br class="webkit-block-placeholder"></div><div>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?</div><div><br class="webkit-block-placeholder"></div><div><br></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Chris has seen this document, so I don't know why he can say that no one has tested it.</div></div></blockquote><div><br></div><div>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.</div><div><br class="webkit-block-placeholder"></div><div>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. </div><div><br class="webkit-block-placeholder"></div><div>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.</div><div><br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div> By the way, the results on screen and in print are better!</div></div></blockquote><div><br class="webkit-block-placeholder"></div><div>Better in what way? How much better? What's the metric? </div><div><br class="webkit-block-placeholder"></div><div>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?</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div> 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.</div></div></blockquote><div><br class="webkit-block-placeholder"></div><div>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.</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div> 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.</div></div></blockquote><div><br class="webkit-block-placeholder"></div></div><div>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.</div><div><br class="webkit-block-placeholder"></div><div>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.</div><div><br class="webkit-block-placeholder"></div><div><br></div><div>Chris Murphy</div><br></body></html>