[argyllcms] Re: perceptual black too light

  • From: "Gerhard Fuernkranz" <nospam456@xxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Thu, 16 Feb 2006 01:10:56 +0100 (MET)

> --- Ursprüngliche Nachricht ---
> Von: Graeme Gill <graeme@xxxxxxxxxxxxx>

> But as far as I can tell, this doesn't differ from relative
> colorimetric intent.

If you consider the monitor profile only, it does not differ
from relative colorimetric (at least if you assume that the
monitor observer is adapted to monitor white).

But if you consider the transformation from printer profile to a
monitor profile, then ICC-absoulte is indeed different from relative
colorimetric. Relative colorimetric maps paper white to monitor
white, but ICC-absolute maps the illuminant color (i.e. the color
of an illuminated perfect diffuse reflector) to monitor white, such
that for instance a blue-ish, FWA-rich paper is also simulated with
a slightly blue-ish tint on the monitor.

Furthermore, since paper usually has a reflectance of < 100%, the
luminance of paper white, after transformation to the monitor space,
becomes implicitly lower than the monitor white luminance, which also
helps to reduce out-of-gamut probles if tinted paper white is simulated
on the monitor).

If src and dst illuminant match, then ICC-absolute becomes identical
to the "traditional" interpretation of absolute colorimetric. For
instance in case of a hardcopy proof, where the proof and the final
print are viewed under the same illuminant, it does not make any
difference whether the illuminant relative ICC-absolute intent or
the "traditional" absolute colorimetric intent is used for
computing the proof - both will give the same result.

> > Notice, that the ICC assumption is basically, that the observer
> > of a reflective print is adapted to the _illuminant_ and
> > not to paper white, 
> 
> I can't buy that in reality. If you are not looking at the
> illuminant itself (which you aren't likely to do if you want
> to see anything), then the illuminant has no effect on your
> adaptation unless it is reflected off something.

I'm not sure, what I should believe. On the one hand I tend to agree
with your newspaper example, on the other hand, if I'm viewing a book,
magazine of a sheet of paper in a usual everyday viewing environment
(living room, or maybe also outdoors), i.e. in an environment,
where the sheet of paper is yet another object in the scene, then
I think it is possible to tell whether the paper is rather blue-ish
or yellow-ish, even if neither the light source nor a reference
object with a known white color is visible in the field of view.
So there indeed seem to exist congnitive mechanisms in our vision,
which are able to estimate and discount the illuminant.

Eventually I guess, depending on the actual viewing situation,
the "truth" is likely somewhere in the middle, sometimes closer
to the illuminant color, and in other situations closer to
media white.

(Actually it is even more complicated, since particularly for
larger images, there is not a fixed adaptation state of the
observer, but the observer continuosly readapts, when the
eyes move through the scene (or image) ...)

Regarding your newspaper example, are you sure, that the photos
have been rendered with a perceptual gray axis with paper chromaticity,
or are they probably rendered with a perceptual gray axis with D50
chromaticity, which just bends towards paper white (or actually
paper green) at the upper end?

Btw:

In papers regarding research of chromagenic color constancy
(i.e illuminant estimation) algorithms, Morovic, Finlayson
and Hordley write

"The central area of the human retina - called the fovea - also
uses a filter, the macular pigment. This is the reason why there
are two standard colorimetric observers - 10° and 2°, depending
on the field of vision.

It turns out that the 10° and 2° observer spectral sensitivities
are a chromagenic pair - simulating the human visual system and
using these two observers for the unfiltered RGB and filtered
counterpart, we achieve good illuminant estimation (significantly
better than using other methods)"

See for instance
http://photo.csail.mit.edu/posters/chromagenic.pdf

They don't claim or proof that the illuminat estimation of the
vision actuall does work in this way, but obviously the did a
computational proof of concept, that it could work in this way.

> My analysis (which I commented on on the Lcms list a while ago)
> is that this change in the ICC spec. is not well founded, and I can't
> see it being helpful. In the softproofing situations I'm aware
> of, people really do want an absolute white point (and luminance
> levels too, if possible) match, so that they can compare directly
> to hard proofs.

Agreed, in many situations a side-by-side comparison with a
hard proof is desired, particularly for professional use cases.

With ICC-absolute intent, such an absolute match (for a side-by-
side comparison) can only be achieved with a D50 calibrated monitor
(or in the general case, with a monitor whose WP is calibrated to
the illuminant color used to view the print).

But in less strict situations (where a side-by-side comparison
is not required, and where the monitor WP is not the same as
the viewing illuminant for the print), an approximate appearance
match may be sufficient to get an impression how the print would
look (e.g. to see which colors are clipped on the print), and
particularly for this case I find ICC-absolute not so bad. It's
similar to relcol, though not identical, since additionally,
it does simulate the tint of the paper on the monitor.

> I haven't tested this very much, but I don't think that there's
> a problem (and in fact that the new scheme eliminates the problem you
> mention above, which I think exists in current version.) Because the
> source grey axis is just a point of reference, any reference is
> equivalent. So [0,0,0]..[100,0,0] will also (essentially) be preserved
> in the output.

OK, so you do NOT really split the src -> dst mapping into a
mapping from the (possibly skewed) src gray axis to the non-skewed
PCS [0,0,0]..[100,0,0] gray axis and then from PCS to the (again
possibly skewed) dst gray axis (where only the 2nd part gets
recorded in the B2A0 table), but you rather treat the src profile's
gamut more ore less directly as "PCS gamut", for establishing the
PCS -> dst device gamut mapping.

> Now I'm back to looking at the rspl smoothing factors,
> that, in light of the bumpy CMYK gamut surfaces I'm seeing,
> seem too low in the V0.53 release

Yes that's what I think as well. IMO one needs very accurate
measurements and a very good printer repeatability, in order that
the default smoothness would be appropriate. But since this is
now tunable via command line arguments, this is no longer a big
problem - everybody can now choose his desired smoothness factor.

> (I notice now Gerhard, that you were using "profile -r3" in
> your example a little while back, which is consistent with
> what I'm now noticing.)

I don't remember, which numbers I did use exactly for which data
set. The repeatability of my laser printer is not too good (about
2dE average (or maybe even worse), for a set of CMYK colors
printed several times at different locations on the _same_ page).
So particularly for this printer, the default smoothness is IMO
far too low. But my laser printer is likely not a good general
reference, I think typical inkjets usually behave better.

I've seen, you've added a new option to fakeread to add noise
to the measurements. But it looks like you add uniform random
numbers. I think that gaussian noise would be more appropriate.
I do not want to claim that real measurement and reproducibility
noise is perfectly gaussian, but it has a rather bell-shaped
PDF, not a rectangle. IMO the disadvantage of uniform noise is,
that the max. deviation is strictly limited, while a bell-shaped
PDF also can produce larger outliers (though with correspondingly
low probability), which I think is more realistic.

Regards,
Gerhard

-- 
Gerhard Fuernkranz
nospam456@xxxxxx

Telefonieren Sie schon oder sparen Sie noch?
NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie

Other related posts: