> > Er, if I stretch to use the *full* dynamic range this is not the case.
> Does anyone know an efficient algorithm to upsample say 10 or 12 bits
> to 16? The example David gave earlier (4->8 bits) doesn't apply here well.
You duplicate the toplevel bits as appropriate.
The basic idea is to multiply with a number that is made up like this:
1.00000000010000000001...
where the number of zeroes is equal to the number of incoming significant bits
minus 1.
Let me show that concept in decimal for illustration:
Say you want to scale values ranging from 0-99 i.e. 2 significant digits.
You would then multiply with 1.01010101... .
For say 48 this yields 48.4848484848...
This takes care to "pad" the number as required for later stretching.
Now for the streching itself, you usually just shift the position of the
decimal. To stretch say to three digits, you would just shift the
point by one digit and get
484.84848...
So converting 12->16 bit is just a matter of:
converted=(1.0000000000010000...*old)<<(16-12)
or rather:
converted=10000.000000010000...*old
and even faster/simpler:
converted=(old<<4)+(old>>8)
The shift values can of course be calculated readily as
shiftval[n]=(newlen-oldlen)-n*oldlen
where n ranges from 0 to the point where the shiftval exceeds -oldlen,
thus making the result of old<<shiftval always zero.
> I don't understand your aversion against upsampling in general but I
> feel too that it should not take place in the backend. IMHO the
> backend should just give you the data as the scanner sends it out and
> it's the responsibility of the frontend to make sense of it.
> Putting it in all the backends would mean more (duplicate) work.
It is trivial, and if done in the backend, you can sometimes make use
of some additional data that would otherwise get lost. This is for example
the case when lossy compression is used in the transmission from the
device (like a camera) to the backend.
Another example would be a device that allows for external multi-pass-
averaging. The averaging algorithm might want to take the properties of
the typical noise that affects the image into account.
> OTOH it would be nice to have simple access to the deep color data in
> a unified 16 bit format. Perhaps in the longer run this would be
> better.
This is the idea. Keep the protocol simple for the _general_ case.
As the stretching algorithm is known, it is simple to undo, if you really
require it.
For the case of summing/averaging the images, even without first stripping
the streched bits, the added error is 1 LSB max per picture.
Note that the minimal error of any AD-device is 0.5 LSB, so the effective
added error is 0.5LSB.
I use high precision DACs and similar devices for optical measurements
almost every day, and I have yet to find a setup, where the digitizing
noise dominates the error bars.
CU, Andy
-- Andreas Beck | Email : <Andreas.Beck@ggi-project.org>
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com