[argyllcms] Re: [argyllcms] Re: Camera Profiling using ArgyllCMS

  • From: Nikolay Pokhilchenko <nikolay_po@xxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Fri, 28 Nov 2008 15:31:39 +0300

Graeme Gill wrote:
> I'll have a think about it, but I'm unconvinced. Due to subsequent white
> balancing, there is (typically) no particular relationship between equal
> RGB values in the raw data. The values that make up grey will be at different
> points on the curve for each channel if each channel value is scaled
> by a factor to get white.

There is no channel-different scaling by any factor in RAW data from camera. I 
hope it's possible to setup raw converter parameters to get true equivalence 
between *.tif and RAW data without white balancing, at least for "RGB" sensor 

> In an ICC profile based workflow, the
> RGB values aren't rescaled in any case - the RGB is converted to
> PCS via a chromatic adaptation matrix that maps the chosen white
> (typically the white patch of the test chart) to D50 in XYZ space,
> and then from PCS to the device output space. This process usually
> means that non-equal RGB values map to PCS grey. The device curves of
> the profile are not there just to compensate for device non-linearity,
> they are there to optimise the accuracy and smoothness of the device model.

I think the non-linearity of "RGB" (most likely LMS) data from sensor must be 
compensated before matrix conversion to allow the next conversions to be truly 
additive nor multiplicative. At this step compensation may be equivalent for 
all channels. Can it be implemented in standard ICC profile based workflow? May 
be it's exclusive feature of RAW converter? May the ICC profile based workflow 
do the input curves application before matrix conversion? If so, then the 
switch for equalisation of input curves may be justifiable.

> They in fact have two independent effects for a CLUT profile, firstly
> positioning the grid points in the input space, and secondly affecting
> the way the interpolation behaves within the CLUT cells. The optimum
> values for both of these aspects depends on the related output (PCS) values,
> and therefore may be different for each input channel and for the choice
> of PCS (XYZ or Lab).

Okay, there is no point for channel equalisation at the CLUT step.

> I would have thought that genuine raw output
> wouldn't have any white balancing done to it though.

Generally there is no any white balance or matrix conversions of RAW data in 
cameras. There is just bad pixel mapping only. The RAW format must contain just 
samples from ADC. But there may be problem for certain RAW formats to find a 
RAW converter mode without matrix or shape conversions. Almost all RAW 
converter do the matrix conversions, isn't it? Genuine raw output is 
unacceptable for direct viewing as standard RGB image, but I believe it's the 
best data source for color managed workflow. IMHO, it will be better to 
disjoint geometrical conversion from subpixels to pixels in RAW converter and 
ICC-conversion in CM-software.

Other related posts: