Re: 16 bit per sample support

Andreas Dilger (adilger@enel.ucalgary.ca)
Mon, 5 Apr 1999 09:25:57 -0600 (MDT)

Jonathon writes:
> 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.

If it is done correctly (ie linearly), there is no problem with extending
the 12-bit data to 16-bit for storage. What you need to do is use a format
like PNG when storing the image, and put in an sBIT chunk, which records the
number of significant bits in the original image (in this case 12), and then
you can always get the original data back if you need to.

If you are doing things like adding images together, just assuming that 12
bits is better than the stored 16 bits is pointless, because if you are
adding more than 16 images or doing other mathematical operations you will
overflow anyways, and you are probably better off using a 32-bit fixed point
representation anyways. The important thing is that you know what bit-depth
the original data was in, and the back-end will know this, and the front-end
should save it. PNG does this, and it is being used for medical image storage.

Cheers, Andreas

-- 
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
http://www-mddsp.enel.ucalgary.ca/People/adilger/       hungry?" -- Dogbert



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