Extracting green channel from FITS

[Bill Tschumy]

Karen,

Thanks for the analysis.  It sounds like either AIJ or ASTAP is handling this incorrectly.  I have posted a link to your response in the ASTAP forums to see what the developer thinks.

I've seen many places that Canon uses RGGB.  However, there could be an ambiguity in how you enumerate things.

Is RGGB this:

RG
GB

or

RG
BG

where in the second case you order starting from top left and proceeding in a clockwise direction.

[keastrid]

They are read left-to-right like text, as you see here.

[Bill Tschumy]

keastrid,

Thanks for the clarification.

I did hear back from Han the developer of ASTAP.  He has sent a request to join the AIJ forum so we can get this working the same.

In the meantime, he asked that I post these images.  He says:

The first is a marked up of the image from AstroImageJ. The left bottom pixel is position 1,1 as indicated.

https://sourceforge.net/p/astap-program/discussion/general/thread/f23b0d61db/7f13/attachment/image_RGGB_2.jpg

The second image is a special test file i made some time ago. RG means RGGB.  This is what you see if you specify RGGB pattern. Only the yellow marked is correct red, green, blue

https://sourceforge.net/p/astap-program/discussion/general/thread/f23b0d61db/c8b1/attachment/test%20RGGB.png

I'm not totally sure how these will resolve the issue, but maybe someone smarter than I can tell.

[karenacollins]

Hi Bill,

Thanks for the info from Han.

As a possible help, could you take an daytime photo of a green surface (and likewise red and blue surfaces, if practical), so that we can see which pixels from your camera are for sure R, G, B?

Karen

[han.k]

The link to the FITs file posted earlier has a RGGB debayer/demosaic pattern.

The RGGB pattern should be interpretated as follows (corrected 2022-03-03):


So pixel 1,1 is top left.

Attached in a ZIP file a FITs image for testing the four possible patterns. I created it because it made testing much more simple.

bayer_test_pattern.zip

For demosaic pattern RGGB it shows this:



So for RGGB=RG it shows (yellow marked) from left to right  red, green, blue.


To complicate things they invented a new keyword ROWORDER (not used in the ZWO FITS), see:

https://free-astro.org/index.php?title=Siril:FITS_orientation

I'm not so happy about keyword ROWORDER but that was created.

Other keywords to include in the final debayer pattern are:
XBAYROFF
YBAYROFF

See:
https://cdn.diffractionlimited.com/help/maximdl/FITS_File_Header_Definitions.htm


It would be much simpler if the processing software would update the value of keyword BAYERPAT after each manipulation but some preferred to maintain the orginal BAYERPAT value.


Han,
author of ASTAP

[Bill Tschumy]

This was surprisingly hard to do.  I had to take then through my scope using the ASIAir camera control software.  The images are out of focus because my scope would not focus that close.   I put a green bucket, a blue bucket an a red snow shovel in front of them.  Hopefully they will be useful

The ASIAir software does specify RGGB in the FITS header.  The Canon camera is common and surely someone would have said something by now if this was wrong.

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

[han.k]

Thank Bill. The blue and red bucket images are almost saturated. So it is difficult to recognize but enough to see the pattern. I made a mistake with the previous drawing. With BAYERPAT= 'RGGB' and no other keywords it is as follows:



Here some more test files I made some time ago with all keywords ROWORDER, XBAYROFF,  YBAYROFF

bayer_pattern1.zip

bayer_pattern2.zip

bayer_pattern3.zip

bayer_pattern4.zip

They should all look like this:




Han

[karenacollins]

Hi Han,

Thank you for the additional information. I'm still a bit confused on the notation. If we assume that only the BAYERPAT = RGGB keyword exists and that the pixels in the lower-left of the screen grab below are the lower left-most pixels in the fits image, would the RGGB pixel locations in the first "super-pixel" be as marked in blue?

[han.k]

Hi Karen,
Yes it can be highly confusing. Lets talk about FITS X and FITS Y only. I see in astroimageJ you also have AstroimageJ X, Y

Having only BAYERPAT='RGGB'

FITS X =1 (odd)  FITS Y=1 (odd)   pixel is red.    
FITS X =2 (even)  FITS Y=1 (odd)   pixel is green.
FITS X =1 (odd)  FITS Y=2 (even)   pixel is green.    
FITS X =2 (even)  FITS Y=2 (even)   pixel is blue.    

--------------------------------------------------

Nothing changes if you add:
ROWORDER= 'TOP-DOWN'           / Order of the rows in image array  
So this is the default.

[han.k]

If you find keyword:
ROWORDER= 'BOTTOM-UP'          / Order of the rows in image array

Then the image is flipped vertical. So

RG
GB

becomes

GB
RG

Similar with XBAYROFF and YBARYOFF, They are default zero. Just check if these values are odd or even and shift/flip if odd.

All to maintain the RGGB definition for a camera model. :(

[karenacollins]

Hi Han,

Great, that seems to match the blue labels in the above screen grab (again, assuming that the set of 4 blue marked pixels are the lower left of the unflipped, unrotated fits image).

We'll make the modifications so that our extraction is consistent with ASTAP.

Thanks!
Karen

[han.k]

Hi Karen,

I double checked again my test images with Siril, CCDCiel and Pixinsight program and they display the colour correctly so that is confirmed. The only difference it that some programs flip the image vertical on ROWORDER and other only flip the Bayer pattern but that doesn't matter for astronomy.


Something totally different. I promote the better use of TIFF files for astronomy. Would it technically be possible that AstroImageJ could read KEYWORDS from a TIFF file description? This specification makes conversion between TIFF and FITS  possible without loosing the header info. See the draft specification here:

https://astro-tiff.sourceforge.io/ 

I used it currently for saving disk space used for raw files. We typically produce raw files in the thousands. This is easier to implement then the RICE compression (cfitsio) as specified in the FITS standard with almost the same compression performance.

I don't want to generate work for you. Only if you have some spare time or have a trainee without work :)

Thanks, Han

[karenacollins]

Hi Han,

I'm not sure if it meets the spec you linked, but the underlying IJ will write TIFF images with headers and read them back in as if they had been saved in fits format. If you have AIJ installed, have you tried to see if they will already open? If you are not set up to test easily, just make an example available somewhere that we can use for testing.

If it doesn't work out of the box, we'll add a feature request and schedule it depending on the complexity of the implementation.

Karen

[han.k]

Hi Karen,

I was not aware AstroImageJ did something similar. I tested it using the latest AstroImageJ and studied the exported TIFF file.

Using a hex editor and TIFF analyse program, I can see the full FITS header is stored by AstroImageJ in tag 50389. That's very interesting. This is more or less the same solution as developed and implemented by some programs now. The only major difference is that we use the standard ImageDescribtion tag 270 and ASCII rather then byte format. The advantage of tag 270 is that it is always available in TIFF readers. Tag 50389 is not always readable by TIFF readers and could be overwritten.

Assuming this is an easy modification can your consider adding support reading tag 270 ?
AstroImageJ already writes a small amount of info in tag 270.

The so called Astro-TIFF sample using tag 270 are all available in the specification webpage:
https://astro-tiff.sourceforge.io/


Thanks, Han

[keastrid]

Hi Han,

For the xBAYROFF keywords, is it just a transformation of the superpixel orientation, or is there an actual "shift" involved? And their application is just a transform of the superpixel in x/y if odd, no change if even?

Are the keywords ever used together (and with ROWORDER), and if so is there an application order?

[han.k]

The purpose of the XBAYROFF and YBAYROFF is when rows of columns are skipped. I assume for area which used a dark reference in some sensors.  They are rare maybe very rarely used. If you crop an image in MaximDL they are not generated. So that is surprising.

Since Bayer pattern is 2x2 you only have to apply them if the value is odd. An odd value is the same as flipping the pattern or shifting one pixel.

They can all occur. So an odd value for YBAYROFF is the same as ROWORDER= 'BOTTOM-UP' if both  are in the header they nullify each other.  But I never found a file for testing.  Maybe we should ask the makers of MaximDL for a sample.

Han

[han.k]

Looking in my collection of FITS files downloaded from nova.astrometry.net (few hunderd files),  I found only two files with an XBAYROFF=1  There where many more with XBAYROFF=0. These two where created by SharpCap.

The brightest star in the file linked should be pretty red.  Strange enough Pixinsight, Siril make the sky purple. ASTAP and CCDCiel make a greenish sky. So here there is difference interpretation.

Since it is rare XBAYROFF=1 or odd, you could consider to skip reading XBAYROFF, YBAYROFF.  This makes it much more simple.  Keyword ROWORDER is now much more used.

Here is one file:
https://ufile.io/xbxzipg9

Han

[karenacollins]

Hi Han,

Thanks for the research on the TIFF file header support. We will add this to our issue tracking system, and can hopefully add support for tag 270 soon.

Kevin, we'll need to figure out how to seamlessly support the current IJ formatted TIFF file headers and the new format.

Karen

[karenacollins]

Hi Bill,

AIJ versions 5.0.3 (and later) now have the pixel interpretations corrected according to FITS pixel ordering (as kindly described above by Han). We believe that the ROWORDER, XBAYROFF, and YBAYROFF keywords are also implemented as described by Han in this post. Let us know if you spot any problems with the functionality.

Han, we'd also welcome any expert testing and feedback you may have too.

To update AIJ, go to Toolbar > Help > Update AIJ and select either the daily build or 5.0.3 or later.

Kevin, thanks for your work on this!

Cheers,
Karen

[han.k]

Hello Karen,

I have installed 5.0.3.00

Unfortunately I think the pattern G-B-G-B and G-R-G-R are mixed up for debayering. I have converted my test files to 16 bit since AstroImageJ doesn't accept 8 bit images. See below.

I'm checking also for the other keywords but noticed a discrepancy between PixInsight and ASTAP I need to investigate. Somehow these four simple pattern result in bugs. Should be simple but it is not.

Han

updated v4
bayer_pattern_v4.zip