>
> David.Mosberger@acm.org said:
> > This is perfectly well defined in section 3.2:
> > ... Valid bit depths are 1, 8, or 16 bits per sample.
> > If a device's natural bit depth is something else, it is up
> > to the driver to scale the sample values appropriately (e.g.,
> > a 4 bit sample could be scaled by a factor of four to represent
> > a sample value of depth 8).
>
> Possibly depending on the device this should be configurable. If I
> was scanning an X-ray at say 12bits I would be very upset if the backend
> then stretched it to 16bits.
I'm not sure why. The only (small) disadvantage is that there is an increase
in bandwidth from the backend to the frontend. For most users, especially
those looking for maximum performance, this is CPU bandwidth, and thus
very expendable.
There is no data loss (watch this...
0xabc (12bit) --> 0xabca (16bit) --> 0xabc (12bit)
0x123 (12bit) --> 0x1231 (16bit) --> 0x123 (12bit)
All the file formats you're likely to use are either 8-bit (and will lose
the bottom four bits however they're encoded) or 16-bit (and will stretch
anything smaller just as the backend does to fit internal structures).
If you're scanning X rays over a low-bandwidth (say 10Mbit) network and
it sucks to have a 33% longer download time, then run the connection over
a compressed virtual pipe using ssh :)
Nick.
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com