sane-project-website/old-archive/1999-04/0108.html

78 wiersze
3.5 KiB
HTML
Czysty Zwykły widok Historia

<!-- received="Tue Apr 6 11:23:04 1999 PDT" -->
<!-- sent="Tue, 6 Apr 1999 14:40:51 -0400 (EDT)" -->
<!-- name="Tripp Lilley" -->
<!-- email="tlilley@perspex.com" -->
<!-- subject="Re: 16 bit per sample support" -->
<!-- id="" -->
<!-- inreplyto="19990406145327.A639@bitterling.LeidenUniv.nl" -->
<title>sane-devel: Re: 16 bit per sample support</title>
<h1>Re: 16 bit per sample support</h1>
<b>Tripp Lilley</b> (<a href="mailto:tlilley@perspex.com"><i>tlilley@perspex.com</i></a>)<br>
<i>Tue, 6 Apr 1999 14:40:51 -0400 (EDT)</i>
<p>
<ul>
<li> <b>Messages sorted by:</b> <a href="date.html#108">[ date ]</a><a href="index.html#108">[ thread ]</a><a href="subject.html#108">[ subject ]</a><a href="author.html#108">[ author ]</a>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0109.html">Oliver Rauch: "Re: configuring sane-1.00"</a>
<li> <b>Previous message:</b> <a href="0107.html">Peter Kirchgessner: "HP ScanJet 5100C support wanted"</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>
<!-- body="start" -->
On Tue, 6 Apr 1999, Ewald R. de Wit wrote:<br>
<p>
<i>&gt; The SANE parameter 'depth' can remain what is currently (ie the native</i><br>
<i>&gt; depth), and not setting it to 16 for depths&gt;8. Then we don't need a</i><br>
<i>&gt; new parameter.</i><br>
<p>
Personally, I vote for a separation between "actual" depth and<br>
"transmission" depth. I like the option of writing code driven entirely by<br>
the parameters, and not by "arbitrary" rules about certain parameters. In<br>
this case, overloading 'depth' this way would mean that depth=1 would<br>
imply 1-bit transmission, 8 &gt;= depth &gt;1 implies 8-bit transmission, etc.<br>
But I don't like where that leaves us when we support 24-bit or 32-bit<br>
transmission. I'd prefer if a frontend could be safe just acting on the<br>
data it was given.<br>
<p>
<p>
<i>&gt; On the subject of new additions to the SANE standard, perhaps it's</i><br>
<i>&gt; good to add a SANE_FRAME_RGBI frame format in anticipation of support</i><br>
<i>&gt; for filmscanners with the Digital ICE feature (it's an extra infrared</i><br>
<i>&gt; channel to localize scratches and dust on the film).</i><br>
<p>
If we go this route, may I suggest calling it SANE_FRAME_RGBIR instead?<br>
RGBI already has meaning (RGB+Intensity) in the video world.<br>
<p>
However, it might at this point make sense to revisit the general frame<br>
description mechanism. Something more self-describing, like the way<br>
parameters work, might give us more flexibility in responding to whatever<br>
cool new tricks the imaging device vendors throw at us. But I don't have<br>
any fleshed out ideas :-)<br>
<p>
<pre>
--
Tripp Lilley + Innovative Workflow Engineering, Inc. + (<a href="mailto:tripp@iweinc.com">tripp@iweinc.com</a>)
------------------------------------------------------------------------------
"You know, this /is/ kinda like the community room in a mental ward."
<p>
<pre>
--
Mary Papadopoulos (roommate), commenting on our office/rec room
<p>
<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="0109.html">Oliver Rauch: "Re: configuring sane-1.00"</a>
<li> <b>Previous message:</b> <a href="0107.html">Peter Kirchgessner: "HP ScanJet 5100C support wanted"</a>
<!-- nextthread="start" -->
<!-- reply="end" -->
</ul>