I would suggest that you specify by bit depth, rather than a boolean option.
This will allow more flexibility later on I think. If a user specifies, say,
10 bits/sample and the scanner only supports 8 and 12 bits/sample, then the
front-end should either dither or simply truncate to the specified depth.
Another possibility is to only allow the user to select valid bit depths for
the scanner.
> In the sane api it is not define how bit depths between 8 and 16 bits are
> handled. So if the scanner gives back 12 bpp is this bit 0-11 or bit 5-16
> or does this mean the colors are mixed togeht in some bytes:
> (8 bits red) (4 bits red, 4 bits green) (8 bits green) (8 bits blue) (4 bits
> blue, whats with the rest?)
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.
> How can the fronten find out how the backend does this?
> Is it ok for a backend to say it is 16 bpp and use bit 5-16 although it
> is only 12 bpp ?
If you do it as only 8 or 16 bits/sample as PNG, then the frontend doesn't
really need to know any other depths than this. You can use "upscale"
algorithm as PNG does: for bit depths smaller than a full byte, you copy
the high-order bits into the "empty" bits at the bottom. For example, if
you have a 5-bit sample with bits "11010" (value = 26 of 31 max), then you
upshift to a full byte as "11010000" | "110" (original sample left shifted 3,
logical or with original high 3 bits) = "11010110" = 220. This gives you the
correct ratio of intensity 26/32 = 220/255, and you can display like a regular
8-bit image. If you want the original data back, you can just downshift 3
bits. The same holds true for 16-bit/sample data, where you replicate the
high bits and then just treat all data like 16-bit/sample images, and you
don't have to worry whether the data was originally 10-bit or 12-bit or
16-bit. If you want only 8-bit data, you just discard the low byte.
As a side note, it should be defined whether you have high-byte first (network
byte order), or low byte first (intel order). I would vote for network byte
order, since this is the same as PNG, and then you can just dump the data
into a PNG file.
Cheers, Andreas
--
Andreas Dilger University of Calgary \ "If a man ate a pound of pasta and
Micronet Research Group \ a pound of antipasto, would they
Dept of Electrical & Computer Engineering \ cancel out, leaving him still
<http://www-mddsp.enel.ucalgary.ca/People/adilger/> hungry?" -- Dogbert
--
Source code, list archive, and docs: http://www.mostang.com/sane/
To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com