Hi Gerhard,
Please bear in mind this is still a work in progress. There is almost nothing
on that on open source, so I am still trying to figure out what would be the
"good" way to do things. Black-preserving transforms are not well assessed
by dE metrics. There are some situations where dE is not such important,
and this is one of these.
The chromaticity of the src and dst K-only axis may differ a couple of
dE_ab units. If [0,0,0,K] is mapped to [0,0,0,K'], but e.g.
[0.001,0,0,K] is mapped to [C',M',Y',K'], such that [0.001,0,0,K] and
[C',M',Y',K'] match colorimetrically, doesn't this produce a
discontinuity immediately near the K-only axis? Shouldn't there be done
a smooth blending? (sure, the limited CLUT resolution will smooth the
transition, but is this sufficent?).
Note that a couple of dE in the black ink means a huge tint.
That's very evident because the eye is far more sensitive near neutral
axes than in any other region. If the original separation is correct,
this effect greatly improves overall appearance.
For sure you have seen prints of gray images with a huge
color cast towards magenta or green. That's very unpleasant.
Mainly, this happens because metamerism is not taken into
account when doing the profile. Black ink chromaticity changes on
different illuminants. For example, a profile is done measuring black
ink under D50, then, under D50 this black ink have tendency to
magenta. Ok, the profile captures such chroma and, when
reproducing colorimetrically, replaces the destination black with
CMY reproducing this magenta. Now, If you take the original K ink
and examine it under sunlight, it is not magenta anymore! But the
reproduction using CMY keeps going magenta. Result: a nasty color
cast .
And this is just one of the reasons why keeping black ink is so important.
Maybe there is a slight discontinuity, as big as the chromaticity of
blacks differ, but it is so small that the smoothing induced by the
CLUT is enough to compensate. And this is almost nothing when
compared with the huge cast on grays a CMYK->Lab->CMYK
may create.
If [0,0,0,K] is mapped to [0,0,0,K'] in the destination color space,
shouldn't also [C,M,Y,0] be mapped to [C',M',Y',0], such that [0,0,0,K']
and [C',M',Y',0] (in the destination color space) have the same color as
well?
That's almost the same question. CMY=gray is not maintained anymore, but
a colorimetric match. If you place, side by side, two gray patches; one done
by using equal amounts of CMY and other done exclusively by K ink, then
after a black preserving transform you should end with a patch with same
chromaticity as equal amounts of CMY in the source profile, and a patch
created by using K ink only. To what extent the CMY is still gray... well, it
depends. If the origin profile said a and b were close to zero, you are going to
obtain a,b close to zero on output but only under D50. In real world, most times
illuminants are not D50, and you end with some sort of tint. That doesn't
happen on the K only patch.
Isn't there a risk, that the Newton method gets stuck in a local minimum?
Yes, and it happens. I am still not fully satisfied by the algorithm. It works to
some extent, but misses ink limiting (TAC) preservation. I have to figure out
how to get the TAC from the output profile and how to avoid local minimums
as well.
Best regards,
Marti.
----- Original Message -----
From: "Gerhard Fuernkranz" <[EMAIL PROTECTED]>
To: <lcms-user@lists.sourceforge.net>
Sent: Tuesday, May 24, 2005 1:25 AM
Subject: Re: [Lcms-user] Preview of black preserving feature on CVS
Marti schrieb:
Hi Marti,
a few comments/questions below.
The algorithm is a little bit more complex. Here is a coarse outline:
1) A K tone curve from K-> K' is computed. That is, which amount of K'
on the output space gives same L* as which amount of K in input. That
is done by measuring ramps of (0,0,0, K) using the proof direction,
on both input and output profile. Then joining the obtained curves.
2) The tone curve is used on (0,0,0,K) -> (0,0,0,K') so pure black is
always preserved as pure black.
The chromaticity of the src and dst K-only axis may differ a couple of
dE_ab units. If [0,0,0,K] is mapped to [0,0,0,K'], but e.g.
[0.001,0,0,K] is mapped to [C',M',Y',K'], such that [0.001,0,0,K] and
[C',M',Y',K'] match colorimetrically, doesn't this produce a
discontinuity immediately near the K-only axis? Shouldn't there be done
a smooth blending? (sure, the limited CLUT resolution will smooth the
transition, but is this sufficent?).
Another related issue, where IMO the desired behaviour is not so clear,
and different people may have a different opinion:
Example:
Assume that [0,0,0,K] and [C,M,Y,0] have the same color in the source
color space.
If [0,0,0,K] is mapped to [0,0,0,K'] in the destination color space,
shouldn't also [C,M,Y,0] be mapped to [C',M',Y',0], such that [0,0,0,K']
and [C',M',Y',0] (in the destination color space) have the same color as
well?
Or in other words:
If two (different) CMYK values have the same color in the source color
space, wouldn't one expect, that the colors of the transformed CMYK
values also match in the destination color space?
2) AToBXX tags on output profile are reversed and a special BKToA is
computed. This is a new LUT has a extended PCS using Lab + K.
3) Then a devicelink is built by using the original AtoB plus this new
BKToA. Original K is passed to the extended PCS across tone curve.
The method for inversion is a modified Newton-Raphson extended to 3
dimensions. The original CMY + K across tone curve is used as a seed for
the search. The algorith iterates across Jacobian as far as the error
decreases and the system is convergent.
Isn't there a risk, that the Newton method gets stuck in a local minimum?
This have some nice side effects:
- If the color cannot be matched at all, the original separation is
keept as much as possible.
I've seen, you have again removed the MaximumError threshold and the
different handling below and beyond the threshold. That's IMO good,
since it also did introduce a discontinuity at the threshold.
Regards,
Gerhard
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user
--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 266.11.16 - Release Date: 24/05/2005
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.322 / Virus Database: 266.11.16 - Release Date: 24/05/2005
-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
_______________________________________________
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user
