[argyllcms] Re: Camera Profiling using ArgyllCMS
- From: "Hal V. Engel" <hvengel@xxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Fri, 28 Nov 2008 12:09:30 -0800
On Friday 28 November 2008 04:58:52 Graeme Gill wrote:
> 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.
I had an exchange with the UFRAW author about this subject perhaps a year and
a half ago. The reason I had this exchange was to try to understand what was
happening in the raw processing so that I could understand how to go about
profiling. He told me that the raw process goes something like this:
raw -> white balance* -> bayer integration -> gamma correction -> apply ICC
profile.
* IE. channel-different scaling based on lighting conditions such that the
image will be very close to D50 when it comes out of the bayer integration
process. When I take targets that have been photographed under different but
know lighting conditions (sun light, tungsten ...) and process these through
UFRAW using the corresponding white point setting in UFRAW and then profile
those targets the profiler will say that the white point of the image is near
5000K. I typically see values in the 5100K to 5300K range with my camera
which is a Nikon D70. My brother had a high end Canon DSLR for a while and
when I did the same thing with it and the results were in the 4900K range +-
150K.
UFRAW is based on DCRAW and the DCRAW code base is very widely used. For
example, I know that the raw conversion code in recent versions of Photoshop
are based on DCRAW. So this is likely the best guess at what a "typical" raw
conversion looks like. Like Graeme I am not certain that this is the best
approach to using ICC profiles during the conversion process but it appears
that many of the raw conversion programs are really not designed to use ICC
profiles as part of the basic conversion process. In addition I am not sure
that current targets and profiling processes are suited to creating profiles
that could be used earlier in the conversion process.
>
> > 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:
