Extracting green channel from FITS

[karenacollins]

Yes to clarify, the new functionality is under the menu item Color > "Photometric Friendly Debayer" rather than the "Debayer Image". I need to work with Kevin to find a better name.

We use the following notation to define the layout of the 4 super-pixels.
RGGB
BGGR
GBRG
GRBG

I compare pixels and all 4 modes seemed to be correct as far as I can see. I haven't check combinations with the other keywords, but did take a quick look at Kevin's code.

Let's us know if that is the option you were using and saw the possible incorrect implementation, or if you do check it out and see a problem.

We will investigate supporting 8 bit images.

Karen

[han.k]

I made an conversion mistake (flipped vertical) for the bottom up version. I have renamed them now to v4 and uploaded again.

It doesn't change the observation that in AstroImageJ G-B-G-B is swapped with G-R-G-R

Han

[han.k]

Hello Karen,

Try file "bayer_test pattern 16 bit.fits

I have used option "Debayer Image (FITS header aware)". Then check option "Display Colour Image?". Try the four debayer pattern options and you will see two are swapped.

Menu "Photometric Friendly Debayer", does not seem to do anything.

bayer_pattern_v4.zip

Han

[karenacollins]

You should see a small box that opens in the middle of the screen with a few options. The default pattern option is pulled from the fits header. Then select OK. Up to 4 new 1/4 images will be created.

[han.k]

karenacollins wrote

You should see a small box that opens in the middle of the screen with a few options. The default pattern option is pulled from the fits header. Then select OK. Up to 4 new 1/4 images will be created.

I see it now. It only comes when keyword BAYERPAT is available. Not when it is missing as in my test files.

I have added a BAYERPAT kewword in my test file and tested with RGGB. Then green is black in the green extract. So it looks like red and blue are swapped with green green.

Han

[han.k]

Hello Karen,

I have created a total of 9 test images for all possibilities. Tested them in ASTAP, Siril and CCDCiel programs. Debayering in all programs gave the same result. Testing in PixInsight gave the same pattern except for the files with the keys XBAYROFF  or YBAYROFF unequal to zero.

All have a BAYERPAT='RGGB' defined in the header.

The nine test files:
bayer_test_version5.zip

The files are:
bayer_test_pattern v5 16 bit.fit
bayer_test_pattern v5 row order is top-down 16 bit.fits
bayer_test_pattern v5 roworder is bottom-up 16 bit.fits
bayer_test_pattern v5 roworder is bottom-up, xbayroff=0, ybayroff=1, 16 bit.fits
bayer_test_pattern v5 roworder is bottom-up, xbayroff=1, ybayroff=0, 16 bit.fits
bayer_test_pattern v5 roworder is bottom-up, xbayroff=1, ybayroff=1, 16 bit.fits
bayer_test_pattern v5 roworder is top-down, xbayroff=0, ybayroff=1, 16 bit.fits
bayer_test_pattern v5 roworder is top-down, xbayroff=1, ybayroff=0, 16 bit.fits
bayer_test_pattern v5 roworder is top-down, xbayroff=1, ybayroff=1, 16 bit.fits

In colour with RGGB defined they should all display:


When extracting the both green sensitive pixels it should display:



This should help to debug. The files will be useful for future testing, so making them was not a problem for me.

Hope this helps, Han



                                                                                               

[keastrid]

Thank you for the test images!

We should now be correctly transforming the superpixels based on the header, pending a new daily build.

8-bit images are also accepted now as well.

The TIFF format change has been added to the issue tracker as well.

Kevin

[Bill Tschumy]

Karen, Kevin and Han,

Thank you so much for all working together to get this feature in AstroImageJ.  With the test images from Han, I can now feel confident this is all implemented correctly.

I assume the new version will not be available until tomorrow (Saturday, March 5th)?

Bill

[han.k]

Bill,

It is always good to check and double check every part of the system. Can you repeat the test with your system using red, green and blue coloured buckets or other coloured items but with a much shorter exposure time to avoid pixel saturation? Or if it is possible to remove the camera and use a standard lens to image a computer monitor with this test image:

Han

[karenacollins]

Hi Bill and Han,

I have updated the daily build with Kevin's latest debayer fixes. He believes all problems are resolved based on Han's test images. If either of you find different results, please let know. If all works as expected, we'd be happy to hear that too.

Bill, I agree with Han that it would be helpful to send us an image from your camera as requested below, just as a triple check on everything.

You will see version 5.0.3.01 or later after the daily build update.

The fixes are:
-Renamed debayer options (see more below)
-Support for 8 bit debayering
-Fixed debayer not opening on missing keyword
-Corrections to debayer pixel interpretations

Note that the debayer option we are discussing here has been renamed to Color > "Debayer to single color/luminosity 1/4 size stack(s)"

The other option is now named "Debayer with demosaicing and smoothing options". If there are problems with the bayer patterns in this option, we will fix them, but as a medium priority at this point since the code is from a 3rd party plugin and there are apparently no present user reported issues. Nevertheless, please do report any issues.

Karen

[karenacollins]

Hi Han,

Thanks for making the test images. I'm confused about the orientation. When displayed in AIJ or DS9 with no image flip and no image rotation, they show upside down (i.e. flipped in the Y-axis). Is that expected? What is the key image distinction we should see when separating the images into individual R, G, and B single color images?

Karen

[han.k]

Hello Karen,

Yes the images are upside down (Y-axis) also in ASTAP. That is maybe not so nice. I only focused on the debayer pattern.

No problem, I will rework the image to have them correctly orientated for future reference. I'm now heavily familiar with the topic again so that is a minor exercise. So all images vertical will be flipped but no effect on the debayering. I will arrange to get them on a webpage for future use. Standardization is important for all.

It is a little unclear to me what you mean with image distinction.

Note some programs also flip the image vertical when keyword ROWORDER='BOTTOM-UP' is specified. But personally I would not do that. That will be more confusing in my opinion. It is already a little idiotic that we have four keywords for only 4 different Bayer patterns.

Han

[karenacollins]

No problem on the upside down. I was just comparing to the image posted above. I guess I was thinking the images were encoded in a way that when the colors are debayered into the 3 respective stacks, displayed items in a specific color would only show up in one of the three stacks. But I see that these are to apparently help determine which of 4 debayer patterns should be extracted. I think a nice image to have would be encoded in standard RGGB mode, with some R, G, and B colored symbols of unique shapes and corresponding text in the corresponding same colored pixels. Then when the correct debayer routine runs, one should see only the corresponding colored text and symbols transferred to their respective 1/4 stack.

Karen

[han.k]

Maybe there are some other patterns possible but the coloured areas was easiest to create. I have reworked the images as v6. Same deBayer result as v5. Only the orientation is flipped and you can start counting from FITS pixel position 1,1.

Han

bayer_test_pattern_v6.zip

[Bill Tschumy]

Han,

I will try taking a picture of the RGB image.  Might need to wait a few days because the weather is bad right now.

Bill

[Bill Tschumy]

OK, I shot some test images using ASIAir Pro.  I used the Red Green Blue image posted by Han.

This is with the most recent db5.0.4 AIJ build.

Unfortunately, something is still not right.  If I extract the Green channel using ASTAP, it looks very close to what AIJ gives for the Blue channel.  The AIJ Green channel doesn't look like it the ASTAP TG image at all.

I suspect ASTAP is correct because the Green rectangle is brighter in the green extracted image (as you would expect).  With AIJ it is the blue rectangle that looks brighter in the green extraction.

ASTAP: RGB_Test_TG.fit
AIJ: RGB_Test.fit (GREEN).fits

Maybe ASIAir Pro is doing something wrong with the keywords in the image

I am using RGGB for the Bayer pattern (which is also what ASIAir places in the fits file for my Canon 700D).

Here are the files:

https://www.otherwise.com/RGB_2.zip

[Bill Tschumy]

I should also mention that if I open the 3 color RGB_Test.fit in Affinity Photo with the RGGB pattern, it does look correct.  Not of the other bayer patterns look right.

[han.k]

Thanks Bill.

This confirms that for ASTAP all works correct. I'm sure Karen and Kevin will fix it in the next AstroImageJ

This time the signal is weak. Not a problem it confirms everything. The background pixel value is about 8300 there is some colour leak into the other Bayer pixels. The even and odd indication is in FITS coordinates.

BAYERPAT 'RGGB', image by ZWO ASIAir:

Original image, pixel values in the green area:
green ~15000   [even,odd pixels]
green ~15000   [odd even pixels]
blue   ~10000
red    ~10000

Original image, values in the red area
red ~10300   [odd, odd pixels]
other colours ~9000


Original image, values in the blue area    
blue  ~13000 [even,even pixels]
other colours, ~9600, ~8300 ~9700


Now the extract values in the 1/4 image:

ASTAP Green_TG  Green extract
green area 15074 (average)

ASTAP Red_TR extract
red area 10610 (average)

ASTAP Blue_TB extract
blue area 12864 (average)

[karenacollins]

Hi Bill,

Many thanks for the Canon EOS 700D image of Han's R G B test pattern on your computer screen. It is the true test of ensuring the colors are being extracted correctly.

Kevin fixed a problem in the AIJ extraction this morning, and I have uploaded the fix to the latest daily build (v5.0.3.02 or later, after update). The results should now be correct, and I believe match the ASTAP results.

Your image shows the red, green, and blue areas as the brightest areas in the AIJ extracted 1/4 size red, green, and blue images, respectively.

Also, I believe that all 9 of Han's v6 test images are now interpreted correctly too, as well as a separate one that I created.

We'll push this latest version to a numbered build soon, but use the daily build for now for correct extractions.

Thank you for highlighting this deficiency in AIJ, and thanks to Han for helping us get the ASTAP and AIJ results to be consistent.

Do let us know if you notice other possible problems.

Karen

[han.k]

Thanks Karen,

For version 5.03.02

Using Bill latest image:

The menu "Debayer to single color/luminosity 1/4 size stacks" works good. All three image have the correct pixel values.

For the menu "Debayer with demosaicing and smoothing option" plus check on "Display colour image", It starts default with order B-G-B-G.  I have to select pattern G-R-G-R to get the correct colours for Bill's latest image. The same RGGB pattern should be displayed default and work.

Han