Following standards (rendering intents)
Following standards (rendering intents)
- Subject: Following standards (rendering intents)
- From: Henrik Holmegaard <email@hidden>
- Date: Mon, 10 Dec 2001 14:06:50 +0100
The gamut compression that occurs in an ICC profile chain is an
aspect of the printer profile, and the gamut compression is not
standardized. Therefore, Adobe cannot make its Color Settings File
technology default to Perceptual and likewise it cannot use Relative
Colorimetric because that is currently implemented in printer
profiles as a proofing intent and not an output intent, which means
that converting from SourceRGB into OutputCMYK with RelCol minus BPC
leads to terrible clipping.
If Black Point Compensation is a non-standard processing
implementation, then it is surely right as diplomatic default for the
source to output step, even if it just as surely wrong for the output
to destination step, because applying it here leads to a soft proof
and a proof print which do not match the output print. This is the
current problem in Adobe software.
I would suppose that Apple cannot just implement a perceptual gamut
mapping, whether the mapping of another company or even a mapping of
its own, as that would raise cries about the Apple CMM favouring its
own gamut mapping ... non-sense or not it'd happen. And Apple
probably did not feel it could implement a non-standard black point
processing, either. This is not a very easy position to be in, and
unless gamut mapping is standardized as some on the ECI list and
other lists I follow suggest, what is there other than a default CMYK
space that maps to L 100 a 0 b 0 and L 0 a 0 b 0 (which I guess this
is why Generic CMYK Profile is implemented like that)?
It is not enough for anybody whether potty freelancer or responsible
color architect to say that everyone must follow the standard,
because as I think Chris Cox said a long time ago, the standard
actually overlooked this situation. In other words following the
standard doesn't work.
In the middle of this stands the user. The problems are what they
are, and nobody can change that overnight or maybe even in years, I
don't know. But is it doable at this stage to tell newbies that they
should use RelCol BPC for SourceRGB to OutputCMYK in a manual
conversion, revisit the Color Settings dialog to uncheck BPC, and
then select RelCol in the Print dialog (a three step workflow)?
Personally, I don't think so because pulling a proof print becomes so
very complex compared to recommending BPC off and Perceptual for
Output followed by RelCol for the proof print and soft proof, but I
may be wrong (as in so many other things, I'm sure).
What I would very much hope for is not so much off-line activity in
standards groups of which we never really hear much, but the opening
up of a discussion of some of these problems to do with profile
chains, however thorny they may be. OK, so they're thorny, but then
so are roses, but that doesn't mean roses should be avoided, does it?
This technology has already made many things much easier then they
once were. And I don't buy the arguments of those who write in
high-end publications that this'll never work. It's easy to poke fun
at ICC workflows, but in an open systems world, what exactly is the
alternative to whisking out the spectro, getting the inkjet and
monitor calibrated and characterized, and pitching into the virtual
color network out there? Closed loop color and manual tweaking? The
open systems world may at this time not be a pretty sight, I agree.
But it will get better with each iteration of the key software, and
meanwhile there is a massive educational problem for users who must
climb aboard and yet fear the consequences and the complexity.
OK, I've had my say. If anybody wants to bash me, please feel free to
do so -:).