> Personally, I vote for a separation between "actual" depth and
> "transmission" depth. I like the option of writing code driven entirely by
> the parameters, and not by "arbitrary" rules about certain parameters. In
> this case, overloading 'depth' this way would mean that depth=1 would
> imply 1-bit transmission, 8 >= depth >1 implies 8-bit transmission, etc.
The "arbitrary" rules you despise are laid out in the SANE standard. They
aren't very taxing, and there has to be some rule, or we end up like TIFF
with backends offering "13 bit packed BRG data, alternating right-left,
left-right with 7 bits of packing every third line, negative colour sense"
The SANE standard doesn't "imply" anything from depth, it reflects the
natural colour depth of the image data only. Most backends choose to use
a transmission format (controlled as explained by Ewald below) which
best matches their native colour depth. This is hardly surprising.
On Tue, 6 Apr 1999, Ewald R. de Wit wrote:
> The transmission width should be calculated from parameters
> pixels_per_line and bytes_per_pixel. If I understand the SANE
> standard correctly, your code must NOT use depth for this.
> For example, my photosmart reports a depth of 10 and sends the data
> in 16 bits - that would certainly confuse your code.
>
> So, there is nothing overloaded, special or arbitrary about 'depth'
> and another parameter 'native_depth' would be redundant, as far as I
> can see anyway.
Yes! Almost this entire discussion comes from people who have not read the
standards document. The SANE documentation has for *ages* described exactly
how a 12-bit RGB sample should be transmitted to the frontend, including
"receiver makes right" approach to endian issues.
People, please, rather than say "Oh no! How will SANE handle such-and-such
a problem" read the documentation first, and if you see something missing
or unclear, come to the discussion with that.
An example of something which was unclear was - Should the backend leave
the "spare" bits empty? Ignore them? Stretch the existing bits to fill
the spare ones? The answer described here (Stretch to maximise dynamic
range) should probably go into the SANE standard, either as an advisory
or as a requirement. BUT Even if it does not, a properly written SANE
frontend can *today* get the true colour depth of a properly written SANE
backend using the API as written, and extract the 12-bit data from the
16-bit transmission stream correctly.
Tripp Lilley (tlilley@perspex.com) wrote:
> But I don't like where that leaves us when we support 24-bit or 32-bit
> transmission.
Oh, it's terrible. We will have to set bytes_per_pixel = 12. I suspect
that this will be the end of SANE as we know it :)
Nick.
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com