[argyllcms] Re: Black turning down problem (the -r trick)
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Mon, 17 Jan 2011 12:20:33 +1100
Nikolay Pokhilchenko wrote:
OK. It's clear. But the device sampling at target print/measure stage isn't
regular.
There is an optimization by curvature in normal ArgyllCMS workflow. The sample
density
per volume unit can differ significantly between different device space points.
So, the
sampling density is varying and can in some cases overdrive the A2B bandwidth
heavily.
Another pros for filtering after target measuring: If the chart resolution was
insufficient, the harmonics of real device response can aliasing. First of all
they
will affect the high-frequency side of sampled spectrum. So the LPF can help
even in
case of insufficient sampling
Unlike traditional regular sampling (which equates to traditional regular grid
test charts, e.g. "targen -m"), the default OFPS sampling tends to be
stochastic and
irregular. This is an advantage in reducing the chance of aliasing artefacts,
since there is no single sampling frequency to "beat" with.
I have an idea - the patches shouldn't be monotonic ones but should be
gradients. Of
course, such gradient can cover only 2D changes. This approach can help to
filter the
device response in frequency domain.
Intriguing idea, but it has practical problems. To do this really requires a
larger
aperture on the instrument, and better control and repeatability over the area
that
is actually scanned. Unless the variation was on a very fine scale (and then
you're into problems beating with screening), there will be much greater patch
reading repeatability errors.
As Enena mentioned, (here IMHO) the ArgyllCMS in current state will work worse,
when
frequency of sampling increases. I mean the case of sharp bumps. From this
point I
recommend to perform an LPF.
Sorry, I don't follow this logic at all. Increased sampling density around
"sharp"
features will characterise it more accurately. Fewer samples are needed to
characterise slowly changing "smooth" features. The way that targen/ofps
uses curvature to set patch density was tuned to optimise accuracy
of the resulting profiles when measured against actual "known" device behaviour.
By the way, can we filter by splines? If is needed, the profiler can compute
device
response bandwidth, the A2B bandwidth capacity at certain device space point
and select
proper spline order. The filtering will be done automatically without sudden
bumps in
the table.
Sorry, I'm not really understanding this idea.
Graeme Gill.
Other related posts:
