Bit Resolution Calculator

[Astrofriend]

When talking 32-bit files I normally feels that I'm safe with big margin to not clip any information in my astro image files when workning with them. But is it really so?

After some discussing I feel, why not try to make a Bit Resolution Calculator?

Here is my new Bit Resolution Calculator:
http://www.astrofriend.eu/astronomy/astronomy-calculations/bit-resolution/bit-resolution.html

For sure there will be some mistakes in it. I correct it when I found something. The calculations are also simplified.

I'm a little bit surprised over the result, but still in the safe area when not doing something extrem.

Note this is a theoretical simulation and in real life there are a lot of noise that mask the rounding errors. But still interesting to test what happens in different situations.

/Lars

[vlaiv]

Haven't gone thru complete page, but here are some things that you need to consider (based on your calculation of 35 bits needed).

Flats are going to be the worst to model. Simply because there is division involved (it's easy if you want true precision without any loss due to rounding - just add number of bits, but error introduced is so small at some point).

Bias calibration effectively has no bit count impact because it cancels out (if used with darks / flat darks).

Here are couple of rules that one should know (if we want absolute / best precision, not accounting if it's masked by noise or whatever - simply precision that you need in order not to contribute any rounding errors).

Addition increases bit count by log base 2.

Multiplication increases bit count by addition of number of bits.

So if we have 2 subs that we add - we increase bit depth by 1. If we have 4 subs that we add we increase bit depth by 2, and so on ...

When we have 10bit sub and multiply or divide it with another 10bit sub we end up with 20bit result (it's like multiplying two numbers - let's say 3 digit number and 2 digit number - we will end up with 5 digit number).

Since calibration and stacking can be done with only above two operations +|- and *|/, we can easily calculate number of bits required.

You should also know that 32bit floating point precision does not contain 32bit precision. It contains 23bit mantissa. Here is description of IEEE single precision floating point (32 bit):

Single precision   (32 bits):  1 sign bit |  8-bit exponent   |  23-bit mantissa

64 bit precision (double precision - has more mantissa bits):

Double precision (64 bits):  1 sign bit |  11-bit exponent |  52-bit mantissa

 

 

[x6gas]

I have a degree in physics and astronomy (albeit a long time ago) and I can confirm that my understanding of Vlad's post ended at "things that you need to consider" but blimey he seems to know his stuff!

[Astrofriend]

Hi,

Thanks for the comments, about the flat calibration I did it simple, just say it need at least one more bit, maybe I shall increase this to 2 or 3 bit as you suggest, that's more realistic. All the other I think I already have in the text. It's in an early stage now, lot of updates will come when tested out.

There is a choice if bias should be included or not depending of the situation, if you suspect it cancel out, just omit the bias. If you have separate bis for dark and flat it doesn't cancel out, I see now that I forgot the flat bias. Myself I do dithering and meadian stack with flat calibration only which work ok with my Canon 6D camera which have low static pattern.

One more thing is that all cameras are not linear, to correct for that you need more precision also, often second degree correction or more. I have done some correction for that when workning in Matlab, but that was more just a test. Lens distosion is another part that ad more demand on the precision if you want to correct for that.

About the 32-bit format. What I know the exponent of 8 bit use 7 bit for exponent and the last bit for the sign. Like this +/- 127. Altogether they make 8 bits. But in some system they only use 23 of the 24 bit to store data in. I don't why and when this differ.

Thanks again for the comments and good feedback!

/Lars

[vlaiv]

Yep, I was slightly wrong about flats as division is not the same as multiplication, here is simple example (in decimal digits, but one can show similar in binary):

Multiplication - take any two digit number and multiply with three digit number you will get 5 digit number (in general case since we don't know exact values) - 99 x 999 = 98901

But with division it is not as simple as that, since we have cases where there is always truncation and error will occur at any fixed bit length. Here is simple example in decimal system:

10 / 3 = 3.33333333 ....

Infinite number of digits ...

So for flats - there is no straight forward way to show number of bits involved since in general case you may need infinite number of them. Best way would be to specify minimal error and based on that determine number of bits needed to store result up to that introduced rounding error.

For float point numbers you need sign for both exponent and mantissa - and 1 bit is reserved for that - this is why in 32bit float exponent is in form +/- 2^7 and mantissa is in form of +/- 2^23 = total 32 bits (similarly for double precision and 64 bits).

 

[Astrofriend]

Hi Vlaiv,

Yes of course, the last 24 bit is for the sign. But if you have +/-32000 or 0 to 64000 it stills is the same total range. Used the 16 bit example here.

 

Thanks about info division, have not gone that deep into that, yet. I will change this part in the Bit Calculator later when I have think it over. There are always some deeper things to take care of. But must limit it to be useful.

 

/Lars

[Astrofriend]

I added an illustration of how it goes with the bits when doubling the values:

http://www.astrofriend.eu/astronomy/astronomy-calculations/bit-resolution/bit-resolution.html

 

Maybe easier to follow?

 

There are situations that are not correctly handled, see it like a development project.

 

/Lars