Double Cluster, Altair 183M with LRGB filters

[turfpit]

The Double Cluster, data captured 3rd October 2024 with a total integration time of 1h 6m. Minimum exposures for the LRGB filters were calculated using a combination of Sensor Analysis, Quantum Efficiency Curve for the IMX183M sensor, the Sky Background Calculator and the Minimum Exposure Formula using Camera Read Noise and the Sky Electron Rate (SER) from the Sky Background Calculator.

Thanks to Brian (@oopfan) for encouraging me to investigate this technique and for his help along the way.

The object of this exercise was to use the minimum exposures which would avoid photon starvation and achieve colour balance without having to torture the data during post-processing. The Double Cluster was chosen as the test subject - it has no complex nebulosity and presents a variety of star colours against a dark background. The colour balance was controlled by varying the exposure lengths but capturing an equal number of exposures for all the filters. The result:

double_cluster_L-50x10s_R-50x30s_G-50x20s_B-50x20s.jpg (793.64 KiB) Viewed 3116 times

Equipment: Celestron AVX mount, Vixen 81s refractor with 0.67x flattener/reducer, Altair 183M camera, Teleskop LRGB 1.25" filters mounted in a ZWO mini filter wheel, QHY mini guider with QHY5LII-M guide cam.
Software: Sharpcap, PixInsight.
Data: Bias 100, Flats 30 each LRGB, Darks 25x10s 25x20s 25x30s, Lights L 50x10s R 50x30s G&B 50x20s each.
camera settings: gain=345, black_level=70

Calibration, Integration and post-processing were carried out in PixInsight.

PixInsight_processing.pdf

(162.96 KiB) Downloaded 100 times

The processing steps can be seen in these 2 videos (13m & 11m duration)
https://www.youtube.com/watch?v=eciH4yn3r0Q&t=551s
https://www.youtube.com/watch?v=A9askjeLXjE&t=2s

These are the processing steps stored in the final .xisf file.

PixInsight_process_steps.txt

(24.22 KiB) Downloaded 119 times

These were the steps used to calculate the exposures.

• Run the SharpCap Sensor Analysis Tool.

• Use the Quantum Efficiency graph form https://thinklucid.com/product/phoenix-20-mp-imx183 to estimate the sensor QE for each of the colours.

• Run the Sky Calculator which can be found at https://tools.sharpcap.co.uk/

• Use the Read Noise and calculated Sky Electron Rate to calculate the minimum exposure in the formula
  Minimum Exposure = (Read Noise)*(Read Noise)*(Factor)/SER

The detail to arrive at the exposures:
STEP 1: Run the Sensor Analysis within SharpCap and obtain the graph

sensor_analysis.JPG (37.93 KiB) Viewed 3116 times

The gain of 345 gave an estimated Read Noise of 1.65.


STEP 2: Use the Quantum Efficiency graph to estimate the QE for each of L (400-700nm), R (600-700nm), G (500-600nm), B (400-500nm).

QE_graph.JPG (29.89 KiB) Viewed 3116 times

The estimated QE values were L=70%, R=54%, G=77% and B=80%. By hovering over the points on the graph, QE values could be read off.

STEP 3: Use the Sky Electron Calculator to calculate the SKY Electron Rates.
Data to be supplied: Bortle Number, Telescope F ratio, Camera Pixel Size, Quantum Efficiency, Monochrome, Selected Filter (Red/Green/Blue or None (Luminance)). The outputs are the Sky Electron rates (SER) for each of the 4 filters.

SER_L.zip

(201.38 KiB) Downloaded 100 times

Step 4: Use the Read Noise and SER to calculate the minimum exposures using the formula (Read Noise)^2*(Factor)/SER. A Factor of 10 was used (recommended by Brian). I built these into a spreadsheet. The calculated exposures were rounded up to sensible, easy to use figures.

minimum_exposures.JPG (17.08 KiB) Viewed 3116 times

The whole exercise was repeated using a sheet of white paper during daylight as the illumination for the sensor analysis. This gave a smooth run with minimal user interaction.

sensor_analysis_2.jpg (86.41 KiB) Viewed 3116 times

This is the final spreadsheet. Gains of 177 and 562 have been chosen for future use. The lines for Ha, OIII and SII were drawn on the QE graph to give estimates for those filters' QE.

final_1.JPG (113.92 KiB) Viewed 3116 times

final_2.JPG (70.25 KiB) Viewed 3116 times

Gain 177 will be used for bright nebulae and galaxies, gain 562 for dimmer nebulae and galaxies. Globular clusters will require lower exposures and/or gain. Narrowband at the lower gain might not be viable. Note that the Altair 183M has an upper exposure limit of 15m (900s).

I need some skies now to test out these figures.

The final outcome was satisfactory. In post-processing, there was no need to adjust the colours for balance and minimal curves stretching was needed.

Dave

[admin]

Hi Dave,

a lovely image along with a highly useful discussion/writeup of how you achieved it. I have been thinking about colour balance issues myself recently and have come to realize that one of the big problems is that in deep sky there are two components that you need to fix to get good colour balance

1) Subtract away the background skyglow, which may well have a colour cast to it, leaving only the 'astro' part of the image remaining
2) Multiply/divide the values of the colour channels to correct for camera sensitivity/filters/etc.

Both of these are required - in that order. Trying to achieve good colours with only one of these options available is hard to nearly impossible, and the adjustments can be very fine/fiddly.

I have some improvements in progress based on this, coming within the next month or so I expect.

cheers,

Robin

[turfpit]

Thanks Robin.

I set out with the intention to capture the best quality image in the least amount of time and by acquiring better quality data reduce the amount of post processing required. The colour calibration in PixInsight uses a locally stored 60Gb database. One step that wasn't required for the Double Cluster was High Dynamic Range compression. With an object such as M81 this would avoid over saturation of the object when the L & RGB images are combined. The videos linked to above describe the processing steps I used.

I have developed a similar spreadsheet for the Altair 183C. The development work will hopefully get tested more over the coming weeks.

Good luck with your development - I assume it will be for OSC cameras.

Dave

[timh]

Interesting Dave and I really appreciate the detail and thought that you have put into the approach i.e. if I understand correctly ---

You outline a method (with input from Brian) for mono cam users for how to start from QE versus wavelength plus various other camera gain/ noise characteristics and sky conditions to calculate the most efficient exposure/ gain regime for the separate LRG and B channels -- i.e. so as to both make sure not only that the read noise is swamped for each channel but also that the relative amount of time spent on each channel is optimally balanced? In principle this seems that it should work.

It is also especially informative to have the PixInsight processing record attached as you have. Anyway it all seems to make sense to me (I especially like the new gradient correction tool). The links to the two videos are very useful -- I have never controlled luminance addition to colour with that level of precision and the lessons there are great.

I do have a but though. Firstly, while the image of the double cluster looks pretty good I don't understand the teal appearance of so many of the stars in the lower cluster and the pinkish look to the stars in the upper? I think that the core cluster stars are all white?

As Robin alluded to - well at my location anyway - I have horrible problems from gradients because of street lamps and other sources of light. Even with the best gradient removal tools they are impossible to remove entirely during postprocessing. That is partly why I often stick to narrowband. I used to think that my site was B6/7 -- but now I have realised that estimating some overall figure is not actually that useful since when I attempt to measure the actual sky background on any given night and direction (mags/ sq arcsec or electron rate) by subtracting the signal from a defined region in the master dark from a defined 'background' region in a light frame the answers vary widely depending on where in the sky the scope is pointing - any high cloud haziness - and of course angular proximity to lights and the moon ..wrt both subtle colour tint and signal. Of course a problem with this technique ---and indeed with all of the software background removal tools -- is that especially with the longer focal lengths and extended objects like nebulae it is impossible to actually define any true background points in a frame where some object signal isn't!

PixInsight seem to have a long term approach to solving this problem in terms of their 'MARS' project which aims to map the 'true' inherent background signal across the entire sky - though to use such a database to remove background might seem like cheating . Anyway maybe Robin will beat them to it

Tim

[turfpit]

Tim

Thanks for the comments.

To address the "but ...."

the teal appearance of so many of the stars in the lower cluster and the pinkish look to the stars in the upper? I think that the core cluster stars are all white

I had a look around the internet, starting with some APODs

https://apod.nasa.gov/apod/ap230707.html
White stars in the cluster but with the interesting addition of Ha.

https://apod.nasa.gov/apod/ap201118.html
Blue stars in the clusters.

https://apod.nasa.gov/apod/ap221122.html
Blue stars in the clusters.

https://apod.nasa.gov/apod/ap140123.html
White stars plus Ha.

From Wikipedia
https://en.wikipedia.org/wiki/Double_Cluster
States "each cluster contains 300+ blue-white stars".

I started to investigate what had happened with my image. With some investigation into a highly stretched RGB image it appeared that there was a subtle green gradient in the upper left, lower left, lower right quarters and a faint red gradient in the upper right quarter. The GradientCorrection model I had originally applied had not worked.

I reprocessed using a different GradientCorrection model which showed:

gradient_model.JPG (18.37 KiB) Viewed 2318 times

After processing, the cluster readouts showed a slight tendency to blue:

readouts_after_processing.JPG (58.71 KiB) Viewed 2318 times

These are the processing steps:

Double Cluster Processing.pdf

(845.83 KiB) Downloaded 46 times

As a check, I re-processed the data using DynamicBackgroundExtraction (DBE) using hand placed samples to arrive at this model:

gradient_model_DBE.JPG (21.43 KiB) Viewed 2318 times

The cluster readouts again showing a slight tendency to blue:

readouts_DBE.JPG (52.96 KiB) Viewed 2318 times

These are the processing steps (showing how masks were used to denoise the background and enhance the star saturation):

Double Cluster DBE.pdf

(583.63 KiB) Downloaded 61 times

A couple of things emerged from this exercise:

• I will have to spend a session going over the (11) GradientCorrection videos on the PixInsight Youtube page at https://www.youtube.com/playlist?list=P ... 8TnhEnxIlZ

• An interesting future project would be the addition of Ha to Double Cluster data

Here is the re-processed image:

Double_Cluster_LRGB.jpg (738.66 KiB) Viewed 2318 times

Dave

[timh]

Hi Dave,

Yes that is better --and it is comforting that you ended up with such similar background models from two different tools.. from DBE and from gradient correction in the end.

I now want to see what I end up with on the double cluster if I ever get the chance to take my Newt out to a dark sky site.

I've also started looking more closely at the background problem and paying more attention to the details of the settings in gradient correction - a lot to learn. Having tools like SPCC is an advance but - for most folk observing most of the time in light polluted skies defining the background gradient sufficiently well is probably the major challenge. Well that and simply failing to do things properly - I recently discovered what seems to have been a long-standing problem in the way I have been applying flats for example (not ticking the box to split the 3 colour channels in calibrating OSC frames) which now I find has a significant but subtle effect on the colours after SPCC. The learning in this game never ends!

The Ha is interesting -- I never knew it was there. For longer red filter exposures it could perhaps add some apparent faint red tinting anyway without the benefit of an HA filter? It also raises the interesting question then of what one defines as 'background gradient'?

The PixInsight MARS project seems an interesting approach to maybe cracking the problem in a more absolute way eventually - but it will need a lot of great widefield data from dark sites to build the database I would imagine?

Tim

[turfpit]

Many thanks to Tim and Robin for their comments and to Brian for his invaluable input into avoiding photon starvation and balancing LRGB filter colours by adjusting exposures during data capture.

This is the histogram of the final LRGB image. At no point during the processing of the RGB file and its merging with the L image did I have to perform any adjustments to attain colour balance.

histogram.JPG (8.42 KiB) Viewed 2185 times

Although open clusters might appear to be easy objects to image they are actually quite a severe test of data capture and subsequent processing. By using the camera sensor's QE graph, Robin's Sky Background Calculator and the Minimum Exposure Formula the exposure ratios of
L : R : G : B of 0.5 : 1.5 : 1 : 1 produced good data which required minimal processing. The calculated exposures are minimum exposures and could be increased proportionally if desired (or a longer integration time applied).

The final table in post #1 now needs testing against a variety of objects which require low and high gain.

Dave