[argyllcms] Re: DeviceLink Profile refining
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Fri, 16 Feb 2007 12:17:52 +1100
Thanks Gerhard, for illustrating one of the main issues with the
whole idea of trying to improve a profile.
The damping factor parameter in refine is meant to be a tool to help
deal with repeatability errors, as it applies a "moving average" type
effect over the successive rounds of improvement, as well as (hopefully)
damping out wild behavior that could result from applying feedback to
an unknown response system.
There are some ironies of the whole idea of refining a profile when it is
a not very repeatable system. One is that if you based the initial profile
on a measurement of a chart sized X, and then try and improve it by refining
it with n measurements of a chart sized X, you might in fact have got a better
result by simply using a chart sized (n+1) * X in the first place, or averaging
(n+1) X sized charts results for making the first profile.
If (using whatever method) you get a statistically good fit for the profile
of the behavior for the system having measured n * X charts, the results you get
from any particular sample print may appear to have almost as high errors as
the result you would have got profiling 1 * X charts, simply because the
apparent error is dominated by the repeatability of the system.
The idea of refine does go a bit beyond the above issues though. It attempts
to deal with the end to end system errors, which the individual tables
in a profile and/or link don't see, as well as concentrating specifically
on getting an accurate result for certain nominated colors. You can't
get away from the repeatability effects though, once other errors have
been reduced sufficiently.
Btw, Graeme, it might also be interesting if verify had an option to
print the error summary excluding out-of-gamut patches, since they are
to be considered as outliers, which cannot be corrected anyway. Thus
they obfuscate how well the refinement works for correctable in-gamut
patches. In the -v output, they could possibly be marked as out-of-gamut
too. I just don't know whether this would be easy to implement?
Right. I'll see what I can do. One of the issues with trying to treat
gamut color specially, is that if the device is truly behaving differently
to what the profile has captured, then you can't be sure whether the in/out
of gamut test is returning a true result :-)
Graeme Gill.
Other related posts:
