Re: ICC v4
Re: ICC v4
- Subject: Re: ICC v4
- From: Roger Breton <email@hidden>
- Date: Thu, 17 Nov 2005 20:35:44 -0500
I have a feeling that all these gamuts talk all boil down to changing the
colorimetric encoding, just to halt the wholesale waste of PCS space. Isn't
it? The Destination gamut has no clue about the Source gamut: that seems to
me like one of the golden rule of the ICC founders. Wasn't that a limitation
then as it still is a limitation today? Or are you saying that V4 "ICC PCS
reference gamut" has the potential of changing all that?
> "PCS" has a very large gamut. For Lab its 0..100, -128..127, -128..127.
> The XYZ PCS volume is even larger.
It makes me wonder, then, why wasn't Linotype-Hell's own Lab adapted by
everyone when it was still a game in town back in the Linocolor days? At
least, they had the merit of having devised an encoding of Lab that did not
wast as much bits in useless space. So, yes, converting down from LH-Lab did
not waste as much space after all? Linotype was on to a good thing but the
rest of the world did deem wise to follow them? Isn't history dumb.
> If you compress down from there when your actual image occupies a small
> portion of the PCS gamut, your result will be very desaturated indeed.
Of course. No one debates that.
> Most images in output referred colorspaces are assumed to have been
> adjusted to occupy as much of the gamut as possible, because the output
> device is usually limited in its gamut.
400% inks is not such a large volume to encode in, is that what you're
saying? There is very little wasted bits in that "output referred
colorspace", wouldn't you say, if I follow?
> Because of this, it's usually
> reasonable to assume the source colorspace gamut approximates the gamut
> of the image.
This seems to be the same concept that Bruce Lindbloom was pushing for a
long time ago in its "adjusted gamut" size, a size just as big as necessary
to contain the colorspace of some device, like a scanner.
> One of the limits of ICC V2 is that the destination profile
> doesn't usually know the source colorspace.
And I'll bet WCS has a cure for this ill? But ICC V4 too then?
> CIE based and other very wide gamut or scene referred colorspaces
> can't be relied upon to implicitly define an image gamut.
How would you make this process "more explicit"? Or how does V4 helps make
this process more expicit, I should say?
> To map
> images in these spaces to an output device you either need to
> determine the actual images gamut,
Determining the actual image gamut would tighten the encoding around just
the image content, right? Isn't this the same as "adaptative gamut mapping"?
Because I get the feeling, here, that "gamut" and "encoding" are indeed
intertwined in this advanced colorimetric representation.
> have a gamut provided with
> the image (just like an embedded ICC profile),
Like a dictionary that guides the interpretation of the image colorimetry as
opposed to a "static" view as in V2 PCS?
> or use an agreed
> upon gamut (such as the ICC PCS reference gamut, or the scRGB Gamut
> Boundary Definition in the case of scRGB).
OK. Maybe I got ahead of myself: static would be "ICC PCS" or "scRGB"?
> Graeme Gill.
I wish I could have made it to Scottsdale this year. I'm sure you guys had
many interesting conversations.
Roger Breton | Laval, Canada | email@hidden
http://pages.infinit.net/graxx
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
References: | |
| >Re: ICC v4 (From: Graeme Gill <email@hidden>) |