[Openicc] meta data in test chart
Scott Geffert
scottgeffert at gmail.com
Tue Jan 25 04:16:52 PST 2011
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.
On Jan 25, 2011, at 12:47 AM, 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: Print Color Pipeline (Hal V. Engel)
> 2. Re: meta data in test chart (edmund ronald)
> 3. Re: Print Color Pipeline (Richard Hughes)
> 4. Re: Print Color Pipeline (Jon Cruz)
> 5. Re: Communication between Printer Driver and Oyranos
> (Robert Krawitz)
> 6. Re: meta data in test chart (Chris Murphy)
> 7. Re: meta data in test chart (edmund ronald)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 24 Jan 2011 12:41:33 -0800
> From: "Hal V. Engel" <hvengel at gmail.com>
> Subject: Re: [Openicc] Print Color Pipeline
> To: openicc at lists.freedesktop.org
> Message-ID: <201101241241.34299.hvengel at gmail.com>
> Content-Type: Text/Plain; charset="utf-8"
>
> On Monday, January 24, 2011 10:40:42 am Richard Hughes wrote:
>> On 24 January 2011 18:01, Hal V. Engel <hvengel at gmail.com> wrote:
>>> OpenPrinting in conjunction with Peter Skilling (Peter is also the person
>>> who is working with GIMP on it's UI) has a nice printing UI designed as
>>> part of it's Common Printing Dialog project. Unfortunately work on the
>>> CPD is at a standstill because of funding short falls.
>>
>> Right. My personal view is that the open printing stuff needs to be
>> pushed into a proper desktop stack like Qt and/or GTK+, but then I'm a
>> toolkit kinda guy.
>
> I agree with this. Currently the prototype CDP UIs are for KDE including the
> use of some KDE specific widgets and GNOME. I have not looked at the GNOME
> version so I don't know how much of it is making GNOME specific calls. I think
> the correct approach, particularly now that KDE, as of version 4, no longer
> has it's own print dialog (IE. it always uses the Qt print widget/dialog) is
> to stay as DE agnostic as possible. I think the OpenPrinting folks are open
> to going this direction. Having looked at the KDE version the KDE specific
> stuff would only take a few hours of work to replace with Qt widgets.
>
>>
>>> CPD, CUPS and Oyranos/colord need to be considered as a whole since these
>>> need to integrate with each other in order to provide a seamless
>>> printing environment.
>>
>> I think it would make a lot of sense to write a colord<->oyranos shim
>> using DBus so oyranos can talk to colord and vice-versa.
>>
>>> As a side note the CPD also uses DBus.
>>
>> Yes, I think DBus is a very sane dependency, even for embedded use.
>>
>> Richard.
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 24 Jan 2011 23:10:15 +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:
> <AANLkTimwHGvHXyXaRsgP8C2TEuV1ydp72w1fpd3-QG_J at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Chris,
>
> Would you mind making some workflow suggestions? Personally, I like
> the Mac's idea of choosing a handoff space and having a default
> handoff space of sRGB, because it works well for consumers. However it
> created an awful mess when their handoff space changed *from*
> genericRGB, and so it might be better to go straight to a big handoff
> space, maybe with a 16bit default workflow - which Gutenprint can
> easily do, but I think Gimp cannot -yet.
>
> Or maybe one should not have a handoff space at all, and implement
> direct conversion, maybe even with an option of computing the gamut of
> the source image - which seems to be what Graeme suggests.
>
> Your suggestions on architecture would be highly appreciated, I
> believe, by everyone here.
>
> Edmund
>
> On Mon, Jan 24, 2011 at 8:58 PM, Chris Murphy <lists at colorremedies.com> wrote:
>>
>>
>> On Jan 24, 2011, at 5:57 AM, Graeme Gill wrote:
>>
>>>
>>>> The system above is actually not a bad design, but it would be even
>>>> better provided the handoff space were ProfotoRGB (very wide gamut)
>>>> or PRNG (all printable colors), and a 16 bit conversion were
>>>
>>> I'm not sure that's a good idea with current workflows. The reason
>>> is that few if any workflows have, or communicate the concept
>>> of an image gamut. Unlike other smaller gamut color spaces, where
>>> typically the image has been rendered to just fit into that space,
>>> and therefore the colorspace gamut is a reasonable guide to the image gamut,
>>> a very wide gamut space like ProPhoto or L*a*b* cannot be used
>>> as a guide, because the images gamut will almost always be a great
>>> deal smaller than the space it is encoded in.
>>>
>>> The reason this is important is gamut mapping. If an image is to
>>> be mapped well into the destination colorspace, the gamut it
>>> occupies needs to be known or anticipated. If the encoding colorspace
>>> no longer provides that information, where does it come from ?
>>
>> 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.
>>
>>
>> Chris Murphy
>> _______________________________________________
>> openicc mailing list
>> openicc at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/openicc
>>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 24 Jan 2011 18:40:42 +0000
> From: Richard Hughes <hughsient at gmail.com>
> Subject: Re: [Openicc] Print Color Pipeline
> To: "Hal V. Engel" <hvengel at gmail.com>
> Cc: openicc at lists.freedesktop.org
> Message-ID:
> <AANLkTinG-ge-OAtvpzNqeafhdKBjptTcqMdnox33GOLt at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 24 January 2011 18:01, Hal V. Engel <hvengel at gmail.com> wrote:
>> OpenPrinting in conjunction with Peter Skilling (Peter is also the person who
>> is working with GIMP on it's UI) has a nice printing UI designed as part of
>> it's Common Printing Dialog project. ?Unfortunately work on the CPD is at a
>> standstill because of funding short falls.
>
> Right. My personal view is that the open printing stuff needs to be
> pushed into a proper desktop stack like Qt and/or GTK+, but then I'm a
> toolkit kinda guy.
>
>> CPD, CUPS and Oyranos/colord need to be considered as a whole since these need
>> to integrate with each other in order to provide a seamless printing
>> environment.
>
> I think it would make a lot of sense to write a colord<->oyranos shim
> using DBus so oyranos can talk to colord and vice-versa.
>
>> As a side note the CPD also uses DBus.
>
> Yes, I think DBus is a very sane dependency, even for embedded use.
>
> Richard.
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 25 Jan 2011 10:00:27 +1000
> From: Jon Cruz <jon at joncruz.org>
> Subject: Re: [Openicc] Print Color Pipeline
> To: OpenICC Liste <openicc at lists.freedesktop.org>
> Message-ID: <DFC0AC12-273A-4940-9B06-86F89126FDD1 at joncruz.org>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Jan 25, 2011, at 3:39 AM, Kai-Uwe Behrmann wrote:
>
>> Am 24.01.11, 17:02 +0100 schrieb edmund ronald:
>>> You know, maybe the gimp-usability guys have some suggestions here?
>>> I think they're one of the most affected apps for profiled printing.
>>> In fact, one of the big arguments for Linux would be to have a
>>> seamless Gimp setup, equivalent to the seamless Photoshop setup you
>>> get with the Mac.
>>
>> Agreed. Peter Sikking has already prepared ideas for a UI. As it stands now, IMO the common print dialog (CPD) would be the single best controlable entry point for colour management settings.
>> Do plan Krita and Scribus to use that dialog for local printing?
>
>
> I do think this should be taken grain of salt. I'm not sure of the status in recent months, but when I've discussed things with Peter, he seemed to not quite grasp some of the subtle needs of professional printing. Things like artists being able to control overprint, knockout, rich black, etc.
>
> The best thing would be to consider the use cases that showcase the various issues and make sure he can get a good UI to cover all, not just the average end consumer cases.
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 24 Jan 2011 20:22:30 -0500
> From: Robert Krawitz <rlk at alum.mit.edu>
> Subject: Re: [Openicc] Communication between Printer Driver and
> Oyranos
> To: edmund ronald <edmundronald at gmail.com>
> Cc: openicc at lists.freedesktop.org
> Message-ID:
> <201101250122.p0P1MU9U027598 at dsl092-065-009.bos1.dsl.speakeasy.net>
>
> On Mon, 24 Jan 2011 16:37:44 +0100, edmund ronald wrote:
>> Robert,
>>
>> If it is Gutenpprint, the vendor is probably you, or for the profile
>> possibly me.
>> I hope you feel happy with the V-word :)
>> Which is precisely why I'd like to see a good system for
>> user-supplied settings cum profiles.
>
> Very well, everybody's asking me for a proposal...you asked for it :-)
> This isn't even half baked at this point.
>
> I'm going to suggest using the printrc format from the Gutenprint GIMP
> plugin. This is already supported by a GTK+ UI and abstracted into a
> library (I could abstract the printrc format into a library of its own
> if people really want). The ICC profile can be embedded as a "raw"
> data type (uninterpreted, counted string); likewise the skeletal PPD
> file can also.
>
>>>> In this instance, the default vendor supplied profile for the printer
>>>> will be good enough for the 99% of documents the user is going to
>>>> print. For the "birthday present A3 canvas print" they are printing
>>>> it's okay to ask the user to go through the steps detailed above.
>>>
>>> Who's the "vendor" in this case?
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 24 Jan 2011 19:32:09 -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: <0A242538-BF09-4C8D-B4A7-DED7049E038E at colorremedies.com>
> Content-Type: text/plain; charset=us-ascii
>
> I'm unsure of the context, and that makes a big difference.
>
> If we're talking about professional workflows, the image editing portion should be 16bpc float, or 32bpc float, depending on hardware capabilities. Since there is enough precision and it's floating point, the tone reproduction curve doesn't matter, you can define colors inside as well as outside of the sRGB gamut. And then you'd need a means of soft-proofing to an actual output-referred aimpoint, to render the image for that particular gamut and dynamic range. That's presently how we get the best results, specifically because we don't have dynamic gamut mapping, or spacially-variant luminance mapping. Yet.
>
> For everyone else, their images are already output-referred to sRGB, or Adobe RGB. And the workflow I would honor is maintain the image in the space that it's rendered into. I wouldn't do a conversion on an 8bpc Adobe RGB file to sRGB and then display or print it. It's a waste of time, you don't get anything for it. Most of the time the colors are going to be the same anyway.
>
> I think the notion that converting images to sRGB or monitor RGB is kindof a stupid workflow. I know why Microsoft and Apple chose that paradigm. But its flawed because it ignores all kinds of realities about the average user's ambient lighting and surround conditions. No one is getting soft proofing who does not put a lot of effort into it. Dumbing an image down from Adobe RGB to sRGB jto reduce the gamut of the capture a bit so that there's better correlation screen to print I think is a total fantasy. Most real scenes contain colors that happily exist in both sRGB and Adobe RGB (1998). A bigger difference is the quality/consistency of the in-camera rendering into sRGB or Adobe RGB, not the size of the color space itself.
>
> So from those two workflows, just prior to printing you have;
>
> a.) 16bpc floating-point or 32bpc-floating point, sRGB primaries (or whatever)
> b.) 8bpc integer sRGB most likely, maybe 8bpc integer Adobe RGB (1998)
>
> Images conforming to b.) can be printed as is they are, although I'd say there's no compelling reason on most netbook and better hardware to treat all of these images in their original space but drop them into the 16bpc printing pipeline. I wouldn't even bother with the 8bpc pipeline for such hardware. For tablets and phones, OK sure 8bpc print pipeline is the default.
>
> Images conforming to a.) they're going to have to be rendered to output by the application that's editing them; probably best to convert them directly to output space, 16bpc integer encoding; or if a handoff is necessary then 16bpc integer in the widest supported color space.
>
>
> Chris
>
>
> On Jan 24, 2011, at 3:10 PM, edmund ronald wrote:
>
>> Chris,
>>
>> Would you mind making some workflow suggestions? Personally, I like
>> the Mac's idea of choosing a handoff space and having a default
>> handoff space of sRGB, because it works well for consumers. However it
>> created an awful mess when their handoff space changed *from*
>> genericRGB, and so it might be better to go straight to a big handoff
>> space, maybe with a 16bit default workflow - which Gutenprint can
>> easily do, but I think Gimp cannot -yet.
>>
>> Or maybe one should not have a handoff space at all, and implement
>> direct conversion, maybe even with an option of computing the gamut of
>> the source image - which seems to be what Graeme suggests.
>>
>> Your suggestions on architecture would be highly appreciated, I
>> believe, by everyone here.
>>
>> Edmund
>>
>> On Mon, Jan 24, 2011 at 8:58 PM, Chris Murphy <lists at colorremedies.com> wrote:
>>>
>>>
>>> On Jan 24, 2011, at 5:57 AM, Graeme Gill wrote:
>>>
>>>>
>>>>> The system above is actually not a bad design, but it would be even
>>>>> better provided the handoff space were ProfotoRGB (very wide gamut)
>>>>> or PRNG (all printable colors), and a 16 bit conversion were
>>>>
>>>> I'm not sure that's a good idea with current workflows. The reason
>>>> is that few if any workflows have, or communicate the concept
>>>> of an image gamut. Unlike other smaller gamut color spaces, where
>>>> typically the image has been rendered to just fit into that space,
>>>> and therefore the colorspace gamut is a reasonable guide to the image gamut,
>>>> a very wide gamut space like ProPhoto or L*a*b* cannot be used
>>>> as a guide, because the images gamut will almost always be a great
>>>> deal smaller than the space it is encoded in.
>>>>
>>>> The reason this is important is gamut mapping. If an image is to
>>>> be mapped well into the destination colorspace, the gamut it
>>>> occupies needs to be known or anticipated. If the encoding colorspace
>>>> no longer provides that information, where does it come from ?
>>>
>>> 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.
>>>
>>>
>>> Chris Murphy
>>> _______________________________________________
>>> openicc mailing list
>>> openicc at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/openicc
>>>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 25 Jan 2011 06:47:18 +0100
> From: edmund ronald <edmundronald at gmail.com>
> Subject: Re: [Openicc] meta data in test chart
> To: Chris Murphy <lists at colorremedies.com>, Ann L McCarthy
> <almccart at lexmark.com>
> Cc: openicc Liste <openicc at lists.freedesktop.org>
> Message-ID:
> <AANLkTin_2UYHF=6ab4UDh3HhYtwKXUHET514-V10X_2- at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Tue, Jan 25, 2011 at 3:32 AM, Chris Murphy <lists at colorremedies.com> wrote:
>> I'm unsure of the context, and that makes a big difference.
>>
>> If we're talking about professional workflows, the image editing portion should be 16bpc float, or 32bpc float, depending on hardware capabilities. Since there is enough precision and it's floating point, the tone reproduction curve doesn't matter, you can define colors inside as well as outside of the sRGB gamut. And then you'd need a means of soft-proofing to an actual output-referred aimpoint, to render the image for that particular gamut and dynamic range. That's presently how we get the best results, specifically because we don't have dynamic gamut mapping, or spacially-variant luminance mapping. Yet.
>>
>> For everyone else, their images are already output-referred to sRGB, or Adobe RGB. And the workflow I would honor is maintain the image in the space that it's rendered into. I wouldn't do a conversion on an 8bpc Adobe RGB file to sRGB and then display or print it. It's a waste of time, you don't get anything for it. Most of the time the colors are going to be the same anyway.
>>
>> I think the notion that converting images to sRGB or monitor RGB is kindof a stupid workflow. I know why Microsoft and Apple chose that paradigm. But its flawed because it ignores all kinds of realities about the average user's ambient lighting and surround conditions. No one is getting soft proofing who does not put a lot of effort into it. Dumbing an image down from Adobe RGB to sRGB jto reduce the gamut of the capture a bit so that there's better correlation screen to print I think is a total fantasy. Most real scenes contain colors that happily exist in both sRGB and Adobe RGB (1998). A bigger difference is the quality/consistency of the in-camera rendering into sRGB or Adobe RGB, not the size of the color space itself.
>>
>> So from those two workflows, just prior to printing you have;
>>
>> a.) 16bpc floating-point or 32bpc-floating point, sRGB primaries (or whatever)
>> b.) 8bpc integer sRGB most likely, maybe 8bpc integer Adobe RGB (1998)
>>
>> Images conforming to b.) can be printed as is they are, although I'd say there's no compelling reason on most netbook and better hardware to treat all of these images in their original space but drop them into the 16bpc printing pipeline. I wouldn't even bother with the 8bpc pipeline for such hardware. For tablets and phones, OK sure 8bpc print pipeline is the default.
>>
>> Images conforming to a.) they're going to have to be rendered to output by the application that's editing them; probably best to convert them directly to output space, 16bpc integer encoding; or if a handoff is necessary then 16bpc integer in the widest supported color space.
>>
>>
>> Chris
>>
>>
>> On Jan 24, 2011, at 3:10 PM, edmund ronald wrote:
>>
>>> Chris,
>>>
>>> Would you mind making some workflow suggestions? Personally, I like
>>> the Mac's idea of choosing a handoff space and having a default
>>> handoff space of sRGB, because it works well for consumers. However it
>>> created an awful mess when their handoff space changed *from*
>>> genericRGB, and so it might be better to go straight to a big handoff
>>> space, maybe with a 16bit default workflow - which Gutenprint can
>>> easily do, but I think Gimp cannot -yet.
>>>
>>> Or maybe one should not have a handoff space at all, and implement
>>> direct conversion, maybe even with an option of computing the gamut of
>>> the source image - which seems to be what Graeme suggests.
>>>
>>> Your suggestions on architecture would be highly appreciated, I
>>> believe, by everyone here.
>>>
>>> Edmund
>>>
>>> On Mon, Jan 24, 2011 at 8:58 PM, Chris Murphy <lists at colorremedies.com> wrote:
>>>>
>>>>
>>>> On Jan 24, 2011, at 5:57 AM, Graeme Gill wrote:
>>>>
>>>>>
>>>>>> The system above is actually not a bad design, but it would be even
>>>>>> better provided the handoff space were ProfotoRGB (very wide gamut)
>>>>>> or PRNG (all printable colors), and a 16 bit conversion were
>>>>>
>>>>> I'm not sure that's a good idea with current workflows. The reason
>>>>> is that few if any workflows have, or communicate the concept
>>>>> of an image gamut. Unlike other smaller gamut color spaces, where
>>>>> typically the image has been rendered to just fit into that space,
>>>>> and therefore the colorspace gamut is a reasonable guide to the image gamut,
>>>>> a very wide gamut space like ProPhoto or L*a*b* cannot be used
>>>>> as a guide, because the images gamut will almost always be a great
>>>>> deal smaller than the space it is encoded in.
>>>>>
>>>>> The reason this is important is gamut mapping. If an image is to
>>>>> be mapped well into the destination colorspace, the gamut it
>>>>> occupies needs to be known or anticipated. If the encoding colorspace
>>>>> no longer provides that information, where does it come from ?
>>>>
>>>> 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.
>>>>
>>>>
>>>> Chris Murphy
>
>
> Chris,
>
>
> If I understand rightly, you recommend that the workflow breaks down
> into two parallel but separate pipelines, one for pros, and one for
> consumers.
>
> - (CONS) The consumer workflow would be attempting to go with sRGB or
> AdobeRGB and a 16 bit pipeline.
> - (PROF)the pro workflow would be all singing and dancing.
>
> It's 6 in the morning, I'm not sure I'm very good at this :) However,
> I think that
> - (CONS) needs careful future -proofing so it doesn't make implicit
> gamut assumptions, but we have available all the tools to do it. A
> simplified UI is possible at system level because the only *real* user
> decision is the basic workspace, and even that should be hardwired to
> sRGB at distribution installation.
>
> - (PROF) needs some consultation with the GIMP *functionality* guys
> because Gutenprint can now do 16 bits easily, but they cannot provide
> them, and they are going to be necessary or wide-gamut workflows will
> be wrecking images at conversion time.
>
> This just deals with the actual image data being passed around, it has
> nothing to do with print settings or print profiles etc apart from the
> fact that a 16-bit print chain should allow us to solve a lot of fine
> linearisation issues with the dual hammers of ink limitation and
> profiling.
>
> My feeling is that at this point it is getting more and more urgent to
> get the GIMP guys on board. Especially for the (PROF) workflow they
> need to know what is going to be downstream so as to implement profile
> conversions and image write-out with the required bit-depth which is
> going to be essential to the print path.
>
> Edmund
>
>
> ------------------------------
>
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>
> End of openicc Digest, Vol 58, Issue 39
> ***************************************
>
More information about the openicc
mailing list