[argyllcms] Re: Black turning down problem (the -r trick)
- From: Nikolay Pokhilchenko <nikolay_po@xxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Sat, 15 Jan 2011 11:28:59 +0300
Sat, 15 Jan 2011 03:15:53 +0100 Gerhard Fuernkranz wrote:
> Am 14.01.2011 20:03, schrieb Nikolay Pokhilchenko:
> > Graeme, I see an analogy with audio analog-to-digital conversion
>
> There is indeed such an alalogy, but...
>
> > (2D quantization - time and amplitude). May be the profiler must
> automatically limit the harmonic spectrum of device response bumps when the
> bumps spectrum is wider than can "digitize" the A2B. There should be the
> Nyquist-Shannon sampling theorem taken in account. I suggest to perform low
> pass filtration (LPF) of device response data before computing of A2B table.
>
> ...when the A2B table is created, it is already too late to apply an
> anti-alias filter. When we reach this stage, the device response _has
> already_ been sampled (at the points corresponding to the the patches on
> the target). The sampling of the device response basically happens when
> you print (and then measure) the target, and not when the A2B table is
> afterwards created from the samples.
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
> But a Nyquist filter must be applied _BEFORE_ sampling. This means you
> would need to install the anti-aliasing low-pass filter _in the device_
> when you print the target, so that the printed target already reflects
> the sampling of the low-pass-filtered device behavior.
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.
> But if you had
> any opportunity to make the device response smoother, then you would not
> have to care any more about high-frequency bumps, because they would
> disappear then anyway. So we rather have to consider the case where the
> device is as is, and you can't change its behavior. In this case you
> can't apply any anti-aliasing filter and the consequence of the sampling
> theorem is that you can only sample at a high enough frequency, greater
> than twice the highest frequency of the bumps in the device response,
> which simply means that you need to use enough patches.
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.
> Sampling at
> higher and higher frequencies may become impracticable though, as CMYK
> space is 4-dimensional, i.e. doubling the sampling frequency requires to
> print and measure 16 times as many patches!
We can work over the targets and measurements with gradiented patches. There
some modification of targen and chartread is needed. The i1 (rev.D) can sample
the patch rater frequently. Every patch is sampled many times by it's lenight
along instrument moving. When patch is a gradient (not very long by physical
lenight and by dE) it's averaged measurement will produce low pass filtering in
one of three dimension (for CMYK). It isn't solve the problem of filtering
completely, but can decrease the order of its complicity.
> Creating the A2B table from the measured patches does not involve any
> sampling, but spline fitting. The sampling theorem does not play a role
> here. What here happens is is actually the opposite of sampling, i.e.
> given a set of discrete samples we try to find a smooth, continuous
> function which approximates the original device behavior. Fitting
> smoothing splines to scattered data does an implied smoothing anyway, so
> I don't see any need for a separate smoothing pass before fitting the
> splines to the data.
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.
Other related posts:
