Silverfast Improvements (EPSON 4990)

[ulrichw]

We have been using Silverfast Ai Studio IT8 with our EPSON PERFECTION 4990 for about one year. There were some minor problems and program errors, but most of them could be solved after contacting Silverfast support and/or waiting for an Silverfast update. Overall we are satisfied with Silverfast, its features and the program stability.
But there are still some possible enhancements:

1. Descreening speed-up
The new descreening algorithms are doing a good job - but they are very, very slow. I'm pretty sure that there is a major speed-up possible - such algorithms usually need n*ld(n) time or at least n^2 time (let n be the number of image pixels). Probably the improvement could be done by using other convolution algorithms? Especially large images could profit of such an improvment. We don't use the automatic recognition of screen size.


2. Documentation
The documentation is often not up-to-date - especially after some updates.
Many images show the Mac-version, which often differs from the Win-version.
The IT8 documentation is not very clear (in my opinion).

Thanks
Ulrich


---
Ulrich Wirleitner
IPZ, TU-Graz
Image Processing

[LSI_Marquardt]

Dear Mr. Wirleitner,

the descreening currently operates on scans of at least 600dpi, as this
is a native scanner resolution and a save oversampling factor.
With both these "security" values we are able to avoid moir? in any cases.
The descreen filter is not separable and already SSE/Altivec optimized and therefore there is now way of a speed up besides a smaller matrix or lower scan resolution, which would reduce the quality. Nevertheless we think about a lower quality draft mode for the future.


With best regards,

Philipp Marquardt
LSI Development

[RAG]

LSI Marquardt,

Thanks for the information!

While a speed boost would be nice I prefer high quality. A lower quality draft mode would effectively defeat the purpose for me because I would have to deal with the quality in an image editor such as Photoshop after the scan.

[ulrichw]

Dear Mr. Marquardt!

Thank you for your fast response. When I was talking about a optimal descreening algorithm I did'nt mean optimal coding or compiler set up - like usage of an extended processor code set like SSE, SSE2, Altivec etc. (of course this should be done anyway).
I was talking about using optimal image processing algorithms (i.e. the way you filter or convolute an image).

However. I'm using following descreening procedure:

scanning:

1.) determine original's finest screen size in lpcm (sometimes there are different screen sizes)
2.) screen size [lpi] = screen size [lpcm] * 2.54"
3.) minimum scan resolution [dpi] = screen size [lpi] * 2 (shannon's law)
4.) round up to next native scanner resolution (must be integer dividable by max. scanner x/y-resolution - i.e. max. scanner res. = 1200dpi: /2= 600dpi; /3=400dpi /4=300dpi ...)
5.) scan image at selected (or higher) resolution

Example:
1.) finest screen on original is ~100lpcm
2.) 100lpcm = 254lpi
3.) 254 * 2 = 508dpi
4.) scan with next native scanner resolution = 600dpi

image processing:

1.) possibly filter image (blur or median, small radius or 3x3)
2.) resize image to desired resolution (i.e. resize by integer factor from 600dpi to 300dpi or 200dpi)
3.) if necessary apply USM-filter (small radius)

such image processing algorithms can be calculated within n*log(n) time or in worst case within n^2 time (n=number of pixels).

Of course I can't say anything about Silverfast's descreening technique (and of course you may keep it secret) - but probably it does not differ too much from this procedure. And if this is the case - I'm pretty sure your algorithm can be optimized.

so long for descreening
Ulrich


---
Ulrich Wirleitner
IPZ, TU-Graz
Image Processing