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

<!-- received="Tue Apr  6 05:03:30 1999 PDT" -->
<!-- sent="Tue, 6 Apr 1999 14:02:24 +0200 (MET DST)" -->
<!-- name="becka@rz.uni-duesseldorf.de" -->
<!-- email="becka@rz.uni-duesseldorf.de" -->
<!-- subject="Re: 16 bit per sample support" -->
<!-- id="199904061202.OAA29719@zeus.rz.uni-duesseldorf.de" -->
<!-- inreplyto="19990406122003.A515@bitterling.LeidenUniv.nl" -->
<title>sane-devel: Re: 16 bit per sample support</title>
<h1>Re: 16 bit per sample support</h1>
<a href="mailto:becka@rz.uni-duesseldorf.de"><i>becka@rz.uni-duesseldorf.de</i></a><br>
<i>Tue, 6 Apr 1999 14:02:24 +0200 (MET DST)</i>
<p>
<ul>
<li> <b>Messages sorted by:</b> <a href="date.html#97">[ date ]</a><a href="index.html#97">[ thread ]</a><a href="subject.html#97">[ subject ]</a><a href="author.html#97">[ author ]</a>
<!-- next="start" -->
<li> <b>Next message:</b> <a href="0098.html">Ewald R. de Wit: "Re: 16 bit per sample support"</a>
<li> <b>Previous message:</b> <a href="0096.html">Ewald R. de Wit: "Re: 16 bit per sample support"</a>
<!-- nextthread="start" -->
<li> <b>Next in thread:</b> <a href="0098.html">Ewald R. de Wit: "Re: 16 bit per sample support"</a>
<li> <b>Reply:</b> <a href="0098.html">Ewald R. de Wit: "Re: 16 bit per sample support"</a>
<!-- reply="end" -->
</ul>
<!-- body="start" -->
Hi !<br>
<p>
<i>&gt; &gt; Er, if I stretch to use the *full* dynamic range this is not the case.</i><br>
<p>
<i>&gt; Does anyone know an efficient algorithm to upsample say 10 or 12 bits</i><br>
<i>&gt; to 16? The example David gave earlier (4-&gt;8 bits) doesn't apply here well.</i><br>
<p>
You duplicate the toplevel bits as appropriate.<br>
<p>
The basic idea is to multiply with a number that is made up like this:<br>
<p>
1.00000000010000000001...<br>
<p>
where the number of zeroes is equal to the number of incoming significant bits<br>
minus 1.<br>
<p>
Let me show that concept in decimal for illustration:<br>
<p>
Say you want to scale values ranging from 0-99 i.e. 2 significant digits.<br>
<p>
You would then multiply with 1.01010101... .<br>
<p>
For say 48 this yields 48.4848484848...<br>
<p>
This takes care to "pad" the number as required for later stretching.<br>
<p>
Now for the streching itself, you usually just shift the position of the<br>
decimal. To stretch say to three digits, you would just shift the<br>
point by one digit and get<br>
<p>
484.84848...<br>
<p>
So converting 12-&gt;16 bit is just a matter of:<br>
<p>
converted=(1.0000000000010000...*old)&lt;&lt;(16-12)<br>
<p>
or rather:<br>
converted=10000.000000010000...*old<br>
<p>
and even faster/simpler:<br>
<p>
converted=(old&lt;&lt;4)+(old&gt;&gt;8)<br>
<p>
The shift values can of course be calculated readily as<br>
<p>
shiftval[n]=(newlen-oldlen)-n*oldlen<br>
<p>
where n ranges from 0 to the point where the shiftval exceeds -oldlen,<br>
thus making the result of old&lt;&lt;shiftval  always zero.<br>
<p>
<i>&gt; I don't understand your aversion against upsampling in general but I</i><br>
<i>&gt; feel too that it should not take place in the backend. IMHO the</i><br>
<i>&gt; backend should just give you the data as the scanner sends it out and</i><br>
<i>&gt; it's the responsibility of the frontend to make sense of it.</i><br>
<i>&gt; Putting it in all the backends would mean more (duplicate) work.</i><br>
<p>
It is trivial, and if done in the backend, you can sometimes make use <br>
of some additional data that would otherwise get lost. This is for example<br>
the case when lossy compression is used in the transmission from the<br>
device (like a camera) to the backend.<br>
Another example would be a device that allows for external multi-pass-<br>
averaging. The averaging algorithm might want to take the properties of<br>
the typical noise that affects the image into account.<br>
<p>
<i>&gt; OTOH it would be nice to have simple access to the deep color data in</i><br>
<i>&gt; a unified 16 bit format. Perhaps in the longer run this would be</i><br>
<i>&gt; better.</i><br>
<p>
This is the idea. Keep the protocol simple for the _general_ case.<br>
<p>
As the stretching algorithm is known, it is simple to undo, if you really<br>
require it.<br>
<p>
For the case of summing/averaging the images, even without first stripping <br>
the streched bits, the added error is 1 LSB max per picture. <br>
<p>
Note that the minimal error of any AD-device is 0.5 LSB, so the effective<br>
added error is 0.5LSB.<br>
<p>
I use high precision DACs and similar devices for optical measurements <br>
almost every day, and I have yet to find a setup, where the digitizing<br>
noise dominates the error bars.<br>
<p>
CU, Andy<br>
<p>
<pre>
-- 
Andreas Beck              |  Email :  &lt;<a href="mailto:Andreas.Beck@ggi-project.org">Andreas.Beck@ggi-project.org</a>&gt;
<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="0098.html">Ewald R. de Wit: "Re: 16 bit per sample support"</a>
<li> <b>Previous message:</b> <a href="0096.html">Ewald R. de Wit: "Re: 16 bit per sample support"</a>
<!-- nextthread="start" -->
<li> <b>Next in thread:</b> <a href="0098.html">Ewald R. de Wit: "Re: 16 bit per sample support"</a>
<li> <b>Reply:</b> <a href="0098.html">Ewald R. de Wit: "Re: 16 bit per sample support"</a>
<!-- reply="end" -->
</ul>