Re: ICC v4
Re: ICC v4
- Subject: Re: ICC v4
- From: Graeme Gill <email@hidden>
- Date: Fri, 18 Nov 2005 19:28:17 -0800
Roger Breton wrote:
The gamut "compression dynamics" are currently set in stone inside profiles,
one-size-fits-all style,
They are set by the B2A table in a V2 profile, and by both the A2B and B2A tables
in a V4 profiles (for perceptual at least).
The way I understand this, in non-technical terms, is that the gamut
compression -- only applicable in my view to the Perceptual intent, in my
view -- is calculated at the time of creating the profile, say in
ProfileMakerPro or Argyll. What this means is that the profiler calculates a
fixed solution from the entire ICC Lab space lattice which has, by
definition, extend all the way from 0 < L* < 100, -127 < a* < +127 and -127
< b* < +127. So it's a fixed transform or rather "mapping" from the whole
PCS Lab to whathever device coordinates like CMYK.
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.
> So you see, in this
scheme of things, the characteristics of either the Source gamut or device
or image never comes into consideration. On the face of it, this idea has
the merit of insuring "blind" exchange and promotes a real modular color
processing which I believe is the cornerstone of the ICC system.
The destination device gamut would always be taken into consideration - it's the
destination device profile that's being created, after all. Unless the profiler
has the facility to be told what the source gamut is going to be (which
Argyll will let you do), it will have to assume some gamut. For V4 profiles,
the PCS reference gamut will be assumed.
whereas, ideally, superior results would come from
a compression procedure established *at conversion time* to tailor the
destination space for each given source image's gamut.
Now, how is that operationalized?
By doing the gamut mapping when the source profile is known (at run time),
rather than when the destination profile is created.
(Does this mean
conversion techniques that better respond to source image characteristics
such as "low-key", or lack of very dark or light colors?)
I think it has the potential of tuning the conversion to the characteristics
of the Source better, indeed, but beats me as to how that's done in
practice. Perhaps Graeme or some other generous soul could shed some light
on this for us mere color mortals? I'm all ears.
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.
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.
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.
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.
Note that even though the V4 specs may not entirely cover it, I suspect
that mapping to/from the PCS reference gamut will help the Saturation intent
work properly, as well as the Perceptual.
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>) |