[argyllcms] Re: workflow

> The main trap is the image recognition failing, and bad raster scan
> values being used. The error values at the end of the profile
> creation is a signal that that something like this has happened.

Hello Graeme,

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.)

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?

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, ...

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

> > Suggestions:
> > - add the release number in the archive filemane
> 
> It complicates things a little in creating a release, but
> I'll see what I can do.
> 
> > - use of a top directory for filename in the archive
> 
> I notice that other releases do this sort of thing, but I
> personally find it to be an annoyance. I've already
> created a directory for a project, I don't need yet another
> (usually harder to type!) directory underneath it. Is there
> a compelling argument for arranging things this way ?

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. 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).

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.

Regards,
Gerhard

-- 
SMS bei wichtigen e-mails und Ihre Gedanken sind frei ...
Alle Infos zur SMS-Benachrichtigung: http://www.gmx.net/de/go/sms

Other related posts: