[Openicc] meta data in test chart

Tue Jan 25 17:27:41 PST 2011

I actually agree with Chris in that if there is a way to avoid the bottlenecks altogether this would be best. (see comments)

"I don't think we should ask for the building of architectures that are obsolete or that have unnecessary bottlenecks out of the gate"

 "Probably no matter what such things depend on hardware. But building out the least effort for the most performance and quality I think is the goal. I would not take a bet that the "force the hardware to be sRGB" paradigm even applies to mobile for much longer. There's an advantage for manufacturers to be able to have each unit capable of doing display compensation for everything that appears on the display. So a focus on optimization with minimal degradation of image quality for such products I think is inevitable". 

I think that this is forward thinking as very few devices today (other than printing presses) are smaller than sRGB, and as Chris points out while eciRGB is slightly larger than AdobeRGB, many devices today and more down the road will be capable of even wider gamut than these spaces so whatever method offers the most direct path would be the logical course.

On Jan 25, 2011, at 6:55 PM, openicc-request at lists.freedesktop.org wrote:

> Send openicc mailing list submissions to
> 	openicc at lists.freedesktop.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.freedesktop.org/mailman/listinfo/openicc
> or, via email, send a message with subject or body 'help' to
> 	openicc-request at lists.freedesktop.org
> 
> You can reach the person managing the list at
> 	openicc-owner at lists.freedesktop.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openicc digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: meta data in test chart (Chris Murphy)
>   2. Re: meta data in test chart (edmund ronald)
>   3. Re: meta data in test chart (Chris Murphy)
>   4. Re: meta data in test chart (Chris Murphy)
>   5. Re: meta data in test chart (Alastair M. Robinson)
>   6. Re: meta data in test chart (edmund ronald)
>   7. Re: meta data in test chart (Graeme Gill)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 25 Jan 2011 15:00:46 -0700
> From: Chris Murphy <lists at colorremedies.com>
> Subject: Re: [Openicc] meta data in test chart
> To: openicc Liste <openicc at lists.freedesktop.org>
> Message-ID: <7F262AAE-9F06-41E5-9416-223C52B22DBD at colorremedies.com>
> Content-Type: text/plain; charset=us-ascii
> 
> 
> On Jan 25, 2011, at 4:00 AM, Graeme Gill wrote:
> 
>> Chris Murphy wrote:
>> 
>>> Use of the PRMG would be useful here, in theory, because the idea is that the image is
>>> rendered scene-referred to output-referred once in something like ProPhoto RGB. The
>>> problem is that Adobe RGB and ProPhoto RGB do not come in v4 versions that make use of
>>> the PRMG. And then also there are no widely available v4 + PRMG output device profiles.
>>> So as far as I'm concerned ICC v4 and the PRMG are in a coma for mainstream users.
>> 
>> Hmm. I'm don't think that the PRMG helps in any way. You still need to identify
>> the source gamut. If your source profile is ProPhoto, what gamut is mapped
>> to the PRMG in the A2B table ?
> 
> In the grand v4 + PRMG scheme, it is the source profile's job to map the image to PRMG, and the destination profile's job to map from the PRMG.
> 
> But we don't have a v4 ProPhoto RGB, let alone one that describes how ProPhoto RGB images should be mapped to the PRMG. However I've been told this would be almost trivial because ProPhoto RGB is an output medium metric (hence its former name), but the work simply hasn't been done. It's probably Kodak's job to do it but AFAIK there's no interest.
> 
> 
>> If you map the ProPhoto gamut, most images
>> encoded in that space will end up looking very dull when linked with
>> (say) a printer profile that then maps from the PRMG to the printer gamut.
> 
> Yes, if you use the existing v2 ProPhoto profile, which is why most people end up using RelCol+BPC, rather than bump up saturation in the perceptual intent at the time they build the profile.
> 
> 
> Chris
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 25 Jan 2011 23:18:39 +0100
> From: edmund ronald <edmundronald at gmail.com>
> Subject: Re: [Openicc] meta data in test chart
> To: Chris Murphy <lists at colorremedies.com>
> Cc: openicc Liste <openicc at lists.freedesktop.org>
> Message-ID:
> 	<AANLkTimeE9scwgQdp9mx=YouP3+eX6z98cVwzkUqvj0Y at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Look guys, somehow we need to cobble up a workflow that works, and
> that even works with profiles generated by standard tools.
> Suggest something! Or else we'll have to go to all-sRGB and
> all-AdobeRGB for consumers.
> 
> Edmund
> 
> 
> On Tue, Jan 25, 2011 at 11:00 PM, Chris Murphy <lists at colorremedies.com> wrote:
>> 
>> On Jan 25, 2011, at 4:00 AM, Graeme Gill wrote:
>> 
>>> Chris Murphy wrote:
>>> 
>>>> Use of the PRMG would be useful here, in theory, because the idea is that the image is
>>>> rendered scene-referred to output-referred once in something like ProPhoto RGB. The
>>>> problem is that Adobe RGB and ProPhoto RGB do not come in v4 versions that make use of
>>>> the PRMG. And then also there are no widely available v4 + PRMG output device profiles.
>>>> So as far as I'm concerned ICC v4 and the PRMG are in a coma for mainstream users.
>>> 
>>> Hmm. I'm don't think that the PRMG helps in any way. You still need to identify
>>> the source gamut. If your source profile is ProPhoto, what gamut is mapped
>>> to the PRMG in the A2B table ?
>> 
>> In the grand v4 + PRMG scheme, it is the source profile's job to map the image to PRMG, and the destination profile's job to map from the PRMG.
>> 
>> But we don't have a v4 ProPhoto RGB, let alone one that describes how ProPhoto RGB images should be mapped to the PRMG. However I've been told this would be almost trivial because ProPhoto RGB is an output medium metric (hence its former name), but the work simply hasn't been done. It's probably Kodak's job to do it but AFAIK there's no interest.
>> 
>> 
>>> If you map the ProPhoto gamut, most images
>>> encoded in that space will end up looking very dull when linked with
>>> (say) a printer profile that then maps from the PRMG to the printer gamut.
>> 
>> Yes, if you use the existing v2 ProPhoto profile, which is why most people end up using RelCol+BPC, rather than bump up saturation in the perceptual intent at the time they build the profile.
>> 
>> 
>> Chris
>> _______________________________________________
>> openicc mailing list
>> openicc at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/openicc
>> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 25 Jan 2011 15:27:24 -0700
> From: Chris Murphy <lists at colorremedies.com>
> Subject: Re: [Openicc] meta data in test chart
> To: openicc Liste <openicc at lists.freedesktop.org>
> Message-ID: <888511DD-6BA5-42C0-90BB-2473B1F66D6F at colorremedies.com>
> Content-Type: text/plain; charset=us-ascii
> 
> 
> On Jan 25, 2011, at 5:16 AM, Scott Geffert wrote:
> 
>> Please consider testing eciRGBv2 as the handoff space. It is v2 and v4 compliant, and is slightly larger gamut than AdobeRGB.  Being L* based it seems more appropriate in this case. It is also being finalized as an ISO TS which fits the open source model better than a "corporate" color space. IMO sRGB limits the gamut as so many devices today are much larger gamut.
> 
> 
> a.) The tone reproduction curve is irrelevant.
> 
> b.) The v4 version of eciRGBv2 doesn't use the PRMG so there's no point in testing it, it will have all the same perceptual weaknesses as any v2 profile does.
> 
> c.) The issue of sRGB's gamut relative to increasingly wider gamut display and print technologies means we shouldn't have intermediate color spaces in the pipeline causing a gamut bottleneck- i.e. normalizing everything into sRGB. I think such a workflow is not ideal, even for consumers, for the reasons I've previously mentioned. But eciRGB also has the same gamut bottleneck issue, so I would not recommend it as an intermediate space in a larger architectural framework for a platform either.
> 
> I don't think we should ask for the building of architectures that are obsolete or that have unnecessary bottlenecks out of the gate. A system wide available intermediate/editing space (as a library that the window server could one day tap into, as well as other applications), I'd propose would be 16bpc or 32bpc (depending on the hardware capabilities) float, and then use Rec 709 primaries. Then it effectively doesn't matter what the source image is, you don't have a meaningful bottleneck (yes you might have a small bottleneck for a 16bpc integer encoded ProPhoto image, being re-encoded as 16bpc floating-point encoded Rec 709/sRGB image but I think that's rather minor.)
> 
> Probably no matter what such things depend on hardware. But building out the least effort for the most performance and quality I think is the goal. I would not take a bet that the "force the hardware to be sRGB" paradigm even applies to mobile for much longer. There's an advantage for manufacturers to be able to have each unit capable of doing display compensation for everything that appears on the display. So a focus on optimization with minimal degradation of image quality for such products I think is inevitable.
> 
> 
> Chris Murphy
> 
> ------------------------------
> 
> Message: 4
> Date: Tue, 25 Jan 2011 15:43:51 -0700
> From: Chris Murphy <lists at colorremedies.com>
> Subject: Re: [Openicc] meta data in test chart
> To: openicc Liste <openicc at lists.freedesktop.org>
> Message-ID: <B7472AA7-07DA-415B-869B-2D659FBA8762 at colorremedies.com>
> Content-Type: text/plain; charset=us-ascii
> 
> I'm still unclear on exactly what aspect of what platform we're talking about. Is this a hypothetical pipeline for Gnome and/or KDE? Or a library that some applications can optionally use? Or just for GIMP? I don't exactly understand what workflow we're discussing as when I think of workflow I think of end-users, not engineers.
> 
> And again, I'd refuse the premise that it must be all-any one particular color space. Just honor the object's source space (or assume sRGB if it's not present) and convert for display and print. No intermediate space. The color space for the window server is "display RGB" and everything is responsible for normalizing to that space.
> 
> If you want to build something more sophisticated, then you could have a separate high-quality pipeline for the window server that's either 16bpc or 32bpc floating point using Rec 709 primaries. After compositing is done, then you get the "right 8bpc" for display* by doing display compensation to "display RGB" which would be the window server itself doing it, not applications using this hypothetical pipeline.
> 
> 
> * Understood that we have a variable bitdepth pipeline to different displays, maybe anywhere from 5bpc to 16bpc.
> 
> Chris Murphy
> 
> 
> On Jan 25, 2011, at 3:18 PM, edmund ronald wrote:
> 
>> Look guys, somehow we need to cobble up a workflow that works, and
>> that even works with profiles generated by standard tools.
>> Suggest something! Or else we'll have to go to all-sRGB and
>> all-AdobeRGB for consumers.
>> 
>> Edmund
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Tue, 25 Jan 2011 23:36:11 +0000
> From: "Alastair M. Robinson" <blackfive at fakenhamweb.co.uk>
> Subject: Re: [Openicc] meta data in test chart
> To: edmund ronald <edmundronald at gmail.com>
> Cc: openicc Liste <openicc at lists.freedesktop.org>
> Message-ID: <4D3F5E6B.2070602 at fakenhamweb.co.uk>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Hi :)
> 
> On 25/01/11 22:18, edmund ronald wrote:
> 
>> Look guys, somehow we need to cobble up a workflow that works, and
>> that even works with profiles generated by standard tools.
>> Suggest something! Or else we'll have to go to all-sRGB and
>> all-AdobeRGB for consumers.
> 
> It seems like we're currently like a bunch of proverbial blind men 
> trying to make a sculpture of a non-existent elephant.  I think we're 
> seeing one of the limitations of using a mailing list for this kind of 
> discussion, because points are being raised, discussed, nearly resolved, 
> and then forgotten as the topic drifts.
> 
> I think we need a Google Docs document or a Wiki page or something just 
> to record the key points as they're discussed and keep track of any 
> consensus that might be reached.
> 
> All the best
> --
> Alastair M. Robinson
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Wed, 26 Jan 2011 00:49:45 +0100
> From: edmund ronald <edmundronald at gmail.com>
> Subject: Re: [Openicc] meta data in test chart
> To: "Alastair M. Robinson" <blackfive at fakenhamweb.co.uk>
> Cc: openicc Liste <openicc at lists.freedesktop.org>
> Message-ID:
> 	<AANLkTim9Mh0wBqJVWBBOLrNiRWZEynXH81-6bRWgxm=h at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Here's a wiki page
> http://www.wiki-site.com/index.php/Linuxcolor
> 
> we could do a group. maybe a Google group?
> we need some drawing ability for flowcharting stuff, maybe
> 
> 
> Edmund
> 
>> It seems like we're currently like a bunch of proverbial blind men trying to
>> make a sculpture of a non-existent elephant. ?I think we're seeing one of
>> the limitations of using a mailing list for this kind of discussion, because
>> points are being raised, discussed, nearly resolved, and then forgotten as
>> the topic drifts.
>> 
>> I think we need a Google Docs document or a Wiki page or something just to
>> record the key points as they're discussed and keep track of any consensus
>> that might be reached.
>> 
>> All the best
>> --
>> Alastair M. Robinson
>> 
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Wed, 26 Jan 2011 10:49:51 +1100
> From: Graeme Gill <graeme at argyllcms.com>
> Subject: Re: [Openicc] meta data in test chart
> To: OpenICC Liste <openicc at lists.freedesktop.org>
> Message-ID: <4D3F619F.5050409 at argyllcms.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Chris Murphy wrote:
>> But we don't have a v4 ProPhoto RGB, let alone one that describes how ProPhoto RGB
>> images should be mapped to the PRMG. However I've been told this would be almost
>> trivial because ProPhoto RGB is an output medium metric (hence its former name), but
>> the work simply hasn't been done. It's probably Kodak's job to do it but AFAIK there's
>> no interest.
> 
> I don't think it would be useful in itself. If you construct a V4 ProPhoto
> profile that maps the ProPhoto gamut to the PRMG in the A2B, you'll end up with
> rather dull images. If you map some other smaller source gamut to the PRMG (say
> an sRGB gamut ??:-), then the advantage of a wide gamut space is thrown away.
> 
> I don't think a wide gamut space can realistically be used as an output medium
> that you render to. Super-wide gamut spaces are often oddly shaped (L*a*b* cube ?),
> and many have impossible (non-real world) colors in their gamut. Inflating an
> images gamut to match the gamut of a large gamut space and then shrinking it
> again when it is rendered to the actual output medium is not going to be a
> hi-fidelity operation. There is no "right way" to map to and from impossible
> color values, since you can't perform the psycho-visual experiments needed to
> figure out what they should map to.
> 
> Conclusion - as soon as you move outside reasonably real world colorspace gamuts,
> relying on the encoding space to signal the gamut of an image is not a viable
> approach. In the future, something like an embedded tag in the image or document
> format that signals the intended or important gamut to render, will become the
> appropriate technical approach. Some sort of dynamic color management
> at the point of rendering into an output media is then desirable.
> 
>> Yes, if you use the existing v2 ProPhoto profile, which is why most people end up using
>> RelCol+BPC, rather than bump up saturation in the perceptual intent at the time they
>> build the profile.
> 
> Unless the image has been blown up to fill the ProPhoto colorspace space, a v4 profile
> that maps to/from the PRMG won't change this.
> 
> Graeme Gill.
> 
> 
> ------------------------------
> 
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
> 
> End of openicc Digest, Vol 58, Issue 43
> ***************************************
> 