Edmund, Requiring an intermediate handoff space is not the best approach when optimal results are desired. One of the rules of thumb is -- fewer conversions = better. Best regards, Ann McCarthy Imaging Systems R&D Lexmark International, Inc. <table width=100%> <tr valign=top> <td width=40%>edmund ronald <edmundronald@gmail.com> Sent by: openicc-bounces+almccart=lexmark.com@lists.freedesktop.org 01/24/2011 05:10 PM <td width=59%> <table width=100%> <tr valign=top> <td> <div align=right>To</div> <td>Chris Murphy <lists@colorremedies.com> <tr valign=top> <td> <div align=right>cc</div> <td>openicc Liste <openicc@lists.freedesktop.org> <tr valign=top> <td> <div align=right>Subject</div> <td>Re: [Openicc] meta data in test chart</table> <table> <tr valign=top> <td> <td></table> </table> <tt>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@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@lists.freedesktop.org > </tt><a href=http://lists.freedesktop.org/mailman/listinfo/openicc><tt>http://lists.freedesktop.org/mailman/listinfo/openicc > _______________________________________________ openicc mailing list openicc@lists.freedesktop.org </tt><a href=http://lists.freedesktop.org/mailman/listinfo/openicc><tt>http://lists.freedesktop.org/mailman/listinfo/openicc </tt></a></a>