HaRGB with OSC

[Ken Pendlebury]

Hi folks,

I have a OSC camera (QHY8) and I was curious if anyone else has attempted Ha imaging with something similar...

I have read many posts here about various methods by which Ha may be combined with RGB, but was curious about the steps prior to these methods for OSC type cameras.

When using an Ha filter over a Bayer matrix, I assume that only the red pixels actually get any data.  Is it fair to say that in order to get my hands on an Ha image, I would debayer the frame, extract the RGB channels and toss the green and blue (meaning only the red frame is of interest)?  At this point, I think that I would desaturate (extract lum) the red channel in order to prepare it for use in pixel math.

Any thoughts on this roughly outlined process?

I apologize if this has already been asked, but it is difficult to search for terms like "Ha" and "OSC"

Lastly, I have read a lot of chatter about "NB Channel Mixer" modules and the like from last year.  Is pixel math still the accepted way to perform HaRGB combinations in PI 1.6?

i.e:

R: (1 - k)*$T + k*Ha  where k between 0-1
G: $T
B: (1 - j)*$T + j*Ha where j between 0-1

Thanks for the help,
Ken

[Nocturnal]

Ken,

try extracting R G and B from a color image and you'll see you get 3 monochrome image. No need to desaturate further

Frankly I'm not sure what the use is of HaRGB mixing but I can see the use of replacing R with Ha resulting in HaGB. Open for discussion of course

Whatever you decide to do keep in mind that Ha is simply a thin slice of the R signal. Why would you go through the pain of capturing just Ha only to then add R back in? That makes no sense to me. Same with using Ha as the L for an RGB image. Assuming there is a blue component in an image why would you darken or lighten it based on Ha intensity? In an extreme example, if there's an area that has strong blue light but very little Ha then Ha as L would darken the blue in that area. That hardly seems productive. Conversely if there's lots of Ha and little blue then blue would be amplified, resulting in the Ha (red) becoming less prominent (salmon color anyone?).

Your mileage may vary

[Niall Saunders]

Hi Ken,

My first thought would be to ignore the deBayer step - at least in the way it was intended to be used.

Instead, I would be 'down-sampling', in a roundabout way, to extract a 0.5x0.5 image from each of the original RGBG filter arrays - you effectively end up with a 2x2 binned image, well, FOUR of them actually.

At the very least, you can 'sum' the two 'G' channels, or 'average' them.

Now you have 3 channels again, although the Rd channel may be strongest. But the Gn filter might also be surprisingly efficient as well - I don't know.

Maybe at this stage you could look at a false-colour RGB combine of these three binned images. Maybe you could just stay in Mono, and then think an HDRC process? Many different possibilities. Maybe you just have to dump the Bu channel, and maybe you can add the Rd and Gn data for your mono image?

You just have to experiment. If YOU like the result, then that one was absolutely the best processing method

Cheers,

[Nocturnal]

Niall,

the reason you do not want to do that is because the noise from the G and B pixels will be added to the R signal. I see three methods:

- extract just the R pixels from the raw frames (PI does not have a method to do this) and stack those, upsample 2x to match RGB
- debayer with super pixel, stack and extract R or first extract then stack (more efficient stacking), upsample
- debayer with bilinear, extract and stack or stack and extract. No upsample.

Don't use VNG or AHD debayer (PI doesn't have them) as these use more than just the R pixels to calculate the R channel.

[Carlos Milovic]

What Niall described is the "Super Pixel" technique.


PS: What is "HDRC" for you, Niall?

[Niall Saunders]

Yes Sander,

If you are using an HaNB filter over an OSC CCD, then only the Rd pixels are really going to have any 'useful' data - so you need to get to 'just' the Rd data. PixelMath or a PJSR can certainly be used to create the 'half-size' image that would be based on purely the Rd pixels, which would allow your first method to be implemented.

Would the lower resolution Ha data be of much use with a set of 'standard' RGB data thereafter (having been 'upsampled' once again, of course)? I don't know - but a gut feeling tells me that this would be unlikely, Perhaps 'downsampling' the RGB (or Binning RGB 2x2) might help - the final image only ever then being 1/4 of the size (pix x pix) of the overall CCD resolution.

It doesn't affect me at present - I am still working with either a DSI-IIC or a DSI-IIPro (with full filter-wheel). However, when I finally make the upgrade move at the end of the year (currently favouring the QHY9), I have a strong feeling that I will be aiming for an OSC again - just because of the incredibly short and very sporadic 'weather windows' we get here in NE Scotland, which just don't allow for 'multi-night' imaging sessions - so maybe I will be saying goodbye to my HaNB filter anyway. There is virtually NO chance that I will be able to consider both an OSC 'and' a Mono version of my next imager (unlike the case as was with my DSI models).

So, maybe I will be 'spared' the difficulties of NB imaging in the first place !!

Cheers,

[yock1960]

Hi Ken,

I'm neither a Guru or a Jedi  , but I am using a OSC (DSI-III) to collect a little Ha in order to boost my typically weaker luminance on a number of emission type targets and to keep imaging during a full moon. I extract the red channel and combine it to an RGB image using Pixel math, basically using the formula you gave, except that I do not change the blue channel. I found the formula from a thread here back in September. It has helped me on both M16 & NGC6888, especially the Crescent where otherwise the interior part of the nebula would be pretty bare.

Here's a link to my NGC6888 image:

http://home.fuse.net/yockeyml/astro/NGC6888haRGB.jpg

God knows how long it would take without the Ha. Both the Ha & RGB were about two hours @ 5 minutes.

Steve

[Nocturnal]

What Niall described is the "Super Pixel" technique.


PS: What is "HDRC" for you, Niall?

I don't agree Carlos, sorry. Niall suggested downsampling 2x. That's not the same as super pixel debayer and is in fact inferior because it does not throw away the R and B pixels. Super pixel and bilinear debayer only use R pixels for the R channel and B for the B channel etc. Then imaging Ha with an OSC camera you should not bin 2x2 for the same reason. You do not want whatever accumulated in the G and B pixels. For one you can not do effective hot/cold pixel repair on 2x2 binned images.

[harist]

Nice Article:
http://www.stark-labs.com/craig/articles/assets/LineFilterRecon_API.pdf

combined with
http://pixinsight.com/forum/index.php?topic=1591.0

At http://2.bp.blogspot.com/_9HcYqbvUc4s/SRcoj93hioI/AAAAAAAABm4/2E5Z1udeha4/s1600-h/Cygnus+Trio+Mosaic.jpg

is an APOD taken with QHY8 with narrowband filters (info from CN).

Tasos

[Simon Hicks]

Frankly I'm not sure what the use is of HaRGB mixing but I can see the use of replacing R with Ha resulting in HaGB

Surely there's potentially other structure in the R bandwidth that is outside of the 12nm (or 6nm or whatever your filter is) centered around 656nm. I think there are Si lines around there (Si II).

This still leaves the question of whether you want to distinguish that structure from the Ha structure (i.e. assign it to a different channel in the palette) or mix it with the Ha structure. Personal choice I guess.

[Carlos Milovic]

I don't think that Niall was talking about a "true" binning, or downsampling, but using just the color pixels to form 3 (or 4) subimages each half size of the original, containing only information of one bayer matrix element. That is almost the same as a super pixel technique.