[argyllcms] Camera Profiling Ideas [Was: Re: Re: A few questions + an idea for spyd2.c (this time even more useless than before!)]
- From: Andrew Mihal <andrewcmihal@xxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Thu, 12 Mar 2009 12:43:35 -0700
Hi,
On the topic of alternatives to reflective charts for profiling
cameras, how about taking a photograph of the solar spectrum through a
spectroscope? You can use the positions of the absorption lines to
register your image against the well-known solar spectrum and then
compare your image data against the expected intensity of each color.
I think the image at the end of this page would be characteristic of
what you'd get:
http://www.ifa.hawaii.edu/~hodapp/solar-spectroscope-1.html
Does this image look like it would provide valuable data? Can you hack
together a spectroscope of sufficient quality with some razor blades
and a diffraction grating, without the machine shop?
Andrew
On Wed, Mar 11, 2009 at 4:15 PM, Graeme Gill <graeme@xxxxxxxxxxxxx> wrote:
> howdy555@xxxxxxxxx wrote:
>
>> 1) Is there any option that would increase the profile quality even
>> more than -qu? With -qm I get peak err = 2.808569, avg err = 0.511902,
>> with -qu: peak err = 1.891550, avg err = 0.446999, so maybe with -qX
>> (as in eXtreme) I would get 1.50? :). The calculation time with a LUT
>> profile is very reasonable, even for the 'ultra' quality.
>
> It's not clear exactly what your workflow is, or where these
> numbers come from. Are they from colprof ? How many points
> are in your test set ?
> As has been noted, the self fit errors do not give much
> real indication of how accurate a profile, you need independent
> measurements for this. You may well find that the self fit numbers
> get worse as you increase the number of test points used (since the
> profile will be unable to track the noise), even though the accuracy
> of the profile is increasing.
>
> Generally average errors < 1.0 indicate that you are either fitting
> a very small number of points, or are close to the repeatability
> limits of the device/instrument.
>
>> The original implementation makes a weighted average of 2 XYZ values read:
>> the "fast" one (with a very small integration time) and the "slow" one
>
> Actually, the current 1.0.3 release code does something different,
> it does an initial very short reading, and then uses that to scale the
> real reading. I prefer that because it minimized quantization, but
> unfortunately the Spyder3 doesn't cope with the short measurement
> and plays up, hence the change to an incremental scheme.
>
>> - possibly increasing the integration time, with the increase being the
>> weight). This puzzled me as the average is very far from the source of
>> all the errors - the meter's sensors.
>
> Since the sensor readings and XYZ are linearly related (the
> "level 2" correction doing nothing typically for the Spyder 3),
> I'm not sure this makes any difference in itself.
>
>> Therefore I tried a different approach:
>> I averaged the sensor readings and THEN calculated XYZ from the
>> averaged data. The real novelty however is that I allowed ONLY
>> non-zero sensor values into the average. So each sensor "k" has its own
>> "n[k]" and its own "accumulatedValue[k]" (with the result equal to
>> sensor[k] = accumulatedValue[k]/n[k], of course). This makes the
>> problem of "zero XYZ result for non-zero sensor values" much less
>> likely to occur. To get better results, I averaged 4 readings: fast one,
>> moderately slow one and 2 very slow ones.
>
> It's hard to know what's going on in the instrument. The sensors have
> a typical dark frequency of 0.3 Hz, so should produce at least two
> transitions
> in 5 seconds when not illuminated, but this doesn't seem to be the
> case. It does seem reasonable to work at the sensor reading level
> if zero sensor readings are to be detected.
>
>> speed: it is much slower than the original method although I would say
>> it is usable even for monitor calibration. Any further increase in
>> integration time or number of averaged measurements seems to be
>> unacceptable for this purpose though.
>
> I may have more of a play with it, and determine how long the integration
> time needs to be on my instrument to guarantee non-zero sensor readings.
>
>> 3) The camera calibration - this one puzzles me so I would really be
>> grateful for some insights about my wacky idea:
>>
>> Why can't I use my trashy monitor as a calibration target? Why do I
>> have to use expensive calibration targets? If I understand correctly
>
> Pretty much, yes. The reason is that the spectral output shape of
> a monitor is narrow band, since this is the best way of achieving
> a wide color gamut with minimal cost (ie. 3 colorants). The real world
> colors of reflective objects typically the subject of most photography
> have the opposite characteristic of a smoother, broadband spectrum.
> A reflective measurement chart is therefore much more characteristic
> of what the camera is going to be used on, while the spectral
> interaction between a monitor and camera sensor is likely to
> be relatively unpredictable in its correlation to the real world.
>
> You could do something like what you are suggesting, and create
> a profile, but much like using a scanner in place of an instrument,
> you might be disappointed with the result.
>
> Graeme Gill.
>
>
Other related posts:
