kopia lustrzana https://gitlab.com/sane-project/website
93 wiersze
4.7 KiB
HTML
93 wiersze
4.7 KiB
HTML
<!-- received="Tue Apr 6 13:40:44 1999 PDT" -->
|
||
<!-- sent="Tue, 6 Apr 1999 21:42:06 +0100 (BST)" -->
|
||
<!-- name="Nick Lamb" -->
|
||
<!-- email="njl98r@ecs.soton.ac.uk" -->
|
||
<!-- subject="Re: 16 bit per sample support" -->
|
||
<!-- id="" -->
|
||
<!-- inreplyto="19990406204550.C989@bitterling.LeidenUniv.nl" -->
|
||
<title>sane-devel: Re: 16 bit per sample support</title>
|
||
<h1>Re: 16 bit per sample support</h1>
|
||
<b>Nick Lamb</b> (<a href="mailto:njl98r@ecs.soton.ac.uk"><i>njl98r@ecs.soton.ac.uk</i></a>)<br>
|
||
<i>Tue, 6 Apr 1999 21:42:06 +0100 (BST)</i>
|
||
<p>
|
||
<ul>
|
||
<li> <b>Messages sorted by:</b> <a href="date.html#116">[ date ]</a><a href="index.html#116">[ thread ]</a><a href="subject.html#116">[ subject ]</a><a href="author.html#116">[ author ]</a>
|
||
<!-- next="start" -->
|
||
<li> <b>Next message:</b> <a href="0117.html">Nick Lamb: "Re: 16 bit per sample support"</a>
|
||
<li> <b>Previous message:</b> <a href="0115.html">Tripp Lilley: "Re: 16 bit per sample support"</a>
|
||
<!-- nextthread="start" -->
|
||
<!-- reply="end" -->
|
||
</ul>
|
||
<!-- body="start" -->
|
||
Tripp Lilley (<a href="mailto:tlilley@perspex.com">tlilley@perspex.com</a>) wrote:<br>
|
||
<p>
|
||
<i>> Personally, I vote for a separation between "actual" depth and</i><br>
|
||
<i>> "transmission" depth. I like the option of writing code driven entirely by</i><br>
|
||
<i>> the parameters, and not by "arbitrary" rules about certain parameters. In</i><br>
|
||
<i>> this case, overloading 'depth' this way would mean that depth=1 would</i><br>
|
||
<i>> imply 1-bit transmission, 8 >= depth >1 implies 8-bit transmission, etc.</i><br>
|
||
<p>
|
||
The "arbitrary" rules you despise are laid out in the SANE standard. They<br>
|
||
aren't very taxing, and there has to be some rule, or we end up like TIFF<br>
|
||
with backends offering "13 bit packed BRG data, alternating right-left,<br>
|
||
left-right with 7 bits of packing every third line, negative colour sense"<br>
|
||
<p>
|
||
The SANE standard doesn't "imply" anything from depth, it reflects the<br>
|
||
natural colour depth of the image data only. Most backends choose to use<br>
|
||
a transmission format (controlled as explained by Ewald below) which<br>
|
||
best matches their native colour depth. This is hardly surprising.<br>
|
||
<p>
|
||
On Tue, 6 Apr 1999, Ewald R. de Wit wrote:<br>
|
||
<i>> The transmission width should be calculated from parameters</i><br>
|
||
<i>> pixels_per_line and bytes_per_pixel. If I understand the SANE</i><br>
|
||
<i>> standard correctly, your code must NOT use depth for this.</i><br>
|
||
<i>> For example, my photosmart reports a depth of 10 and sends the data</i><br>
|
||
<i>> in 16 bits - that would certainly confuse your code.</i><br>
|
||
<i>> </i><br>
|
||
<i>> So, there is nothing overloaded, special or arbitrary about 'depth'</i><br>
|
||
<i>> and another parameter 'native_depth' would be redundant, as far as I </i><br>
|
||
<i>> can see anyway.</i><br>
|
||
<p>
|
||
Yes! Almost this entire discussion comes from people who have not read the<br>
|
||
standards document. The SANE documentation has for *ages* described exactly<br>
|
||
how a 12-bit RGB sample should be transmitted to the frontend, including<br>
|
||
"receiver makes right" approach to endian issues.<br>
|
||
<p>
|
||
People, please, rather than say "Oh no! How will SANE handle such-and-such<br>
|
||
a problem" read the documentation first, and if you see something missing<br>
|
||
or unclear, come to the discussion with that. <br>
|
||
<p>
|
||
An example of something which was unclear was - Should the backend leave<br>
|
||
the "spare" bits empty? Ignore them? Stretch the existing bits to fill<br>
|
||
the spare ones? The answer described here (Stretch to maximise dynamic<br>
|
||
range) should probably go into the SANE standard, either as an advisory<br>
|
||
or as a requirement. BUT Even if it does not, a properly written SANE<br>
|
||
frontend can *today* get the true colour depth of a properly written SANE<br>
|
||
backend using the API as written, and extract the 12-bit data from the<br>
|
||
16-bit transmission stream correctly.<br>
|
||
<p>
|
||
Tripp Lilley (<a href="mailto:tlilley@perspex.com">tlilley@perspex.com</a>) wrote:<br>
|
||
<i>> But I don't like where that leaves us when we support 24-bit or 32-bit</i><br>
|
||
<i>> transmission.</i><br>
|
||
<p>
|
||
Oh, it's terrible. We will have to set bytes_per_pixel = 12. I suspect<br>
|
||
that this will be the end of SANE as we know it :)<br>
|
||
<p>
|
||
Nick.<br>
|
||
<p>
|
||
<p>
|
||
<pre>
|
||
--
|
||
Source code, list archive, and docs: <a href="http://www.mostang.com/sane/">http://www.mostang.com/sane/</a>
|
||
To unsubscribe: echo unsubscribe sane-devel | mail <a href="mailto:majordomo@mostang.com">majordomo@mostang.com</a>
|
||
</pre>
|
||
<!-- body="end" -->
|
||
<p>
|
||
<ul>
|
||
<!-- next="start" -->
|
||
<li> <b>Next message:</b> <a href="0117.html">Nick Lamb: "Re: 16 bit per sample support"</a>
|
||
<li> <b>Previous message:</b> <a href="0115.html">Tripp Lilley: "Re: 16 bit per sample support"</a>
|
||
<!-- nextthread="start" -->
|
||
<!-- reply="end" -->
|
||
</ul>
|