Sebastien Sable wrote:
> cbagwell@sprynet.com writes:
>
> > This information is very useful. Do you think we should include it
> > in the snapscan.desc file somehow?
>
> I will put it on the web page when it will be ~complete. Some people
> reported other scanners (by mail to me not to the mailing-list). I
> don't have a report for all the models, but at least those that have
> been reported seem to work.
It might be better to do this now. It might encourage people to provide the
information to fill in the holes.
> > Its described as 48-bits on the box but I downloaded the specs for
> > the scanner chip it uses and it says something about 14 bits only.
> > I'll get back to you on this stuff. It may be more useful to
> > describe the scanners dpi not by model names but the actual optical
> > chip used.
>
> I though there were only 300dpi and 600dpi. Are there really
> resolutions higher than 600dpi or is it just some kind of
> interpolation?
Most of the 300dpi scanner have an actual optiocal resoltionof 300dpi in
width and 600dpi in length. The 600dpi scanners are actually 600dpi in
width x 1200 dpi in length. That asymmetric resolution is common to every
model I know of. Running a 600x1200 scanner as 1200x1200 is quite
meaningful. Beyong that its mostly blur!
> I was pretty sure that I could group all scanners in 3 categories to
> simplify the code, and then I realized, that on top of resolution, bus
> and protocol differences, there was a difference between bits per
> color.
Although the bits per colour varies, the current snapscan software always
reads 8 bits per pixel for full colour scans. The rest are absolbed in
gamma correction. The actual scanning process is almost oblivious to the
number of bits.
Regards,
Steve
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com
This archive was generated by hypermail 2b29 : Fri Nov 03 2000 - 07:19:49 PST