Re: ICC v4, was: Gretag's IQueue 140 not processing correctly with V4 profiles
Re: ICC v4, was: Gretag's IQueue 140 not processing correctly with V4 profiles
- Subject: Re: ICC v4, was: Gretag's IQueue 140 not processing correctly with V4 profiles
- From: Graeme Gill <email@hidden>
- Date: Thu, 17 Nov 2005 11:01:21 -0800
Chris Murphy wrote:
On Nov 16, 2005, at 3:38 PM, Graeme Gill wrote:
Lets say you were using perceptual (because that's where v4 is meant
to make the biggest difference), then for v2->v2 where the v2
destination
profile is set to expect the gamut of the source v2, the results should
be good.
The v2 destination doesn't really expect (explicitly) the gamut of the
source profile in any event. That's a big part of the problem with ICC
v2 is that the destination profile's gamut compression is pre-baked at
the time it's built, rather than being dynamically computed based on
the gamut of the source profile. The gamut mapping for an sRGB image
being converted for a photo inkjet printer (or press) is the same for a
ProPhoto RGB equivalent (i.e. take the sRGB version, convert to
ProPhoto RGB, then convert to printer).
It depends on the profile construction (tools). If I want good reproduction
using V2 and a "dumb" CMM, then I'll make sure that the destination
profile gamut mapping is explicitly configured for mapping the source
profiles gamut. (That's one of the two effective workarounds for the
problems inherent in V2 profiles.)
With v2 it's a crap shoot as to whether you get something reasonable,
or substantially desaturated.
Yes, if you're using externally provided profiles.
If you change this to v2->v4 where the destination v4 is set
to expect the reference PCS gamut (which is quite a bit bigger than many
typical source gamuts), then you might well get a desaturated result.
Perhaps. I was under the impression the reference gamut was output
referred so while it would be bigger than sRGB, it would be no where
near as big as ProPhoto RGB. So maybe the reference gamut isn't output
referred, and it's going to be the job of the CMM and output profile to
do that. If that's the case, yes I'd expect desaturated results.
It is output referred, but it is still much bigger than (say) most
printing gamuts (It seems to be about 20 delta E larger in all
dimensions that a Cromalin proof gamut I compared it to).
It doesn't encompass all of sRGB, but it exceeds it in most
directions by a fair margin. Yes, it's nowhere as large as
ProPhoto RGB. So the results will depend a lot on the gamut
of the V2 source profile. If it's a cmyk input, expect desaturation.
If it's ProPhoto RGB (and the image encoded actually uses the
ProPhoto RGB gamut), expect a fully saturated but clipped result.
The white point handling is different so AbsCol conversions might be
better. I'm curious about comparing v2>v2 and v4>v4 proofing
conversions in this respect. That's something we can do today.
The white point handling is only substantially different for
display profiles, where the display native white point is
no longer regarded as the media white in V4 profiles, but the "illuminant".
I wouldn't expect any noticeable change in handling of white points
for reflective devices for any of the reputable CMMs.
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