Binning

[StuartT]

Quick question.. night is finally back, so I am set up and ready to go in a couple of hours for some galaxy stuff. 

I'm using a Celestron Edge HD 9.25 with my only deep sky camera (ASI2600MC). This is not an idea combo, I realise, so I am planning to bin the camera 2x2, or even 3x3. Do you agree?

Or would it be better to leave the camera at 1x1 and then downsample in Pixinsight?

Edited August 5, 2022 by StuartT

[vlaiv]

I would go about it like this:

- shoot regularly without binning. Make sure you that you swamp the read noise with LP signal / background

- do split debayer (I think there is script for PI that does this)

- integrate

- bin x2 resulting integration

This will produce very respectable ~1.33"/px sampling rate (and hopefully your sky and mount will support it for the night).

[StuartT]

12 minutes ago, vlaiv said:

I would go about it like this:

- shoot regularly without binning. Make sure you that you swamp the read noise with LP signal / background

- do split debayer (I think there is script for PI that does this)

- integrate

- bin x2 resulting integration

This will produce very respectable ~1.33"/px sampling rate (and hopefully your sky and mount will support it for the night).

thanks @vlaiv

By split debayer, do you mean generate separate RGB channels?

How would binning the integration by 2 lead to 1.33"/px? Natively this rig is about 0.33, so wouldn't doubling that give 0.66?

[vlaiv]

12 minutes ago, StuartT said:

By split debayer, do you mean generate separate RGB channels?

It is special type of debayering that works a bit like super pixel mode (thus keeps lower sampling rate of bayer matrix instead of doing interpolation) - that splits channels in the process.

It produces 1 red, 1 blue and 2 green subs from each of the raws (do that after calibration), but each x2 smaller in width and height.

You end up with red, blue and green subs after that (green subs will be 2 times as many as subs you recorded). Then you stack them like you would normally do with mono/(L)RGB - you stack each of colors to separate stack - but you align them to same reference frame.

After you finish stacking - bin x2 each of the subs while still linear.

First part - split debayer will produce 0.66"/px from 0.33"/px data, and second x2 bin will turn that 0.66"/px data into 1.33"/px data.

By the way - operation in PI that does split debayering is called SplitCFA - here is forum post about it:

https://pixinsight.com/forum/index.php?threads/splitcfa-mergecfa.14494/

[StuartT]

2 minutes ago, vlaiv said:

It is special type of debayering that works a bit like super pixel mode (thus keeps lower sampling rate of bayer matrix instead of doing interpolation) - that splits channels in the process.

It produces 1 red, 1 blue and 2 green subs from each of the raws (do that after calibration), but each x2 smaller in width and height.

You end up with red, blue and green subs after that (green subs will be 2 times as many as subs you recorded). Then you stack them like you would normally do with mono/(L)RGB - you stack each of colors to separate stack - but you align them to same reference frame.

After you finish stacking - bin x2 each of the subs while still linear.

First part - split debayer will produce 0.66"/px from 0.33"/px data, and second x2 bin will turn that 0.66"/px data into 1.33"/px data.

By the way - operation in PI that does split debayering is called SplitCFA - here is forum post about it:

https://pixinsight.com/forum/index.php?threads/splitcfa-mergecfa.14494/

great! Thank you 

[StuartT]

On 05/08/2022 at 22:19, vlaiv said:

It is special type of debayering that works a bit like super pixel mode (thus keeps lower sampling rate of bayer matrix instead of doing interpolation) - that splits channels in the process.

It produces 1 red, 1 blue and 2 green subs from each of the raws (do that after calibration), but each x2 smaller in width and height.

You end up with red, blue and green subs after that (green subs will be 2 times as many as subs you recorded). Then you stack them like you would normally do with mono/(L)RGB - you stack each of colors to separate stack - but you align them to same reference frame.

After you finish stacking - bin x2 each of the subs while still linear.

First part - split debayer will produce 0.66"/px from 0.33"/px data, and second x2 bin will turn that 0.66"/px data into 1.33"/px data.

By the way - operation in PI that does split debayering is called SplitCFA - here is forum post about it:

https://pixinsight.com/forum/index.php?threads/splitcfa-mergecfa.14494/

@vlaiv Can I just double check this with you? - my guiding is only at about 0.4"- 0.5" this evening. Do you still think it's ok to bin 1x1 (0.33"/px)? Shouldn't guiding be equal or better than image scale?

[vlaiv]

9 minutes ago, StuartT said:

@vlaiv Can I just double check this with you? - my guiding is only at about 0.4"- 0.5" this evening. Do you still think it's ok to bin 1x1 (0.33"/px)? Shouldn't guiding be equal or better than image scale?

You are using ASI2600MC, right?

That is CMOS camera, and for CMOS camera - it does not matter if you bin at capture time or later in software. In fact - it is better to do it in software as you have more flexibility in the way you do it (for example - first split debayer and then stack + bin).

You will get good final resolution for your conditions tonight (and improved SNR) - if you do it like described above.

Just capture at bin 1 and you will handle everything later. Only thing to worry about is to swamp the read noise with background signal. That is it for capture.

[StuartT]

2 minutes ago, vlaiv said:

You are using ASI2600MC, right?

That is CMOS camera, and for CMOS camera - it does not matter if you bin at capture time or later in software. In fact - it is better to do it in software as you have more flexibility in the way you do it (for example - first split debayer and then stack + bin).

You will get good final resolution for your conditions tonight (and improved SNR) - if you do it like described above.

Just capture at bin 1 and you will handle everything later. Only thing to worry about is to swamp the read noise with background signal. That is it for capture.

yes. 2600MC

How can I know if I have swamped the read noise with background?

 

[vlaiv]

5 minutes ago, StuartT said:

yes. 2600MC

How can I know if I have swamped the read noise with background?

You need to have median background higher than certain number that you need to calculate - based on your bias mean value and read noise.

If you don't already know how to do it - then don't worry now, just capture as you normally would.

For next time when planning a session - you'll examine subs from tonight's session and based on that you can calculate if you need longer exposure or not.

There are explanations on how to do it - just search for optimum sub exposure length and you'll find plenty of info.

 

[StuartT]

6 minutes ago, vlaiv said:

You need to have median background higher than certain number that you need to calculate - based on your bias mean value and read noise.

If you don't already know how to do it - then don't worry now, just capture as you normally would.

For next time when planning a session - you'll examine subs from tonight's session and based on that you can calculate if you need longer exposure or not.

There are explanations on how to do it - just search for optimum sub exposure length and you'll find plenty of info.

 

I just tried the Optimum Exposure tool in NINA and it suggested 37s - this seems rather short

[vlaiv]

20 minutes ago, StuartT said:

just tried the Optimum Exposure tool in NINA and it suggested 37s - this seems rather short

It does seem very short, especially for 0.33"/px sampling rate

If you are using longer exposures, then stick with those. I'm not sure if NINA is accurately calculating what needs to be calculated.