Re: 16 bit per sample support

Ewald R. de Wit (ewald@pobox.com)
Tue, 6 Apr 1999 20:45:50 +0200

Tripp Lilley (tlilley@perspex.com) wrote:

> On Tue, 6 Apr 1999, Ewald R. de Wit wrote:
>
> > The SANE parameter 'depth' can remain what is currently (ie the native
> > depth), and not setting it to 16 for depths>8. Then we don't need a
> > new parameter.
>
> 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 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.

> But I don't like where that leaves us when we support 24-bit or 32-bit
> transmission.

Let that be a problem for the engineers of the USS Enterprise. What we
need now is a standard 16 bit format.

> If we go this route, may I suggest calling it SANE_FRAME_RGBIR instead?
> RGBI already has meaning (RGB+Intensity) in the video world.

Better call it SANE_FRAME_RGBD then, the company that invented it
calls the infrared channel the D channel.

-- 
  --  Ewald

--
Source code, list archive, and docs: http://www.mostang.com/sane/
To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com