[argyllcms] Re: Calibration + profiling or Profiling only

  • From: Roger Breton <graxx@xxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Sat, 11 Sep 2010 16:09:01 -0400

Janos,

 

Is Rec709 the same as « sRGB »?

 

I think the easiest path to calibration is always the host video adapter
memory.

 

Some ?good? application I know of choose to calibrate the WP using the
monitor?s own LUT but leave the rest to the video LUT (gray balancing and
gamma). On MacOSX, they say they use a ?time-domain? 10-bit dithering?

 

Whichever route you take all *depends* on the combination of monitor,
instrument and software. I have used very good monitorX with softwareY and
instrumentZ with good results. But on monitor, the same software and
instrument combination gave poor results. There are many, many, many
pitfalls. I think you are using a very good analytic approach and I
understand your desire to continuously improve things.

 

In the end, I have use WP edits on many monitors in order to match a
hardcopy image as viewed under lighting ? no matter how good the monitor or
the software or the instrument. If all a user wants and will be happy with,
like me, right now, is to have a reasonably reliable display system, then
leaving most systems to their supposedly calibrated state, however good or
advanced or astute, will do the job. The minute a comparison to some outside
reference is introduced into the process that?s when all hell break loose. 

 

Best regards / Roger

 

 

From: argyllcms-bounce@xxxxxxxxxxxxx [mailto:argyllcms-bounce@xxxxxxxxxxxxx]
On Behalf Of János, Tóth F.
Sent: 11 septembre 2010 14:45
To: argyllcms@xxxxxxxxxxxxx
Subject: [argyllcms] Calibration + profiling or Profiling only

 

I think I can understand color management but I am not a real expert and I
don't have as much real world experience as some of you, so I want to ask
for recommendation.

 

I want to watch Rec709 movies on a wide gamut display with plain tonal
response curve.

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

 

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

 

 

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.

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

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.)

 

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.)

 

There is a chance that one of the three corrections works against the others
and vice-versa. And look it as a complex job with a lot of variable...

 

 

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.

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.

 

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?

Other related posts: