Re: 16 bit per sample support

Jonathan A. Buzzard (jab@hex.prestel.co.uk)
Sun, 04 Apr 1999 17:13:40 +0000

njl98r@ecs.soton.ac.uk said:
> >Possibly depending on the device this should be configurable. If I
> >was scanning an X-ray at say 12bits I would be very upset if the
> >backend then stretched it to 16bits.
>
> I'm not sure why. The only (small) disadvantage is that there is an
> increase in bandwidth from the backend to the frontend. For most
> users, especially those looking for maximum performance, this is CPU
> bandwidth, and thus very expendable.
>
> There is no data loss (watch this...
> 0xabc (12bit) --> 0xabca (16bit) --> 0xabc (12bit)
> 0x123 (12bit) --> 0x1231 (16bit) --> 0x123 (12bit)

Because you have mugged the values. X-rays where only an example, but the
same could be said of other sources such as aerial photography etc.
With these sorts of things you often want to do calculations on the
scanned images.

For example I might have three Xrays of an object, that after some sort
of registration I wish to stack on top of one another. The Xrays have
been scanned say at 12 bits, now if you have stretched them though to
the full dynamic range of 16 bits adding the pixel values together
will result in loss of information. If they had stayed as 12 bits inside
a 16 bit value there is no problem.

These are dozens of similar cases where stretching the values is simply
not acceptable. A little check button somewhere which can be unchecked
for those that don't want stretching would suffice.

JAB.

-- 
Jonathan A. Buzzard                 Email: jab@hex.prestel.co.uk
Northumberland, United Kingdom.       Tel: +44(0)1661-832195







--
Source code, list archive, and docs: http://www.mostang.com/sane/
To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com