Re: ICC v4
Re: ICC v4
- Subject: Re: ICC v4
- From: Graeme Gill <email@hidden>
- Date: Sat, 19 Nov 2005 18:30:35 +1100
Roger Breton wrote:
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?
I don't know how much more plain I can be Roger. If the destination
profile is being created, then the gamut of the destination device
is available from the device information being used to create the
destination profile, so of course it will be taken into account
in creating the B2A table gamut mapping, irrespective of where
the source gamut comes from.
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?
Yes, this works quite well in a conventional ICC V2 workflow, if the
source profile is fixed, or going to be from a group of profiles
with similar color gamuts. Of course if there were a small group
of source profiles, then a matching number of destination profiles
tuned up for those sources could be created. This is all really
a workaround for systems that can't handle device link profiles.
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.
Well, I hardly see that the existence of ICC V4 changes the meaning
of "color gamut". It means what it's always meant.
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?
I wouldn't imagine most V4 compliant profiles would work that way. They
will probably silently use the PCS reference gamut, just like they've
silently used some other unknown (to the user) gamut in the past when
generating V2 profiles. The other thing they will do for V4 of course
is create a gamut mapping in the A2B table _to_ the PCS reference 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?
Um - no, no connection.
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"?
No. Just making the destination profile "tuned" for a particular
intended workflow.
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).
It's simply "smart CMM" operation.
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.
This is the key to ICC V4. It's nothing that complicated really. Instead of
PCS being (basically) an encoding space, it's now being treated as a full
"image appearance" space, that includes a gamut. By passing through the
PCS reference gamut, the source to destination gamut mapping is
achieved without either the source or destination having to
be aware of each other.
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?
No, you're completely off the track. The source gamut is only
dynamic in the sense of choosing a source profile is dynamic.
Destination gamuts are just as "dynamic" - you can choose from
destination profiles.
I don't know what you mean by "redefine the Source gamut as a
function of the Destination gamut".
Gamut mapping maps from a source gamut to a destination gamut.
To create the mapping, a source gamut and destination gamut
need to be available or assumed.
Graeme Gill.
_______________________________________________
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: Roger Breton <email@hidden>) |