>> I would suggest that for backends that support > 8 bit/sample
>> output, that sane return the data in the high-order bits, and
>> then if you don't need the extra bits (eg for display on the
>> screen), you can simply truncate the low-order bits and treat it
>> like 8 bits/sample. This is how PNG stores the data, whether 5
>> bps or 12 bps -> it only really "stores" either 8 or 16
>> bits/sample, and converts all other bit depths to fit.
Oliver> It does not matter how we define it, there are advantages
Oliver> and disadvantages for both possibilities. The point is that
Oliver> is has to be defined!
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).
Note that, as Andy has pointed out several times, it's best to
scale in a way that preserves the full dynamic range of the
format. E.g., to scale from 4 to 8 bits, multiply by 0x11,
instead of just 0x10. This way, you get mappings like this:
sample scaled
value value
0x0 0x00
0x1 0x11
0x2 0x22
: :
0xf 0xff
--david
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com