[argyllcms] Re: workflow

Gerhard Fuernkranz wrote:
> do you recommend a particular strategy for scanning halftoned
> prints? Do you think it is better to scan at a high resolution,
> such that the dots are visible in the scan, and let scanin do
> the averaging, or rather scan at a very low resolution, hoping
> that the scanner will do a good job for averaging the colors?
> (I've read rumors that some scanners do not really average
> at low resolution, but only return every n-th pixel, which
> would of course not be an optimal behaviour for scanning
> halftones.)

I'm not sure it matter much, since scanning a screening print
with scanin probably has very limited purposes. It's not likely
to be for the purposes of characterizing a scanner, so it's
probably for the purpose of using it as a low quality colorimeter.
In such a case the quality is going to be a compromise, so
does it matter exactly how the screening is dealt with ?

Scanin can trip up on the screening artefacts (it making
it difficult to register the test square edges), so from
this point of view it's best to scan at a lower resolution
(assuming the scanner averages rather than point samples.)

[To be visually correct, averaging would have to be in
a linear color space, but to compute this the response
of the scanner would have to be known.]

> It also looks, like scanin performs a robust averaging of
> the pixel values belonging to a patch. This is likely a good
> thing for scans of a contone target, but is this also appropriate
> for the probability distribution of scanned halftone patterns?
> Aren't for a scanned halftone pattern (which has not yet been
> averaged/blurred) the pixel colors rather distributed as clouds
> around the Neugebauer primaries, such that MOST pixel values
> are far apart from the mean, and rather not distributed
> bell-shaped around their mean value?

Probably, but to solve this problem would be complicated,
and is somewhat far from the intended use of scanin.

> Btw, some time ago I also had recognition problems, though
> I fed a perfect, noise-free image into scanin. The image was
> synthetically generated from a PS file generated by printtarg,
> and "virtually scanned" by a virtual perfect colorimetric
> scanner (i.e. RGB_scanner = XYZ) into a 16bpp linear image.
> Any idea why this did not work? I guess, scanin was not
> able to cope with my virtual scanner's RGB color space.
> But I also encountered recognition problems in the past
> in other situations, e.g. faint printer target from a
> printer in draft mode, ...

It's a tricky problem. I wanted to avoid having to create a
user interaction application to register a standard chart
(Like n IT8.7/2). Under several test scenarios the current
code works extremely reliably, but it still surprises me
at times, when it fails on seemingly simple images. Before
V0.5, I worked on getting a scan of the latest Gretag chart
working, and made several changes to the parameters in the
process. After the release I realized it had broken previously
working cases. The V0.51 release (current) addresses this.
The usual process is to turn on the diagnostic output,
and try and figure which bit is failing.

> Are there some "screws" where one could turn, if scanin
> fails? 

Not in a command line option sense. It would normally
take code changes. Note that a lot of the recognition
code is adaptive, and copes with a wide range of image
variation.

> My experience is, that rather a majority of free software
> I have used, was distributed as <project>-<version>.tar.gz,
> and unpacking the archive resulted in a single subdirectory
> <project>-<version>. I've the impression, in the mean time
> this has established as an unwritten law/convention.

This is so, but I don't find this to be compelling
at present.

 > It also
> looks like in the mean time most free software also uses
> GNU autoconf/automake for cross-plattform building (to be
> honest, I also do not like Jam so much, not necessarily due
> to missing capabilities, but particularly because it is a
> rather unusual tool which nobody else is using, and the
> Argyll Jamfiles never woked for me out of the box on my
> Linux, while "./configure; make; make install" mostly
> worked for other software without needing manual changes).

Sure, but the GNU tools don't come standard on Windows, and
(by many accounts) autoconf etc. is unreasonably complicated to
setup and maintain. Jam is small and self contained, while
installing all the GNU tools is big.

Jam showed some potential to make things simpler (and it
generally does for me. Most of the Jamfiles work unchanged
in different environments without any changes), but it
hasn't quite lived up to the early promises. I did
spend some time a few years ago modifying Jam to try and
overcome many of its drawbacks, but wasn't entirely happy with
the result.
I really can't be bothered fiddling with this aspect
of the project when there is no good replacement build
system currently available, and far too much else to do in Argyll.
Oden comes close, but it's strictly UNIX.
SCons is interesting, but it is still stuck in the
poorly structured top-down paradigm that afflicts Make.

> IMO the drawback of an archive with no top-level directory
> is, that it completely "pollutes" the current directory with
> many files and subdirectories, if it is accidentally unpacked
> in a non-empty diretory, without explicitly creating and chdir
> to a subdirectory first. If a top-level directory is present
> in the archive, the "pollution" consists of only a single
> subdirectory, which can be easily (re)moved.

Agreed. I generally take a quick look at an archive before
unzipping it, for this reason. Also to make sure it won't
overwrite anything unexpected.

Graeme Gill.

Other related posts: