One-shot color camera and rotation of frames prior to de-bayering

[Philip de Louraille]

Observation: After the fact, the result is obvious but should the software handle the case?

Case: I took several shot of M47 a few weeks ago spread in different days at different times.
In one of the series, the data was obtained after M47 was past the Meridian so the data was rotated 180°.
Rookie error (presumably!) I rotated the corrected but still bayered FITS.
Debayered the whole set. Did the alignment, stacking, ... blah blah blah and the stars had the wrong color. What should have been a blue star was red and vice-versa.
So I figured it out by processing each data set independently. The corrupted one was the one I had rotated. Aha! The debayering step. The color matrix was wrong. I had used the default GBRG and should have used (for that set only) GRBG.

But... come to think of it... and since we are using computers... and astronomical software, I was thinking that this should be taken care of automatically... Are there keywords in the FIT linguistic which would indicate the proper debayering matrix to apply and if so, when a frame is rotated, be changed appropriately?

I'd like to keep my data bayered as it takes less physical room on disk. And after a while I won't remember which data got rotated or not and this is a problem when I want to stack data gathered over several years.

So, to sum, should I debayer my (dark-bias-flat corrected) data ASAP and store it that way to keep my then "raw" data? What do you guys do for that scenario?

[Carlos Milovic]

I would go for debayerization... blank DVDs are so cheap these days, that I wouldn't care to use one or two to save the data.
Another option is to separate the files into two or more folders, each one named after the debayer matrix that is needed (or, just create a text file with a "log". Finally, you have the option to add a suffix to your images, telling the rotation angle.

[Nocturnal]

I pile all the images into DeepSkyStacker and it does all the work for me. Doesn't matter how much rotation there is. It rotates right after debayering which is what you should do too probably.

- calibrate
- debayer
- register
- stack

I haven't tried calibration in PI yet but I know the registration part can deal with arbitrary rotation so that should be cool. I'm pretty sure you should debayer before registering. The raw image does not have proper star shapes so that might cause issues with star detection.

[h0ughy]

I pile all the images into DeepSkyStacker and it does all the work for me. Doesn't matter how much rotation there is. It rotates right after debayering which is what you should do too probably.

- calibrate
- debayer
- register
- stack

I haven't tried calibration in PI yet but I know the registration part can deal with arbitrary rotation so that should be cool. I'm pretty sure you should debayer before registering. The raw image does not have proper star shapes so that might cause issues with star detection.

i do exactly the  same thing I stack in DSS then use PI to process. 

[budguinn]

If I'm understanding you......it should make no difference on which side of the meridian you take the shots......if you leave everything alone, the debayer will always be the same.....and I would keep them debayered for storage.

Then, once you've debayered them, you can look at the whole set (before and after meridian) with the new blink facility/script and immediately notice which ones need to be rotated...(if you forget in a few months).

I wouldn't do a lot of flipping things until you get them calibrated and debayered.  Remember, if you flip it to debayer, then you're going to have to something with your flats..darks and biases.......depending on which order you do things.

bud

[Nocturnal]

You almost got it Bud except the part where you blink the images and flip them. That step is not necessary. As I understand it the PI registering process is at least as powerful as the one in DeepSkyStacker and it'll happily register pre- and post meridian flips. I do this all the time. DSS has been doing this for years and it wouldn't make much sense for PI not to offer this. In fact I have registered images with disimilar sizes, angles and scales with PI without any issue. I have for example downloaded Deep Sky Survey images from ESO and registered these with images I was working on.

[budguinn]

Hi Sander,

I didn't know that...and it is a nice feature.

I was mainly concerned with his wanting to flip things before debayering...could cause lots of problems.

[Nocturnal]

Hi bud,

yes, I shared your concern which is why I listed the sequence of steps that should be followed. They don't include 'flip as needed'

Give the image registering a try with some disimilar images. You can even create your own. Load an image, clone it and then resize, crop, flip and rotate it. See if the register module can still recover the image. Clearly the cropped areas are gone but it should overlay what it can. If you get to case that doesn't work anymore, let us know

I guess this'll be a nice demonstration for MWAIC I just made up

[Niall Saunders]

Hi Guys,

The way I have always understood things when working with OSC (Bayered) data, is that you 'should not' do any deBayering until after you have fully calibrated your raw data, and that you 'must not' deBayer after you do anything involving alignment or registration.

So, deBayering ONLY fits in at one specific place in your workflaw - much like all the other steps actually. Very few steps can be carried out anywhere in the timeline other than where they are 'supposed' to be carried out.

And, as far as 'storage' is concerned, that subject is a non-starter for me, when you can buy a 1TB hard drive for $50

Cheers,