Can you bin CMOS OSC cameras to produce a luminance sub?

[tomato]

If you bin a CMOS OSC camera I know that will mess up the Bayer matrix and you will lose the colour data, but would it produce an acceptable monochrome luminance image? The individual pixels  would have different sensitivities but wouldn’t this get evened out by the software binning?

[DaveS]

I don't know, but I expect @vlaiv could give you chapter and verse .

[iapa]

As I understand it, the binning will be done by software, rather than hardware binning as implemented on many CCD cameras.

So, I suspect that software binning for a CMOS OSC, would look at a 4 x 4 grid and pick the 4 Red cells and combine them, repeating for Green and Blue and repeat this across the grid.

I also found this: https://astronomy-imaging-camera.com/tutorials/everything-you-need-to-know-about-astrophotography-pixel-binning-the-fundamentals.html

+1 to @DaveS‘ reply.

[tomato]

1 minute ago, iapa said:

As I understand it, the binning will be done by software, rather than hardware binning as implemented on many CCD cameras.

So, I suspect that software binning for a CMOS OSC, would look at a 4 x 4 grid and pick the 4 Red cells and combine them, repeating for Green and Blue and repeat this across the grid.

I also found this: https://astronomy-imaging-camera.com/tutorials/everything-you-need-to-know-about-astrophotography-pixel-binning-the-fundamentals.html

+1 to @DaveS‘ reply.

That's interesting. Would the software binning be smart enough to offset the green bias in the matrix I wonder?

[iapa]

1 minute ago, tomato said:

That's interesting. Would the software binning be smart enough to offset the green bias in the matrix I wonder?

I doubt that many would take that final step, although it is something that would be nice to have.

Maybe something like PixInsight can go that extra step?

Having said that, just before I hit submit, it occurred that people may want to maximise the green for NB filters.

[vlaiv]

You can do both.

You can bin OSC sensor to produce mono data, and you can bin it in special way so that it is binned x2 and still produces color data.

Both of these are "sub optimal" - or rather don't quite do as you would expect from software binning / SNR point of view.

First - producing mono data.

You can bin Bayer matrix data and you will get mono data - but it won't be the data as produced by mono sensor for couple of reasons.

- bayer filters loose a bit of QE (like any filter does - even in part where they pass light). Compare mono vs osc QE for same sensor:

(Screen shot taken from https://astrojolo.com/gears/colour-camera-versus-mono-price-of-comfort/)

- second is that OSC filter overlap a bit, so you'll get "repeat" of some of data when you colors - see above graph at 490nm - G+B will be higher / will create spike over regular QE - QE curve will be altered by process of binning

- third - it is really hard to predict impact of read noise and overall SNR when doing this - in part because difference in QE graph and because you need to add read noises of each pixel

If you accept all of that, then yes, you'll get mono data (with particular QE and QE curve and particular read noise) like normal mono camera

You can also produce OSC data by binning each other pixel - or binning red channel separately, green separately and blue separately. However, such image will give you x4 lower sampling rate than what pixel size would suggest. If that is OK with you - then yes, you can bin and preserve OSC data.

In fact - if you use super pixel mode to debayer your data and then bin your subs after debayering - well then you effectively have the same thing.

[tomato]

I want to image with a KAF8300 on an Esprit 150 with the 0.77 reducer alongside an Esprit 150 and a QHY268c. To get the imaging resolutions similar I need to bin the QHY camera, so I thought capture Lum with this and RGB with the CCD. I suppose I could capture colour data with the QHY and then downsize the RGB channels in Startools or PI, if trying to bin at the point of capture doesn't work. 

Something to ponder while I wait for the dark nights to return.

[tomato]

Thanks, Vlaiv, for as always, a comprehensive and considered reply,  this came in as I typed my previous post.

There are lots of options then for me to try, I just need enough clear sky time to do them all justice.

[vlaiv]

I would recommend the following workflow to best match color / mono data from two different sources:

1. capture mono at resolution you want to work with (best to keep things above 1"/px if you can as there is not much point going higher res than that)

2. capture osc data at any resolution (again, use reducers or what not to get to reasonable sampling rate - but if you can't - you'll fix that later)

3. Stack mono data

4. Stack OSC data using super pixel mode or split debayer mode

5. Bin OSC data to first suitable resolution lower than mono data

Say you captured mono at 1.1"/px, and your stacked color data (after debayering and stacking) is at 0.7"/px - then bin your color data to 1.4"/px. Register color data against mono data using registration method that can handle resizing. ImageJ plugin can easily do this, and I suspect some other software can also handle mismatch in resolutions.

In any case - you should register OSC data against mono and not other way around so that OSC data gets stretched / squeezed and mono data remains at its based size. This is because color data is not that important for sharpness perception.

In the end - compose data into single image.

[pete_l]

1 hour ago, tomato said:

would it produce an acceptable monochrome luminance image?

Yes, I do it all the time.
I use opencv and Python to process frames from a colour I.P. camera and they turn out fine.

The line of code in question is cv2.cvtColor(frame, cv2.BGR2GRAY) where the BGR part determines the details of the colour -> greyscale conversion

So provided you get the correct Bayer matrix definition, there should be no problem.

[barbulo]

I’d like to ask another question on this regard. Taking into account the capabilities of the ASI294MM (standard resolution 2:2 - 4144x2822@4,64um and “unbinned” resolution 1:1 - 8288x5644@2,3um), is it reasonable to take the luminance subs at 1:1 and then “colour” them with 2:2 subs?

[vlaiv]

35 minutes ago, barbulo said:

I’d like to ask another question on this regard. Taking into account the capabilities of the ASI294MM (standard resolution 2:2 - 4144x2822@4,64um and “unbinned” resolution 1:1 - 8288x5644@2,3um), is it reasonable to take the luminance subs at 1:1 and then “colour” them with 2:2 subs?

It is reasonable to take color subs at bin x2 in comparison to luminance - maybe even x3.

I'm not really sure it is reasonable to take images at 2.3µm pixel size though. Maybe with 60mm F/4 scope - but anything more than that and that pixel size in itself is not reasonable. This is because it gives too high sampling rate. With 60mm F/4 scope - it will give 2"/px and that is ok for such small scope - maybe even that is oversampling.

Say you want to it with Esprit 100mm that is F/5.5 - That will already give you 0.87"/px and that is not achievable in regular seeing conditions with even 8" or 10" scopes let alone 4" one (mind you - although here aperture, unlike for planetary imaging, participates in resolution only to some extent - it is enough to make difference in average seeing between 4" scope and 8" scope). Airy disk diameter of 4" scope is 2.57" by itself without any influence of seeing and mount performance.

But back to the question at hand - yes, eyes are much less sensitive to change in color than in luminance and some small blur in color will almost go unnoticed. For that reason - you can sample color at lower resolution than luminance - and the reason I suggested to bin color data to coarser level than luminance. Here is example:

I found this image online and it is quite colorful and has some fine detail.

This is the same image except I left luminance as is and I scaled chrominance to 50% and then back to 100% (thus loosing a bit of resolution in it):

I honestly can't see any difference. In fact - I'm going to scale chrominance to only 1/4 of the size and see if there is a difference.

Again - I really can't tell the difference.

It might not look like it - but I really did loose resolution in chrominance part - look at difference between old and new a channel (part of Lab color space where ab is color and L is luminance):

same a channel in original image:

We can clearly see the difference and same goes for b channel  - however, that difference is not seen in original image because most of information comes from luminance and not color.

[ollypenrice]

My first experiment would be to shoot mono luminance at the lower resolution and than take both that, and the higher res OSC, into Registar and ask Registar to resize the OSC downwards to match the luminance. Given the downsizing of the the OSC which will follow, and the greater sensitivity of the OSC CMOS camera, I suspect that this might give you all you need. I would only look for a more complicated solution if it didn't. If this is dual rig data you have, in effect, a 'given' in that you'll be shooting equal amounts in both cameras with no sensible way of doing otherwise.  What I am suggesting is predicated on the higher sensitivity of the CMOS (OSC) over the mono CCD. Shooting OSC and luminance in equal amounts with comparable cameras will not, in my experience and that of others I know, produce an adequate colour layer.

We all know from experience that you need an awful lot more data to present an image at 100% over, say, 66%. This holds true even if you're not using a more sophisticated downsizing algorithm. How much difference the algorithm makes, however, I don't know.

Olly

[CCD-Freak]

I use Astro Art 7 to capture and process my ASI-533 images.  It has the option to do a 2x2 mono de-mosaic and it works very well to make mono images.

It is also possible to take an image but don't do the color conversion and do a .5x pixel shift to remove the Bayer matrix grid.  makes a nice mono image.