Re: not that complicated

[Carol Heckman]

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 [[hidden email]] On Behalf Of Johan Henriksson [[hidden email]]
Sent: Tuesday, February 03, 2009 4:23 PM
To: [hidden email]
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

[mahogny]

thanks everyone!

for general interest, the solution:

the formats will be
uint8 -> int16 -> int32 -> float -> double
automatic conversions follow arrows. there will be no concept of a
"color range", 0-256 will be shown on screen. 16bit has to be divided
(using contrast/brightness) to fit the screen. any conversions <- are
either forced by filter format support or by the user. as carol notes,
this will always be a problem, and this makes the best out of the
situation. uint16 bitmaps will be mapped to 15bit or 31bit depending on
program settings.

as for accessing the original, our approach is to apply most filters
lazily in realtime. this way there is no need to run through a 40GB
recording if you just want to display a single slice with higher contrast.

/Johan

Carol Heckman wrote:

> 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 [[hidden email]] On Behalf Of Johan Henriksson [[hidden email]]
> Sent: Tuesday, February 03, 2009 4:23 PM
> To: [hidden email]
> 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
>  

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