64bit vs. 32bit images

[jkmorse]

Hey folks,

Another PI newbie question.  Given that PI does all functions equally well for 32bit and 64bit images, doesn't that mean that we should just make all images 64bit?

Thanks,

Jim

[Carlos Milovic]

No, because this means that they will use the double of space (both in the hard drive and in the ram), and your processes will run slower. Also, most of the time it is a waste of space, since you don't need such degree of accuracy in the numbers. Remember that at the end you'll be showing your images in 8bit monitors.

[jkmorse]

Carlos,

Makes perfect sense.  But in that case are there any processes where it is recommended to use 64bit rather than 32bit.  I guess the other way of asking it is to reverse my first question.  Is there ever a reason to use 64bit rather than the more economical 32bit?

Thanks,

Jim

[Carlos Milovic]

Yes, when you have HDR data. If the dynamic range is very hight, then storing with 32bits is not enough. Later, after HDR compression for optimal display, you can downsample to 32 or 16 bits in the later steps. 8bits should be used only for the final version.

[jkmorse]

Carlos,

Given the very nature of astroimaging, an argument could be made that every image that involves more than just stars is HDR.  That is certainly the case with many nebulae and galaxies.  Is there a good thumbnail guide for when, under PixInsight, an image should be considered HDR?

Thanks,

Jim

[Juan Conejero]

Given the very nature of astroimaging, an argument could be made that every image that involves more than just stars is HDR.

I like this idea. We usually make the distinction between HDR images and HDR problems. The former are images where two or more exposures of the same subject and different durations are combined to cover a wide range of tonal values. The concept of HDR problem is more general and applies when a brightness range---not necessarily very large---is being represented by a large set of numerical values in a single image. HDR problems happen all the time in astrophotography; this image is a nice example.

As for the need for 64-bit images, from the end user perspective they are mainly used to store large HDR compositions. See this post for a good example, where the HDR composition occupies about 2³⁰ discrete sample values (> 2²⁴, which is the capacity of 32-bit floating point). In this case the 32-bit unsigned integer format, also supported in PixInsight, would suffice. However, working with floating point data can be more convenient, especially taking into account that most internal operations work with real and imaginary numbers. For this reason the HDRComposition generates 64-bit floating point images by default.

The extended 64-bit precision can also be necessary to work with images numerically as pure data objects, instead of representable images, but this isn't something that most users have to care about.

[jkmorse]

Juan,

As usual, your explanations are very helpful.  Can I carry the discussion into one more subject from a PixInsight philosophy perspective?  You have been very helpful in describing why you view RGB with a synlum to be superior to LRGB imaging and I am converting my image capture accordingly.  The next question is the balance as treated by PixInsight between number of subs and integration time.  As always, time places limits on what you can do in an evening.  When processing in Pix Insight is it better to take fewer images at longer integration times (e.g., 15minutes), or more images at somewhat shorter integration times (e.g., 5 - 10 minutes).

And thanks again for a great product,

Jim   

[Juan Conejero]

Hi Jim,

This is a "classical" question in astronomical imaging, and its answers have all to do with the different sources of signal and noise present in the CCD data acquisition process. Nothing in PixInsight changes the fact that you need to expose enough as to overcome the readout noise of your CCD with the sky background. You need also to acquire enough frames for the best pixel rejection algorithms to work reliably. For example, if you plan on using Winsorized sigma clipping rejection, you need about 15-20 frames. For linear fit clipping, at least 20-25 frames (the more is *always* the better in this regard). Other factors can limit the maximum length of your subexposures, as the time your mount can guide without tracking errors, differential flexure, etc. I am sure that other users with more field experience than me can provide you with much better information.

[jkmorse]

Juan,

Thanks again.  Just wanted to confirm that there is nothing in PixInsight that tilts the usual balance one way or the other.

Regards,

Jim