kopia lustrzana https://gitlab.com/sane-project/website
78 wiersze
3.5 KiB
HTML
78 wiersze
3.5 KiB
HTML
<!-- 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>> The SANE parameter 'depth' can remain what is currently (ie the native</i><br>
|
||
<i>> depth), and not setting it to 16 for depths>8. Then we don't need a</i><br>
|
||
<i>> 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 >= depth >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>> On the subject of new additions to the SANE standard, perhaps it's</i><br>
|
||
<i>> good to add a SANE_FRAME_RGBI frame format in anticipation of support</i><br>
|
||
<i>> for filmscanners with the Digital ICE feature (it's an extra infrared</i><br>
|
||
<i>> 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>
|