Pixinsight Help - Processing OSC data plus mono camera Luminance data

A couple of notes:

1. Blurxing RGB channels separately is pointless, if not detrimental, as aberration correction will work better on a color image

2. SPCC shouldn’t be done on the combined LRGB image but rather on the RGB image prior to Lum combination.

3. Linear fitting RGB to L won’t produce a very accurate result. Due to the channels having differences in brightness of stars and structures. Instead, if you want to combine LRGB in the linear stage, you should extract the average of the color calibrated RGB image and linear fit your Lum to that. Then, use L * $T / med(avg($T[0],$T[1],$T[2])) on the RGB image in pixelmath.

4. LRGBCombination is meant for non-linear images only. It’s a perfectly valid way to combine LRGB, but you need to stretch the data appropriately first.

I also recommend extracting the background on the combined RGB image, as it’s much easier to see color gradients on a color image, rather than on each color channel separately.

Also, SCNR should be avoided as a means of balancing/correcting colors, curves, stretching, or manual color calibration are better suited for the job if you’re seeing a green cast in your data. Keep in mind, color calibration will almost always result in a green tint to the structures on non-drizzled OSC data, so if haven’t already, stack using 1x drizzle, preferrably with dropshrink set to ~0.45 to avoid interpolation artifacts from debayering. You can 1x drizzle the L data too while you’re at it (the same advantage, except interpolation artifact with mono data are much less significant, so dropshrink can be set to 0.8-0.9)

In the end, processing OSC + mono L is very similar to mono LRGB, the only major differences are the need to drizzle the OSC data and that the RGB data comes pre-combined with OSC :).

Hope this helps!

andrea tasselli · Sep 1, 2025, 06:45 PM

Mikolaj Wadowski:
Also, SCNR should be avoided as a means of balancing/correcting colors, curves, stretching, or manual color calibration are better suited for the job if you’re seeing a green cast in your data. Keep in mind, color calibration will almost always result in a green tint to the structures on non-drizzled OSC data, so if haven’t already, stack using 1x drizzle, preferrably with dropshrink set to ~0.45 to avoid interpolation artifacts from debayering. You can 1x drizzle the L data too while you’re at it (the same advantage, except interpolation artifact with mono data are much less significant, so dropshrink can be set to 0.8-0.9)

*Appropriately used SCNR removes the green (or red or blue) cast form the background only, so there is a point in using it with a RGB image. And I can't really agree that there is a specific green cast only revealed by in drizzled OSC data either. As for drizzling and I assume you are meaning CFA drizzle, then debayering does not have a part in it, the interpolation is being done by the CFA drizzling algorithm already, afaik. That is the whole point of it.

SCNR is not a good tool for background neutralization. That’s BackgroundNeutralization’s job. Unless by background cast you mean green mottle, then yeah, I can somewhat agree, though I’d argue MMT would be a better choice, though it is more difficult to use.

Yes, I meant CFA drizzle whenever I mentioned drizzling the OSC data. Debayered, non-CFA-drizzled OSC images will always have a color cast (it’s almost always green in my experience) after color calibration. You can try it for yourself. Debayer interpolation trashes the photometry of an image, iirc due to small-scale features being messed with. CFA drizzle, iirc, works in the exact same way as standard drizzle, except it knows which pixel belongs to which channel.

Drizzle, both CFA and non-CFA, with a properly set dropshrink has negligible interpolation (or maybe none at all, I can’t remember), while the non-drizzled stacks will show visible interpolation artifacts. Whether that’s little spikes on very undersampled data from lanczos interpolation, debayering being debayering, or the slight convolution unavoidably added during any image transformation, like image registeration. That’s the whole point of 1x drizzle, to make the image (almost?) free of interpolation artifacts to maximize sharpness and restore photometry in some cases.

Mikolaj Wadowski · Sep 1, 2025, 06:25 PM

• Blurxing RGB channels separately is pointless, if not detrimental, as aberration correction will work better on a color image

• SPCC shouldn’t be done on the combined LRGB image but rather on the RGB image prior to Lum combination.

• Linear fitting RGB to L won’t produce a very accurate result. Due to the channels having differences in brightness of stars and structures. Instead, if you want to combine LRGB in the linear stage, you should extract the average of the color calibrated RGB image and linear fit your Lum to that. Then, use L * $T / med(avg($T[0],$T[1],$T[2])) on the RGB image in pixelmath.

• LRGBCombination is meant for non-linear images only. It’s a perfectly valid way to combine LRGB, but you need to stretch the data appropriately first.

thank you @Mikolaj Wadowski . your suggestions does provide better results. no need to split into R,G,B and did not require linear fit. LRGBcombine on stretched data worked perfectly. also Running SCNR on the OSC data provided better results. thank you again.

Amit · Sep 1, 2025, 08:12 PM

Mikolaj Wadowski · Sep 1, 2025, 06:25 PM

• Blurxing RGB channels separately is pointless, if not detrimental, as aberration correction will work better on a color image

• SPCC shouldn’t be done on the combined LRGB image but rather on the RGB image prior to Lum combination.

• Linear fitting RGB to L won’t produce a very accurate result. Due to the channels having differences in brightness of stars and structures. Instead, if you want to combine LRGB in the linear stage, you should extract the average of the color calibrated RGB image and linear fit your Lum to that. Then, use L * $T / med(avg($T[0],$T[1],$T[2])) on the RGB image in pixelmath.

• LRGBCombination is meant for non-linear images only. It’s a perfectly valid way to combine LRGB, but you need to stretch the data appropriately first.

thank you @Mikolaj Wadowski . your suggestions does provide better results. no need to split into R,G,B and did not require linear fit. LRGBcombine on stretched data worked perfectly. also Running SCNR on the OSC data provided better results. thank you again.

Glad I could help. Again, I seriously recommend not killing any signal with SCNR and looking into preventing the unwanted green cast in the first place. But it’s up to you in the end.