Re: ICC v4
Re: ICC v4
- Subject: Re: ICC v4
- From: Steve Upton <email@hidden>
- Date: Sat, 19 Nov 2005 17:39:03 -0800
>
>> 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 think Graeme is referring only to the device gamut which is static in this situation. It's defined by the physics of the destination system and the resulting measurements.
> > 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?
right
> > 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.
I don't follow you here. The definition of gamut is not changed in any way by v4. The main difference is that in v4 a reference gamut is supplied as a standard gamut to map to and from, rather then the profiling software makers choosing their own reference gamuts, not sharing them with the color community and having profiles from different manufacturers not match up when used.
> > 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?
sort of. Actually the reference gamut itself is to be supplied by the ICC. Then there will be one ref gamut available.
> > 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?
but it really doesn't go this far. Keep in mind that gamut mapping HAS to choose some reference gamut because mapping the whole Lab space will just result in very desaturated colors. The reference gamut is just a change in that gamut.
> > 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 because this still happens at profile creation time (if I understand Graeme's example clearly)
> > 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).
again, I don't think this is meant as a dynamic image-time choice but rather a method of creating a better baked-in profile.
> > 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?
yes, but that's how we work right now. The device defines the destination gamut. In our dynamic workflows WE define the source gamut. The problem is that the profile was made without that knowledge so the software used some unpublished gamut as it's source.
>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?
>
nope. There are no dynamics and neither are a function of the destination gamut. I hear what you are saying but it doesn't go quite as far as you are imagining.
hope this helps...
Regards,
Steve
________________________________________________________________________
o Steve Upton CHROMiX www.chromix.com
o (hueman) 866.CHROMiX
o email@hidden 206.985.6837
o ColorGear ColorThink ColorValet ColorSmarts ProfileCentral
________________________________________________________________________
--
_______________________________________________
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>) |