[argyllcms] Re: Camera Profiling using ArgyllCMS

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Fri, 28 Nov 2008 16:17:51 +1100

Pascal de Bruijn wrote:
I thought I noticed that as well. But aren't there any conventions
about this? My
guess is most software is written towards use with Adobe's CMM...

The ICC spec. makes a recommendation that CLUT be used before
matrix, but who knows what actually happens with some software.
A CMM or application writer doesn't have to think much about Adobe's CMM,
they just have to make profiles work with their software. As the creator
of profiling software, I haven't thought too much about Adobe's CMM
either - if I'm creating profiles that comply with the ICC spec.,
they are likely to work with Adobe's CMM.

[ I've seen a profile with both matrix and CLUT entries that is
marked as Lab PCS - talk about confusing! ]

Using -a x and -r 2.5 seems to improve the profile quite a bit. Excessively high
values like -r 5 don't seem to make much of an impact either way.

The matrix shaper is the poorest fit to the data, which is not unusual given
the small number of model parameters. When there are few test patches,
or the data is very noisy, a matrix profile may give the best result. It's
certainly best in terms of smoothness.

>>  I know that the author of UFRAW believes that using a single curve for all
>> >> three channels is the correct approach and it appears that authors of
>> >> ProfileMaker agree him.  At some point I will add a switch to LProf to 
allow
>> >> users to

>> I know that the author of UFRAW believes that using a single curve for all
>> three channels is the correct approach and it appears that authors of

Well, I'd love for ArgyllCMS to be able to do this as well, optionally.

Why ? What do you think this will do ?

I've updated my testcase file (it now includes the spectral data (.hist):
http://files.pcode.nl/temp/argyll/canon_eos400d_testcase.zip

How can I determine the correct -r value from the spectral data?

They are nothing to do with each other. The -r value is for
telling the profiler the estimated level of noise and uncertainty
in the patch data. The more uncertainty, the better the result will
be if it is smoothed more.

If the right spectral information is available, it might be possible
to determine if the problem you have is related to spectral considerations.

My procedure for creating the profile is documented here:
http://blog.pcode.nl/2008/11/color-profiling-your-own-dslr-redux

The photos I'm using to subjectively "verify" the profile quality are taken in
unobscured sunlight as well.

It's still unclear what the problem is, since you haven't described it or
given any examples of it.

cheers,
        Graeme Gill.

Other related posts: