[argyllcms] Re: Determining proper error value for -r
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Thu, 25 May 2006 22:30:46 +1000
Ben Goren wrote:
> Well, the whole thing is a little "loose", because it's not
> actually that critical in the scheme of things. I calculate the
> average deviation (absolute) as 0.08, 0.02, 0.05 for L, a and b
> respectively. Since the range of L is 0 to 100, this translates
> roughly into a percentage.
Um...I guess what I'm /really/ asking for: what does that mean for
-r? Would it be -r 1, or -r 0.5, or -r 2...?
If you take it literally, -r 0.08, using version 0.54. Using
version 0.53, I'm not sure. -r 0.8 perhaps ?,
Put another way, how does -r relate to standard deviation? Given
the one, how would you convert to the other? Or is that the worng
way to go about it entirely?
The standard deviation is the sort of number a statistical would
want to talk about, because it has meaning to them. I figured
average deviation was easier to calculate. The two are related
by a constant, for a given error distribution.
Average deviation is simple the average of the absolute errors
of each value to their overall mean (got that ?).
What I'm looking at, however, is the case where you've got a
device that needs more leeway than the default (assuming that -r
1.3 won't cut it for, for example, my parents' LaserJet) but don't
want to spend lots of time experimenting to find out what the
optimal value is.
As I indicated, I'd be surprised if you could see much visible
difference varying -r from 0.5 to 2.0 (V0.53). Any difference it makes
is likely to be a couple of delta E somewhere, at the most. For
proofing, it might be worth playing with, but not for a whole
lot else.
There's actually a fair bit of "smarts" in the smoothing factor
as it is (implemented as a table). The actual internal smoothing
factor (for a given -r) is varied with dimensionality (3 or 4
typically), and number of test points. I did rather a lot
of simulation runs to set the table up.
But if a higher default value will work for them and won't
(significantly) hurt everybody else, it's obviously a moot point.
It's all a trade-off. A higher -r value gives a smoother profile. It
also gives greater error between the test points and the profile.
Is that error noise ? - some of it. Some of it is the smoothed
shape of the interpolation not matching the actual shape of the
underlying device response. That's probably an area of research
that is worth going into. One way of telling whether this sort
of thing was going on, would be to create an "error map", that
could be visualized. If the error map is full of fine grained
noise, the errors are random. If there are larger patches
of errors all in a consistent direction, then it a shape fit
problem. profcheck -w attempts to do this type of thing, but the
error vectors really need a direction (some sort of arrow head ?),
and they are difficult to make sense of. Colored slices of the 3D
space might be another way.
Would that be time and resources that us non-C-hackers could help
with? If it means, for example, some grunt work of creating and
measuring charts or hacking together Perl programs or spreadsheets
to analyze them, I'd be more than happy to volunteer. And I won't
complain if it turns out that it's a dead end. Well, not very
loudly, at least.
Perhaps. The real issue is in figuring out an approach to extract real
information from all the randomness implicit in real world measurements.
Graeme Gill.
Other related posts:
