[argyllcms] Re: Calibration + profiling or Profiling only

  • From: Florian Höch <lists+argyllcms@xxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Sat, 11 Sep 2010 22:06:11 +0200


Am 11.09.2010 20:44, schrieb János, Tóth F.:
I want to watch Rec709 movies on a wide gamut display with plain tonal
response curve.

I'm not sure I understand what you mean by 'plain tonal response'. Can you elaborate further?

The display has 10 bit panel (internal dithering) and 12 bit controller.
The VGA is able to send out 10 bit/color from it's LUT (ArgyllCMS also
guesses 10 bit after a pre-calibration report) but it works with 8
bit/color framebuffers (right now, deepcolor support is possible in the
not too distant future.)
Which solution sounds better:

First (common/usual):
- WP correction with hardware Gains
- WB and Gamma calibration with VGA LUT
- Profiling

If you can get a reasonable gray balance with hardware gains only and the gamma isn't too far off, you could get away with skipping the VGA LUT calibration.

Second (I have a feeling that it can be better but I am not sure):
- Profiling with untouched hardware RGB Gains and linear VGA LUT

I'd atleast try to get as close as possible to the target by changing the display's hardware settings when using linear VGA LUT.

In the first case, the corrections are scattered.
The hardware Gains will help to get more coherent calibration curves and
I theoretically benefit from the higher bit depth of the display controller.

If the VGA LUT can be kept linear (or near linear), these benefits can be very real (atleast for an 8 bit framebuffer like with most digital connections today).

But the errors and rounding are accumulated as well...

The problem is not rounding, but loosing levels if running out of bit depth. So it's generally advisable to do any corrections in the highest bit depth possible.

The WP is close after the RGB Gain setup but the overall white balance
still needs some corrections. And the curves will cross each others, so
the overall thing needs to be lowered. (After I permanently lost some
contrast ratio and lowered the number of the available shades with the
OSD Gain controls.)

Crossing curves probably hint at a display which does not behave in a very additive/linear way.

And after all of these things, I still need gamut correction. I think it
is a very complex job, so the gamma and white balance are also takes
place in this game. (They all have to be handled together to keep the
desired characteristics.)

I'd really do the whitepoint adjustment with the hardware controls of the display if possible.

There is a chance that one of the three corrections works against the
others and vice-versa.

All three aim towards the same target, so I think it's only a difference how much 'work' each of the three does.

On the second case, I use the 8 bit framebuffers to present everything
but every kind of corrections are made on the same place. Everything is
handled by the color management software. So, it calculates the final 8
bit output values from the input values with the required corrections on
the same place and that's all.

[ originally I was to ask which software, but then I see you mention madVR/yCMS below ]

If gamut correction is as complex as I think, and it really mess with
the WB and gamma, then it can be much better if all of these things are
corrected by a single (but very complex...) software calculation.

Not necessarily. For example, if the whitepoints differ, you can loose a lot of your 8-bit RGB levels just for the whitepoint correction.

And the 8 bit framebuffers contains dithered images. (The software works
with 32 bit PF calculations and uses 16 bit 3DLUTs to create the
dithered image.) [These are madVR+yCMS if somebody know them.]
What do you think?

This is a bit of a special case. Maybe a hardware whitepoint adjustment together with the '3D LUT' of yCMS to do all the remaining work (gamut + tonal response adjustment) is the way to go, given the limitations of 8 bit framebuffers? Hard to tell though, as I didn't use yCMS yet (sounds interesting though).

Florian Höch

Other related posts: