32 bit integer or rational?!

[Astrosurf]

I want to save my stacked images from DSS as 32 bit to get as much data as I can (if this is the way to go!) but DSS gives me two options: integer or rational. What on Earth does that mean?!

Alexxx

[roundycat]

Tell (no, ORDER!) DSS to save your files as 16bit integer TIFFs. There is no point in going for 32bit as it can provide masses more data than you can manage. Basically integer means whole numbers, your data will cover the range 0-65,536 ADU assuming a 16bit camera (DSLR's are nowhere near this) and that is enough to get a very fine picture. Remember this is 65,000 ADU per channel, with RGB you have an awful lot of colours available, more than you will ever be able to get.

Assuming you could get that much bit depth you will end up with billions of colours, not just the mere 16.8 million you get from 8 bit in each of three channels. More to the point you cannot display more than about 7bit on any monitor that I have ever seen. Something you can easily test for yourself. Many web pages display only web 'safe' colours which number about 256. If you intend to print your efforts then the print will also be limited to about 7bit. It's all down to maximum achievable reflection density and that is only about a seven f-stop range.

To me there is a good parallel between 32bit and having a 200mph car. You might 'know' it can do 200 but you will likely never find out.

Dennis

[FraserClarke]

Generally agree with Dennis above. Be a bit careful with mid-processing files though; there you could get into a situation where a 16-bit INT would reck your data by taking all the resolution out of it.

For example, if you try to store a normalized flat field image as a 16-bit INT, you'll remove all the information in it (every pixel will be 1 (or 0)). For that you need a 32-bit floating point (rational) image.

Once a file is processed and properly scaled though, even 16-bit INT is overkill as Dennis says.

Note however, I have NO experience with DSS, so I don't know if the point about calibration files etc is relevant in this case -- I don't know how DSS handles them. Just a general note that 32-bit does have its uses at times

[NickK]

Stacking 16 bit images will need more than 16 bits output if you want to maintain the level of information (ie don't scale as it looses data).

The beauty about having a large numbers of bits is that the output of stacking is more information for processing at an algorithm level. However this tends to be hidden inside the application.

If you stack twenty 16 bit images then you'd want 32 bit output. Subtract the blacks, bias and process against noise at this 32 or even 64 bit size then the signal will be far larger than the noise.

Next look at effectively truncating the lower bits off to remove background noise and then compress the remaining bits into 7-12 bits of colour that your display can show using histogram and curves.

Floaing point numbers have a mantissa and exponent which means in a 32 bit IEEE float you'll only get 24 bits of accuracy as the exponent takes 8 bits IIRC. For all amateur imaging pixel data, you'll not need floating point.

(um.. I did numerical computation at uni)

[roundycat]

Don't understand your comment about flats having pixels equal to 1 or 0. I was just doing some quick tests and my flats were averaging 9,000ADU and had pixel values from about 8k up to 11k. Not a 1 in sight. They were automatically normalised by MaxIm prior to median combine.

Ever since I bought my first CCD camera I have never used 32bit, only ever used 16bit Integer. No problems at all. I have never had my data wrecked by going from MaxIm at 16bit Int into PS and post processing from there. You have lost me completely.

Dennis

[FraserClarke]

Don't understand your comment about flats having pixels equal to 1 or 0. I was just doing some quick tests and my flats were averaging 9,000ADU and had pixel values from about 8k up to 11k. Not a 1 in sight. They were automatically normalised by MaxIm prior to median combine.

I normalize (make the average value = 1.0) my combined flats before I store them (I use different programmes to do the processing), so the values range from 0.9-1.1 (say).

Maxim is probably doing this 'on-the-fly' as it divides the data through by the flats. Maxim will be using 32-bit for it's internal storage/calculation, but saving having to store a 32-bit image at least.

[Astrosurf]

Thanks guys. I'm working through this at the mo!

[Astrofriend]

Dealing with bits can be confusing, I always thought that when I have 32-bit floating point I was on the safe side with margins. Maybe not the case when stackning lot of images and doing HDR.

I made a bit-resolution calculator to do some theoretical test:

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

From that you have a theoretical calculation of your need of bit-resolution without rounding errors. Noise and other things will hidden the last digits in your number, but still if you stacking a lot of images or doing HDR you get interesting results. The calculation is of course simplified, there are in theory lot of cases when you need infinite number of bits,

 

When saying 32-bit in image processing it's normally 32-bit floating point format. From that you can only use 23 bit to store the your pixel value in. The others are used for signs and exponent.

 

/Lars

[NickK]

Yup - most Asti images are 16bit and I found that processing you want a wider precision.

Annoying most GPUs are not IEEE either.. (for my work at the time)