[argyllcms] Re: Calibration issues using argyll
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Thu, 11 Sep 2008 11:38:08 +1000
Peter Karp wrote:
You have not specified which blackpoint setting you have choosen for
the iColor Display calibration. There is one setting to calibrate to
the native blackpoint (meaning as dark as possible) or you can choose
to calibrate to a specific blackpoint luminance with "neutral black".
This setting will use the specified blackpoint and will try to match
the blackpoints color temperature as close as possible to the
whitepoint. This is similar to choose the "blending" in Argyll. But as
Graeme said this is a trade off between a low black point and a more
or less neutral color temperature in the shadows. In my experience a
totally corrected black point is not needed and will result in a too
high black point. "Too high" means here you will loose contrast. You
won't see 1000K higher color temperature in the 0/0/0 black, when a
little above (for non-zero RGB values) you will get close to the white
point color temperature. You could upload or e-mail the generated
profiles and other data files. That might be helpful to find the
reason for your observations.
Yes, this is what the -k parameter is doing in Argyll dispcal. The
-A parameter of version that Steffen is testing, determines the
point and rate at which the aim switches from the white point
hue used over most of the neutral axis, to the native black
point targeted by -k 0.
The calibration matrix used should not make a difference. Your Eizo
uses a "sRGB"-panel type and iColor Display uses the LCD readings from
the SDK. In this case no special calibration matrix is used, but the
default X-Rite factory one for LCDs. I assume that Argyll also uses
the LCD values and neither the raw measuremet data nor the CRT values.
So the instrument readings should be similar.
If iColor is using the instrument SDK, then the Argyll readings
will be very close to identical.
It has some relevance but not in this regard you're trying to
understand. It's a closed loop test and therefore the device will not
tell you "absolute" truth you are looking for here. The test is useful
to some extent, but because you normally won't know if your
colorimeter the use is limited.
Yep, ultimately you need an instrument that you can trust if you
are doing things by the numbers. Spend more money, get a better instrument :-)
I tried the download, but it didn't work (any longer?).
Sorry, I changed the filename when I fixed a bug in it. It's now
<http://www.argyllcms.com/dispcal_win32.zip>
On a related note: One idea I had and always wondered why nobody
seemed to realize (at least AFAIK) is the option to specify for a so
called software calibration (via vcgt) if the calibration curves
should be smoothed, thus giving smoother gradients sacrificing a
little bit of the profile accuracy.
Interesting idea, but it's hard to know if it would be worthwhile.
Certainly the smoothing dispcal applies is varied with the detail
level chosen by -q.
That's the interesting point here. Without having compared both
solutions I guess the reason is the "resolution" (means number of
measurements) in the shadow range which is used as the basis for the
calibration (vcgt) curves.
I suspect that this is the off axis viewing tint effect I mentioned,
exacerbated by trying to set near blacks to the white point hue.
Setting a -A of 3..4 (in the experimental dispcal referred to above,
according to Steffen) appears to reduce this effect. I might
get a chance to test on an Eizo again myself to verify this.
produce a decent smooth gradient IMO. I don't know if Argyll supports
such a smoothing. But you could do this "by hand": read out the vcgt
Yes, there are smoothness and monotonicity constraints applied, but
this can still leave plenty of room for visible banding with
8 bit output. I think I mentioned that my GeForce 8600 GT card
running under MSWindows to a CRT actually has 10 bit table resolution.
Too bad the LCD's can't benefit from this.
Graeme Gill.
Other related posts:
