Johan-
It seems that if you collect the information in 12 bits, all you need do is store the original in its format.  Then you can derive any 8-bit version you need for a specific purpose.  I think you forgot to mention there is a problem with where the high bits and low bits are when stepping down the size to 8 bits, so it really is essential to be able to access the original version again.
carol
Center for Microscopy & Microanalysis
Bowling Green State University
________________________________________
From: Confocal Microscopy List [[log in to unmask]] On Behalf Of Johan Henriksson [[log in to unmask]]
Sent: Tuesday, February 03, 2009 4:23 PM
To: [log in to unmask]
Subject: in the swamp of pixel formats - what is the future?

I'm in the midst of finally deciding how to deal with different pixel
formats in my program (eg 8bit, 16bit). it's a pain-staking trade-off
and I wish to start a discussion here to get the best result. I am
grateful for responses from both users and commercial/open source
developers.

one one hand: performance is higher if the right format is used. 8bit
takes half the memory of 16bit, transfer is 100% faster.

on the other hand: we have unsigned 8bit, 12bit, 16bit, 32bit, signed
8bit, 12bit, 16bit, 32bit, float, double, 8bit palette color, 5+6+5
packed color, HD formats etc.

that's 10+ formats!! if you write an algorithm, you need to produce 10
versions of it. sometimes conversion is needed with potential loss of
information. for every format we can slay, complexity is reduced. less
complexity means fewer bugs and more features faster.

so what are everyones position on this? here is mine:

* the need of easy scientific manipulation is totally separate from fast
rendering. packed formats and other arcane solutions belong in games only.
* we need floating point for calculations. having both float and double
is a minor complication since the range is "virtually the same".
* we need integers because algorithms like levelsets are based on a
proper ordering of numbers. it's possible but hard to do in floating
point. storage of common images is simplified in integer since many
compression algorithms relies on the quantization.
* even trivial operations like subtract and laplace spit out negative
numbers. java does not cope well with unsigned integers and conversion
to signed ones is messy. hence all formats should be signed. in
particular, all unsigned integers should be banned. this is a radical
decision!!
* supporting 4 integer formats is as easy as supporting 2 but not as
easy as only 1. if we go for 1, it should be 16bit or 32bit.
* metaprogramming is the only way out to support all formats with kept
performance. most programmers do not know it and many languages do not
have built-in support for it.

how do we deal with all the unsigned data in existence? most is unsigned
8bit to my knowledge. drop one bit to fit it in 7? put it in 16bit? Here
I would say use 16.

for 16bit data, dropping 1 bit does not hurt that much. I want to know,
how many does actually use the entire range of 16 bits? a loss of
0.00001% precision is not much to cry for.

once again, thankful for any comments
/Johan


--
--
------------------------------------------------
Johan Henriksson
MSc Engineering
PhD student, Karolinska Institutet
http://mahogny.areta.org http://www.endrov.net