[sane-standard] clarification on image depths

Johannes Berg johannes@sipsolutions.net
Fri, 22 Oct 2004 17:40:54 +0200


--=-DyEWG63OkTfsxTk18ajV
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Hi,

Sorry to be such a pain, I'm trying to understand some of the design
goals of the SANE2 standard.

Today's question is about image depths.

The SANE2 work-in-progress document specifies that only 1,8 and 16 bit
depths are permissible. What is the motivation of this restriction?

If a scanner can only give me 12 bits for each channel, why does SANE
require that the resulting value be scaled up to 16 bits? Wouldn't it be
more accurate in terms of representing the image to the frontend if this
restriction were relaxed, but it be required that the data given by
sane_read be an integral multiple of 8 bits?

Currently, a scanner that scans 12 bits per channel actually sends:
  (*)    XXXXXXXX XXXX0000
because it is scaling up from 12 to 16 bits. If it could specify that it
is actually scanning with 12 bit depth only, it could send
(**)    0000XXXX XXXXXXXX
instead [1], and the frontend might be capable of saving the data in a
format that can represent depths that are not integral multiples of 8.
On the other hand, if the scanner specifies 16 bit as the depth, the
frontend cannot exploit the information that the data consists only of
12 bits and has to use an image format that uses 16 bits. [2]

If the frontend is unable to write an image format capable of specifying
a non-integral multiple of 8 for the depth, it might still scale the
image data up to the next integral multiple of 8.

Also, what point serves the restriction of 16 bits maximum?

[1] of course instead of the representation (**) the representation (*)
could be used as well, but this would probably require shifts in both
the front- and backend if the frontend is capable of handling a 12 bit
format.

[2] Unless the frontend parses the format_desc string, but as I read the
standard this is only informational and shouldn't be used for such
purposes.
[Btw: "an information" is impossible in English because "information" is
uncountable, the "an" should be removed (page 33: "The depth information
does not [...] an information [...]")]

johannes

--=-DyEWG63OkTfsxTk18ajV
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Comment: Johannes Berg (SIP Solutions)

iQIVAwUAQXkqAqVg1VMiehFYAQKbIQ/+JnmTqX77hBWdIminsF6ejIY6gmZxarbq
40vagiuCRUcchbbmcOVdeoxa6ikz++VM9K0NvaqmyvI+0QZKZUlApdku/4xc39S7
0zzb1hddEGXK5lt5n38e+OoOMc8Kj/igo4OHkRZMQt2X9NLv5jYsqDOnDT7JLmQ5
MaPvgGh2xg992TRahoH7c3b8jM9Os3jLkF8njPJWYLfJqJjeitxFY14K/rcRJlwT
ThLMeerE5DGlu3JEOJ913d7vAedDmtXIAtDsgq2ctiCJbNi1xp4lfsVFg00gdrm+
bXpqhJCCcE6pJILkzSIqZDEW5jHgIOOz3+fKRNZnFIWTG5/jBEM9RrH7He6HTrU4
ceQm6uZ9O+Ac2CHeaBRTA9eP+nsRdm5U7B/cO2pHzWtez1vdMaAAdodhCwDbcqMO
lxHXKx/Y3wUFsSm8imkT58RHauDAOsSH++ojdKtbueD4GpLtOtj45vPiSrcVh4Db
twDgiMtGPgEZj0bVXzDIVGdmO1N5r82dZiCmns6HRujkzq0RlLfsNaTNzIIAfU8u
3xqQmhkmvx2ihmo7PdTFoyKvzhkXDRlXzmWVUu0rZ7fJXbIGDFQIIwCh/rcEyxs8
1tQhKHdtGX3gs684Zhh8wNJMFqer+L86uraaveocfHdjrLwWjCklOLboIKPWxxp5
LHXTDPVsgms=
=BdXd
-----END PGP SIGNATURE-----

--=-DyEWG63OkTfsxTk18ajV--