[argyllcms] Re: Camera Profiling using ArgyllCMS

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Fri, 28 Nov 2008 23:58:52 +1100

Nikolay Pokhilchenko wrote:

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

That may be possible if ICC profiles are not involved. But ICC models all
assume PCS white point relative PCS values, so unless the white point
of the chart happens to be exactly D50, white point adaptation
is part of the device to PCS ICC 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

This only makes sense for an XYZ PCS. An Lab PCS is not additive. It also
confuses the dual effects of the device input curves. The shape of
the device curves in optimising additivity is only effective within
each CLUT cell. The actual location of the CLUT cell boundaries (the
grid mapping) can be set independently of the shape of the curve within
the cells, so the linearity goal actual has no influence over the overall
device curve shape. [If you look closely at some typical Argyll CLUT
device curves you will notice a subtle "scallop" shape which is a result
of optimising the grid location independently of the per cell interpolation.]

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.

It's hard to guess what typical raw tools workflow actually is. Some may
attempt to do white balancing prior to ICC based color space conversion,
although any such variables will tend to invalidate the profile. Personally
I'd be looking at creating a workflow in which the ICC profile
is used to convert the raw input into absolute XYZ space, and
then apply rendering effects such as white balance etc. in XYZ space.
For this purpose, a matrix profile may be a better bet than
typical CLUT profiles, since CLUT profiles may not have the required
accuracy over a raw images full dynamic range.

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.

Hmm. A lot of discussion about RAW gets carried away (IMHO) about the 
distinction
between the raw bayer output and the RGB image. As far as I am concerned it's
pretty meaningless to have a pixel with a certain filter over it, and then
to forget this and treat it as a "non color" pixel. If a pixel has a particular
filter over it, then it is labeled by the color of the filter right from the 
start.

IMHO, it will be better to disjoint geometrical conversion from subpixels to 
pixels in
RAW converter and ICC-conversion in CM-software.

The labeling of pixels with their filter color and possible spatial 
interpolation
is certainly of little interest as far as color is concerned.

Graeme Gill.


Other related posts: