> Thanks... you are correct it doesn't. I was looking at the code for SANE and
> it didn't look like it handled >8bits per color too. There were a couple of
> locations in the frontends where it errored if bit depth was anything
> besides 1 or 8. Oh well... hopefully people will still find use for it
> without such support. I'd still like to know how in the world you would code
> this to be anything besides... swapping bits is kind of strange. So are you
> telling me that for MSB 10bit data you get:
> 98765432 10987654 ... etc
> but for LSB 10bit you get:
> 76543210 98543210 98763210 ... etc.
> or is it
> 76543210 98765432 10987654 ... etc.
No. "packed" modes are violently unpleasant, and while some scanners might
use them to buy some compression, SANE doesn't support any such a format.
A series of three 10-bit samples (e.g. an RGB pixel captured by a one-pass
30-bit parallel port scanner) will arive through SANE as...
98765432 10------ 98765432 10------ 98765432 10------
Or, alternatively (ENDIAN dependence kicks in here)
10------ 98765432 10------ 98765432 10------ 98765432
The ---- sequences will usually be either zero, or copied from the top bits
of the 10-bit sample (explanation a few weeks ago on this list). The
backend should tell you how many bits are "really there" in any case.
You can tell which way around the samples are from the ENDIAN stuff set
by the sender. Your job, as a recipient, is to correct anything which is
"the wrong way around" for your application/ platform.
Note that since the _high_ bits are used, you could assume that you're
always receiving true 16-bit samples. For a simple application (like
photo retouching) this is probably fairly safe.
Nick.
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com