extracting just the red channel from a canon CR2 raw file?

[pfile]

if i shoot with a Ha filter, then of course some light leaks into the G and B channels.

it would seem that you want to get rid of the G and B channels. however, debayering and then throwing away the G and B channels is probably wrong, because you've 'polluted' your red pixels with noisy data from the G and B channels during interpolation (right?)

so how do you extract just the R channel out of the CR2 file (or the calibrated .fits file) if it is in CFA format, and make it a monochrome image? if i understand this right i will end up with an image that is only 1/4 the size of the advertised sensor size, but it will be 'pure' red data.

thanks.

[Nocturnal]

Hi,

using the bilinear and superpixel debayer in PI there is no 'pollution' of color data with other channels. You can debayer, extract colors and discard G and B. I don't know how this is done in raw conversion.

[Simon Hicks]

Pfile, I had exactly the same issue....so I asked the same question. Then S.J Brown created the BatchChannelExtraction script.....its in the Script / Utilities section. Thank You Mr Brown!  8)

Just open the script, load in all you CR2 raw files, tick the Red Channel, and untick the Green and Blue Channels. I get the script to save all the files as 16bit tiffs and then load them into DSS for calibration and stacking....or you could carry on doing all that in PI.

[pfile]

@sander thanks. i'll be calibrating the frames with PI anyway so i'll have CFA fits files, so i guess the raw thing does not matter too much.

@simon i should read that script and see if it's doing anything special.

[Nocturnal]

You could take the lazy approach and simply stack your RGB files as-is and extract R from the stacked image. Stacking will be faster on monochrome images but there are extra steps and storage space to consider too. Options As most time during stacking is spent registering the subs I am not sure how much time you'd save with mono vs. RGB images with the same star content. An interesting experiment I suppose. I'm sure things like CPU and IO speed can shift the balance back and forth.

[sjbrown]

Pfile,

If you use the Extraction script you will need to run it twice. Once to extract the red channel from the raw files(CR2) and
a second time after debayering the calibrated files. The debayer process will create an RGB image from the single red channel.
The green and blue channels creted are completely flat grey channels with no data so they must be removed.
The superpixel method retains the 1/4 image size that you would expect from having just the red (or blue) channel.

Hope this helps.

John

[pfile]

a further question about this very old question...

...what happens to the G channel when you do superpixel debayering in Pixinsight? are the 2 G pixels averaged? in this message:

http://pixinsight.com/forum/index.php?PHPSESSID=95fdb2ac0b5653573249de19628ef99d&topic=1757.msg10456#msg10456

Juan says the two G pixels get averaged. is that correct?

thanks.

[Nocturnal]

Yes, that's correct. What else could we do?

[pfile]

ignore one of them, or (obviously not what is happening) create 2 green channels.

proper calibration would *probably* alleviate this problem, but i can see a case where one of the 2 green pixels is hot or stuck and so by averaging them at debayer time you lose the ability to reject one of them as an outlier. you might end up rejecting the averaged pixel because it's value shot up due to the hot pixel, but then you lost 1/2 that averaged pixel...

[Nocturnal]

I recommend dealing with hot pixels before calibrating and stacking if possible. I typically use AHD debayering and hot pixels generally get removed with sigma stacking and dithering even though lots of averaging is happening. If I find that hot/cold pixels remain I may restack after dealing with the hot pixels.

I don't see any other way to deal with this. With a sample size of 2 it's impossible to tell which pixel is the one to drop. Can't even use full image statistics because it may just be the edge of a well focused star.

[pfile]

i don't think AHD debayering will work well with narrowband filters... it's my understanding that AHD does consider the other two channels while trying to reconstruct the current channel.

i think what i was trying to describe is that you capture 10 OIII images with your DSLR, then this hypothetical superpixel debayering algorithm produces 20 G images which you then stack. outlying G pixels would be easily rejected in that case, regardless of where they came from in the CFA.

since calibration is performed on the CFA data, if there is a hot G pixel it should get taken care of to a certain extent. but as i was saying in the end a hot G pixel averaged with its good neighbor could result in rejection of the whole pixel, when half the data was good data.

[pfile]

by the way with help from Zbynek on the pixelmath, i did manage to do a RGGB superpixel extraction on OIII data captured with my 50d.

i had 17 30-minute exposures of the OIII component of the veil nebula. so i registered and integrated the G, G and B channels (51 subs).

as a reference i did a 'regular' superpixel debayering of the 17 subs, and then registered and integrated the 17 GG subs and the 17 B subs together.

as it turns out the SNR result was slightly better on the GG+B subs. i'm going to assume that because pixinsight can do SNR weighting of the subs this worked out, but in a program that can't weight the subs the result might have been different.

together with this OIII data, i also had 24x30min of 6nm Ha. the result is here:

http://www.flickr.com/photos/pfile/6333252837/in/photostream/

[Lex]

Pfile,

really nice result; congrats!!