Binning in astrophotography [Deep Sky] Acquisition techniques · Francois Theriault · ... · 26 · 1104 · 5

Francois Theriault:
Thank you all for your feedback. Looks like I will have to experiment more with this.

The basic point I was trying to portray here is that a binned image at long focal length occupies the sale "real estate" on the sensor as an unbinned image at a shorter focal length. This is of course hardware binning at capture time, not software upsampling or downsampling.

As far as SNR, I image from my backyard in an urban area at Bortle 8. So my conditions are typically bad regardless. Let's just say that I do a lot of narrowband to get around the light pollution that is prevalent in my area.

Thanks all for your input.

John Hayes:
Binning is useful for two things:
1) Increasing signal at the expense of sampling rate.  This is very useful for guide cameras.
2) Decreasing the image sampling rate to better match the seeing and the telescope.

If you want to understand how to pick the optimum sampling rate for any telescope under different seeing conditions, please review the talk that I gave at AIC in 2022.  If you haven't registered, it's free to join and get in.  You can find the presentation here:  

https://www.advancedimagingconference.com/articles/secrets-long-focal-length-imaging-john-hayes

I go through all of the factors that go into computing the optimum sampling along with some easy to use charts on slides 43 and 44 to find the sensor that best matches your telescope and your seeing conditions.  You can listen to the presentation or you can just go through the slides.

Binning a CMOS camera does have one downside.  Since cameras transmit only 16 bit images and 2x2 binning adds another 2 bit of information, arithmetic binning in the camera looses 2 bits of information.  The easiest way to fix that is to bin in processing using floating point (or just more bits).  That strategy doesn't reduce bandwidth requirements  in data transmission but it does improve SNR in the result.

John

Francois Theriault (FrancoisT)All,
I feel that we are getting off topic here.

The original premise of the post was to present to the community that when binning - hardware in this case, the image produced occupies the same real estate on the overall final image.



In the case of the Ritchey-Chretien, my original calculations show - that the Ring nebula at the "native" 1x1 occupies 480 pixels on the sensor.
HOWEVER, the Dawes limit indicates that the smallest detail possible with this setup is 1.18 pixels. Therefore, the smallest detail would, in reality, occupy 4 pixels, since it overspills a single pixel. 

The native resolution of the camera is 4656 x 3520, for a total of 16,389,120 pixels total (16 MB).
The target would be 480 x 480 pixels = 230,400 pixels.
Thus, the target occupies 1.4% of the available area on the sensor.

If we bin at 2x2, each pixel is now the equivalent of 4 pixels at the "native" 1x1 binning.

The target now occupies 239 pixels.
Checking the Dawes limit, the smallest feature that can be resolved is now the equivalent of 0.59 pixels, so for all intents 1 pixel.

AND
 The size of the target is now 239 x 239 = 57,121 pixels.
The binned sensor reduces in size, since we are doubling the size of the pixels. It is now 2328 x 1760  = 4,097,280 pixels (4 MB).
So the target is 57,121 / 4,097,280 = 1.4% of the available area on the sensor.

For software binning, that is a whole different discussion. I simply do not know enough about upsampling and downsampling to contribute anything  here.

And as far as taking and processing a whole batch of data in individual subs, I recently burnt out a computer by processing too many runs of subs. Processor overheated, damaged the motherboard and seized up 2 of my hard drives. That is a different post however.

So as far as processing 300 + subs, I really am not that excited about it...

John Hayes:

Jon Rista:

Francois Theriault (FrancoisT)All,
I feel that we are getting off topic here.

The original premise of the post was to present to the community that when binning - hardware in this case, the image produced occupies the same real estate on the overall final image.



In the case of the Ritchey-Chretien, my original calculations show - that the Ring nebula at the "native" 1x1 occupies 480 pixels on the sensor.
HOWEVER, the Dawes limit indicates that the smallest detail possible with this setup is 1.18 pixels. Therefore, the smallest detail would, in reality, occupy 4 pixels, since it overspills a single pixel. 

The native resolution of the camera is 4656 x 3520, for a total of 16,389,120 pixels total (16 MB).
The target would be 480 x 480 pixels = 230,400 pixels.
Thus, the target occupies 1.4% of the available area on the sensor.

If we bin at 2x2, each pixel is now the equivalent of 4 pixels at the "native" 1x1 binning.

The target now occupies 239 pixels.
Checking the Dawes limit, the smallest feature that can be resolved is now the equivalent of 0.59 pixels, so for all intents 1 pixel.

AND
 The size of the target is now 239 x 239 = 57,121 pixels.
The binned sensor reduces in size, since we are doubling the size of the pixels. It is now 2328 x 1760  = 4,097,280 pixels (4 MB).
So the target is 57,121 / 4,097,280 = 1.4% of the available area on the sensor.

For software binning, that is a whole different discussion. I simply do not know enough about upsampling and downsampling to contribute anything  here.

And as far as taking and processing a whole batch of data in individual subs, I recently burnt out a computer by processing too many runs of subs. Processor overheated, damaged the motherboard and seized up 2 of my hard drives. That is a different post however.

So as far as processing 300 + subs, I really am not that excited about it...

So, there is the resolving limit of the optics, and then there is the sampling rate of what the optics resolved. The two are not the same thing. You generally, for best results when it comes to detail, WANT to OVER-sample to a certain degree. There have been many debates on this topic. Suffice it to say, I've (if I have had the opportunity) aimed for about a 3x sampling rate across the FWHM. Some people will strictly adhere to Nyquist rate, which is primarily regarding "two dimensional" signals (i.e. audio), and would require sampling at 2x across the FWHM. Image signals have an additional dimension, however, and then there is the fact that we are translating and stacking many individual subs, among other things, all of which can benefit from sampling beyond Nyquist rate. Somewhere between 3-4 samples across the FWHM will usually net you an optimal balance of resolution vs. SNR. 

Your current table very simplistically divides the Dawes limit by the raw image scale, and you've got ~1.18 pixels. Sampling your stars with just one pixel, or close to it, is not really going to be sufficient. Even a 0.57" size star, "spilling over" into the adjacent pixels, is actually NOT well sampled, it is undersampled. If you really wanted that star to be WELL sampled, or more optimally sampled, then you want the FWHM produce by that star to be sampled by THREE to FOUR pixels, meaning the entire diameter of the star would span maybe 5-7 pixels in total.

I would say, in your case, you most certainly don't need to worry about sampling too much at the Dawes limit of your scope. The Dawes limit is on thing, but it has more to do with the maximum ability of a scope to separate two closely spaced point sources. IMO a more interesting figure would be the actual size of the Airy disc and Airy pattern. The Airy patterns is going to be convolved by seeing, which will produce a star spot that is most likely, under most circumstances (unless you are blessed with wonderful seeing all the time!!) going to be even larger. What is the size of that star spot? What is its FWHM? Ideally, you would be sampling that FWHM with your sensor, with around 3 pixels, and across the entire diameter by more than that. If you are sampling your average star spot by 4+ pixels, then you could downsample by at least 2x, if not more, without any meaningful loss in details.

Jon,
While I agree with the general message that you are conveying to the OP, you've slightly scrambled up the optics here.

1) The Nyquist limit applies to audio signals AND to image data!  It is a simple proof in Fourier space that works in N dimensions showing how sampling relates to the band limit of any linear, shift-invarient system.  It is also very easy to show that sampling at a rate of more than two samples per cycle at the bandwidth limit does not add any additional information to the output--no matter how hard you try!  That's called, "oversampling".  Oversampling merely decreases SNR without adding to image "detail".  This is a very well known result and if there are any debates about it, it is not among professionals or those who have actually done the mathematics (which again, is very simple.).  Trust me:  The engineering teams that designed both Hubble and JWST understand this stuff really well.  It's a proof that's done in the first semester of any graduate level Fourier analysis course.

2) It is simple to show that the Nyquist limit for an optical system requires 4.88 point samples across the Airy Disk.  Remember that the FWHM of the central peak in the Bessel function (which is what the Airy disk is) is narrower than the diameter of the first ring so that translates into 2.05 samples across that central peak to be at the Nyquist limit.  But, that's not relevant unless you are in space AND you are using a point sensor; neither of which applies.

3) Dawes limit is an experimentally derived limit for visual observers.  The eye is not an integrating detector so what you can see with your eye has little to do with what happens with long exposure imaging of faint objects using an integrating detector with finite size.  That's why I posted my AIC talk!  It explains how the sensor size, the optics, and the atmospheric seeing can be combined using MTF analysis to determine the optimum sensor size for any passive imaging system not in space.  I've distilled the analysis into a simple formula that works well down to about 0.3" seeing and if you have better seeing than that, you'll need to go back to Nyquist and do a more rigorous MTF analysis.  The goal of my analysis was to eliminate old-wives tales about how to achieve optimum sampling and it does that.  I can guess from your comments that you probably haven't reviewed it.  I think that you will enjoy it so take the time and go check it out.

John

John Hayes:
Binning a CMOS camera does have one downside.  Since cameras transmit only 16 bit images and 2x2 binning adds another 2 bit of information, arithmetic binning in the camera looses 2 bits of information.  The easiest way to fix that is to bin in processing using floating point (or just more bits).  That strategy doesn't reduce bandwidth requirements  in data transmission but it does improve SNR in the result.

Just an fyi, turns out binning  2x2 on the camera and losing the two LSBs really doesn't affect SNR significantly at all.

https://forums.sharpcap.co.uk/viewtopic.php?p=34676#p34676

Dave

Emilio Frangella:
resolution is only  part of the equation, considering that with modern CMOS cameras you can resample post acquisition and achieve the same results as a native 2x2 binning (CMOS cameras simply resample in software) i would always shoot at bin1 unless storage space/processing power are a concern.

Just an fyi, turns out binning  2x2 on the camera and losing the two LSBs really doesn't affect SNR significantly at all.

https://forums.sharpcap.co.uk/viewtopic.php?p=34676#p34676

Dave

That link is a very simplified description of what happens when you truncate, and it can be made more rigorous.  Instead of talking about "average" error introduced, it's more useful to talk about the standard deviation of the error, and when you discretize a signal into steps of size, s, the error introduced is s/sqrt(12) - which is much less than the "average" error of s/2 or whatever.  Knowing the error as a standard deviation allows you to combine it in quadrature with read noise - and the result is a very real, but very small, contribution when summing 4 pixels at gain 0.8.  And it makes no difference if you round down or up or whatever.

This discretization noise happens even when you don't bin, because the intrinsic read noise will be added in quadrature with the discretization noise of g/sqrt(12), where g is the gain as e/adu.

For gain 0.8 and read noise 3.5, the total read noise with discretization error is slightly bloated to 3.508.  If you sum 4 pixel values exactly the noise is doubled to 7.016, but if you then discretize it in steps of 4 (3.2e), corresponding to dropping the final two bits, you end up with noise in the sum of 7.076 - which is a real but extremely small - and negligible - increase on the exact sum.  (I welcome corrections on the math).

So - it's not good to think in terms of "those low bits are just noise" because those bits also have signal.  The entire set of bits represents the signal and noise - and discretizing or truncating at any level will increase the total noise - but by an amount much smaller than the step size due to the 1/sqrt(12) factor - and the fact that the noise adds in quadrature with the other sensor noise terms (here, read noise).

This describes the impact of discretization of the signal itself, while the original topic of this thread relates to *spatial* binning and discretization of the image and its impact on resolution - and the situation is very similar.  There is always blurring happening on the scale of the pixels, and smaller pixels, in arc-sec, will result in less total blurring in the final result.  This is because the process of aligning and stacking multiple exposures requires shifting and interpolation - on the scale of the pixels - prior to stacking.  And that results in a blur contribution *on the scale of the pixels*.  Smaller pixels means less blur and a smaller fwhm *in the aligned and stacked result*.  There is no sudden point where smaller pixels cease to have resolution benefit because this blur is always happening - just as there is always error introduced by discretization at any size of signal step.

This is also why it is best to defer the final binning or smoothing until the last stage of processing - so the alignment can be done using the original unbinned pixels.  It's also why, for max resolution, you should never bin during acquisition - even though the impact of discretization noise is small.  But if you aren't after max detail - you can go ahead and bin and use any size pixels you want, with a corresponding trade off of pixel SNR for detail.

The amount of  blur depends on the type of interpolation used when stacking, but recently PI switched to recommending 1:1 drizzle over things like Lanczos - and that will definitely result in blur being introduced to each exposure in the stack.  I prefer to use small pixels and nearest neighbor, for a number of reasons, hence I use 0.28" pixels with EdgeHD11 and get stacked fwhm's in the low 1".  That would never be possible with the typically recommended 0.5-1" pixels for such an SCT.

Frank