Re: ICC v4
Re: ICC v4
- Subject: Re: ICC v4
- From: Roger Breton <email@hidden>
- Date: Fri, 18 Nov 2005 22:51:44 -0500
> I doubt any profiler does that, as it would lead to dreadful images.
> Most profilers would map from a more realistic gamut than the full Lab cube.
Oh! Yes, well, I won't debate the merit of doing so. I wasn't aware of this.
I thought, naively, perhaps. Anyway, you ge the point. But the fact of the
matter remains that, once cast into the form of a lattice, the PCS to Device
is fixed, "pre-baked", and that's what I was trying to convey in my own
words, you know. But I appreciate you straightening me out.
> The destination device gamut would always be taken into consideration - it's
> the
> destination device profile that's being created, after all.
How? I guess that couldn't be done without some kinds of assumptions about
possible Sources. Otherwise, how is the profiler to know?
> Unless the
> profiler
> has the facility to be told what the source gamut is going to be (which
> Argyll will let you do),
Ah ha! You mean to say that it's possible -- let alone, desirable -- to
build the Output profile by telling the profiler about the exact source, as
opposed to assume nothing or some abstract or generic source only known to
the engineers behind the profiling package?
> it will have to assume some gamut.
By gamut I take it that you mean some range of colors in PCS space (XYZ or
Lab) that *define* mathematically an eucledian space or volume that
corresponds to an image or a device? You can't use the word gamut in the
context of V4 specs without clarifying its new meaning.
> For V4 profiles,
> the PCS reference gamut will be assumed.
Oh? Do you mean, then, that in V4 profiles, a provision was created to allow
specifying what is the "reference gamut", whether "PCS" or some "custom"
gamut?
> By doing the gamut mapping when the source profile is known (at run time),
> rather than when the destination profile is created.
You know, that almost sounds like "iterative proof correction", doesn't it?
> There are three ways of doing this within the ICC workflow.
>
> 1) For V2, give the destination profile creator the source gamut
> so that it can create a gamut mapping for the B2A table appropriate
> for the intended source.
Wow! Does not that border on the idea of "intelligent CMMs"?
> 2) Created a device link that uses a process that creates the gamut
> mapping at the time of linking, rather than using the destination
> perceptual B2A table.
OK. I follow. Again, this sounds like the same idea of adaptative approach
or late-binding as opposed to static or early-binding (almost sounds like
object-oriented programming concepts).
> 3) For V4, encode the source profiles gamut -> PCS gamut mapping
> in the source profile A2B table, and the destination profile
> PCS gamut -> destination gamut mapping in the destination
> profile B2A table.
I'll have to re-read this a few times before it sinks in, Graeme. This
implementation looks like the key of that whole new approach.
>>> Also, my understanding is that *the destination gamut itself*, say for a
>>> given paper/printer/ink combination or for a scanner, would *not* be
>>> dynamic, since I assume that a given device's color gamut is more or less a
>>> fixed entity, with possibly only minor variations.
>
> Yes.
So we have flexible Source gamuts but fixed Destination gamuts? I'm still
baffled by how the system is able to dynamically redefine the Source gamut
as a function of the Destination gamut, because that's what it ultimately
boils down to, no?
> Graeme Gill.
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>) |