kopia lustrzana https://gitlab.com/sane-project/website
94 wiersze
5.2 KiB
HTML
94 wiersze
5.2 KiB
HTML
<!-- received="Sun Mar 14 16:17:05 1999 PST" -->
|
|
<!-- sent="Sun, 14 Mar 1999 17:08:13 -0700 (MST)" -->
|
|
<!-- name="Andreas Dilger" -->
|
|
<!-- email="adilger@enel.ucalgary.ca" -->
|
|
<!-- subject="Re: 16 bit per sample support" -->
|
|
<!-- id="199903150008.RAA07400@webber.dilger.net" -->
|
|
<!-- inreplyto="36EA3244.22EAAF3C@wolfsburg.de" -->
|
|
<title>sane-devel: Re: 16 bit per sample support</title>
|
|
<h1>Re: 16 bit per sample support</h1>
|
|
<b>Andreas Dilger</b> (<a href="mailto:adilger@enel.ucalgary.ca"><i>adilger@enel.ucalgary.ca</i></a>)<br>
|
|
<i>Sun, 14 Mar 1999 17:08:13 -0700 (MST)</i>
|
|
<p>
|
|
<ul>
|
|
<li> <b>Messages sorted by:</b> <a href="date.html#135">[ date ]</a><a href="index.html#135">[ thread ]</a><a href="subject.html#135">[ subject ]</a><a href="author.html#135">[ author ]</a>
|
|
<!-- next="start" -->
|
|
<li> <b>Next message:</b> <a href="0136.html">Christopher Curtis: "Re: microtek2 driver"</a>
|
|
<li> <b>Previous message:</b> <a href="0134.html">regis rampnoux: "Any development underway for Minolta Scan Dual Dimaage?"</a>
|
|
<!-- nextthread="start" -->
|
|
<!-- reply="end" -->
|
|
</ul>
|
|
<!-- body="start" -->
|
|
Oliver writes:<br>
|
|
<i>> We could define an option the way like the preview option is defined:</i><br>
|
|
<i>> SANE_TRUE=> backend sends not more than 8 bit/sample</i><br>
|
|
<i>> SANE_FALSE=> backend can send more than 8 bits/sample</i><br>
|
|
<i>> or we define an option bit_depht that must be a SANE_CONSTRAINT_WORD_LIST</i><br>
|
|
<i>> so the frontend can simply select "8" (if available) for preview and so on!</i><br>
|
|
<p>
|
|
I would suggest that you specify by bit depth, rather than a boolean option.<br>
|
|
This will allow more flexibility later on I think. If a user specifies, say,<br>
|
|
10 bits/sample and the scanner only supports 8 and 12 bits/sample, then the<br>
|
|
front-end should either dither or simply truncate to the specified depth.<br>
|
|
Another possibility is to only allow the user to select valid bit depths for<br>
|
|
the scanner.<br>
|
|
<p>
|
|
<i>> In the sane api it is not define how bit depths between 8 and 16 bits are</i><br>
|
|
<i>> handled. So if the scanner gives back 12 bpp is this bit 0-11 or bit 5-16</i><br>
|
|
<i>> or does this mean the colors are mixed togeht in some bytes:</i><br>
|
|
<i>> (8 bits red) (4 bits red, 4 bits green) (8 bits green) (8 bits blue) (4 bits</i><br>
|
|
<i>> blue, whats with the rest?)</i><br>
|
|
<p>
|
|
I would suggest that for backends that support > 8 bit/sample output, that sane<br>
|
|
return the data in the high-order bits, and then if you don't need the extra<br>
|
|
bits (eg for display on the screen), you can simply truncate the low-order<br>
|
|
bits and treat it like 8 bits/sample. This is how PNG stores the data, whether<br>
|
|
5 bps or 12 bps -> it only really "stores" either 8 or 16 bits/sample, and<br>
|
|
converts all other bit depths to fit.<br>
|
|
<p>
|
|
<i>> How can the fronten find out how the backend does this?</i><br>
|
|
<i>> Is it ok for a backend to say it is 16 bpp and use bit 5-16 although it</i><br>
|
|
<i>> is only 12 bpp ?</i><br>
|
|
<p>
|
|
If you do it as only 8 or 16 bits/sample as PNG, then the frontend doesn't<br>
|
|
really need to know any other depths than this. You can use "upscale"<br>
|
|
algorithm as PNG does: for bit depths smaller than a full byte, you copy<br>
|
|
the high-order bits into the "empty" bits at the bottom. For example, if<br>
|
|
you have a 5-bit sample with bits "11010" (value = 26 of 31 max), then you<br>
|
|
upshift to a full byte as "11010000" | "110" (original sample left shifted 3,<br>
|
|
logical or with original high 3 bits) = "11010110" = 220. This gives you the<br>
|
|
correct ratio of intensity 26/32 = 220/255, and you can display like a regular<br>
|
|
8-bit image. If you want the original data back, you can just downshift 3<br>
|
|
bits. The same holds true for 16-bit/sample data, where you replicate the<br>
|
|
high bits and then just treat all data like 16-bit/sample images, and you<br>
|
|
don't have to worry whether the data was originally 10-bit or 12-bit or<br>
|
|
16-bit. If you want only 8-bit data, you just discard the low byte.<br>
|
|
<p>
|
|
As a side note, it should be defined whether you have high-byte first (network<br>
|
|
byte order), or low byte first (intel order). I would vote for network byte<br>
|
|
order, since this is the same as PNG, and then you can just dump the data<br>
|
|
into a PNG file.<br>
|
|
<p>
|
|
Cheers, Andreas<br>
|
|
<pre>
|
|
--
|
|
Andreas Dilger University of Calgary \ "If a man ate a pound of pasta and
|
|
Micronet Research Group \ a pound of antipasto, would they
|
|
Dept of Electrical & Computer Engineering \ cancel out, leaving him still
|
|
<<a href="http://www-mddsp.enel.ucalgary.ca/People/adilger/">http://www-mddsp.enel.ucalgary.ca/People/adilger/</a>> hungry?" -- Dogbert
|
|
<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="0136.html">Christopher Curtis: "Re: microtek2 driver"</a>
|
|
<li> <b>Previous message:</b> <a href="0134.html">regis rampnoux: "Any development underway for Minolta Scan Dual Dimaage?"</a>
|
|
<!-- nextthread="start" -->
|
|
<!-- reply="end" -->
|
|
</ul>
|