Different fits formats

[MikeB838]

Hi,

I have a problem debayering the single raw fits frames.

Preface: my camera is a PlayerOne Neptune-C II color camera (RGGB), I use SC V4.1.12516 Pro.

I use Astrometrica and need a single color fits file for it. So I use Fitswork to split an RGB-Fits file into 3 single color files.
There was no problem when using the RGB24 format in SC either with a stack of frames or with a single frame fits file.

Thanks to Robin's hint I changed my capture format to RAW16. Better quality and still no problem to split the stacked fits files into the 3 color files.

But the rawframes seem to have a different format. Siril says its B&B (no more RGB) and Fitswork only produces a red frame as output.

I found the notice in the forum about using Pipp for separating the color channels ("HOWTO Debayer Captured Images"), but when using it as described, I get a result which looks different on the left and the right half of the result (no matter which debayer pattern
I use). Here is an example (screenshot of a result loaded into Astrometria):

rggb_pattern_used.jpg (50.27 KiB) Viewed 6969 times

So Pipp seems to have problems with the single raw frames.

I tried Astap too, but had no success or did it wrong.

The big question: How do the raw fits frames and the stack-fits-frame differ?? Can something be changed for the single raw frames?

So I'm stuck at the moment. I would like to use the green channel on single raw frames sometimes. Have I to switch back to rgb24 format for capturing? Or can I use another program or trick to debayer my single raw16 raw frames (besides Pipp)?

Thanks for looking into it!

Cheers
Mike

[admin]

Hi Mike,

saved stacks from colour cameras are always(*) in RGB (three colour channel format) - this is because it's essential to debayer from RAW images to full colour before the alignment of the new frame with the stack is performed. (*) always, unless you turn off the alignment in live stacking, anyway.

Saved unstacked image files in RAW16 (or RAW8 for that matter) are still in bayer format, so have a single colour plane and may appear as monochrome to some software. The FITS headers 'BAYERPAT' and 'COLORTYP' are added by SharpCap and some image processing software spots these and understands that the file is a RAW colour file, but lots of software ignores them.

In most software you will find an option to force the software to treate single channel FITS files as RAW images, but of course in different places in different software. If you search for "<name of software> debayer" you will usually come up with the info you need.

I'm afraid I'm not quite sure what is going on with the PIPP image screenshot that you have shared. I just tried processing a RAW FITS image through PIPP with the option to debayer turned on, and the output looked perfectly normal (I viewed in FITSLiberator). This was both with and without the 'split channels' option in PIPP.

cheers,

Robin

[MikeB838]

Hi Robin,

thanks for the information.
It seems that when capturing in RGB24, the raw frames are different from the raw frames when capturing in RAW16.

I put a RAW16 frame at:
www.twus.de/frame_00016.zip

May be you can try to debayer it in Pipp. May be I'm doing sth. wrong. Thank you very much.

I try to find another way. In the moment I check if AstroImageJ can help me. I'll see

Cheers,
Mike

[Chuckwagon]

Hi Mike,

I'm sure Robin will have more and better ideas than I would, but I was curious and grabbed your file to see what it looked like. (The link was messed up, it has the shaprcap forum address appended to the front of your link, but I removed it manually and the file downloaded.)

If I open your file with PIPP, I can get it to show color if I go to Input Options and in the Color Debayer section select the Debayer Monochrome Frames and use RGGB. Then on the Output Options tab, in the Color (RGB) Channel Splitting section, select the Split RGB Channels box. Then when I Do Process I get three fits files, one for each color. Sadly, for me, the resulting images are oddly shifted so the frame is split down the middle with the edge of the frame in the center, so the right half of the image is on the left. I don't know if that's a setting somewhere, or just the fact my version of PIPP is old, or I'm just not experienced enough to know what causes that. But the image does load (M27, right?) and can show color if debayered properly. Just need to figure out why it shifts the image around. Maybe there is a Header that can be changed to get the behavior to change. Perhaps Robin has a suggestion.

It is interesting that FITS Liberator sees the file as a single layer image, even though there are obviously 3 layers there. Don't know what's going on there.

As an aside, you can try downloading ASI Studio from ZWO, and use it's built-in ASIfitsview program to see your image. When I load your image with that it shows as color and stretches so the subject is easily seen. I don't think you need an ASI camera to use it, I didn't have any camera on the system I was testing with.

Good luck,
Chuck

P.S. - I did some more playing (I'm bored today) and Siril will open your file and debayer it without it being shifted/split down the middle. (It seems to be upside down, but that's easy to fix.) Then it can extract the 3 color channels and save them as fits files. I did that, then I converted them to mono png files, loaded into Photoshop, and combined the three channels back to an RGB image. Worked fine. So I'd suggest trying Siril to manipulate the file the way you want. Here is the result after some Photoshop levels and Topaz noise reduction.

Mike's M27.jpg (476.79 KiB) Viewed 6934 times

[turfpit]

Curiosity got the better of me with this. Below is some clarification, hopefully to save others time.

Firstly, the correct download link is www.twus.de/frame_00016.zip

To clarify the 'single layer v 3 layers' statement.

An undebayered FITS image will show Image data as Plane 1 only. A debayered FITS image will show Image data as 3 planes - Plane 1, Plane 2, Plane 3. These are the 3 colours extracted by the debayer process. This is why the debayered file is 3 times the size of the undebayered file (8Mb v 24Mb). Output below is from FITS Liberator.

undebayered_v_debayered.JPG (54.39 KiB) Viewed 6907 times

In order for modern image processing software to correctly interpret the image, the following need to be present in the FITS Header (ROWORDER and the Bayer pattern):

FITS-header.JPG (26.63 KiB) Viewed 6907 times

Clearly the information required (highlighted) is present.

I then debayered the single frame in PixInsight (v1.8.9-3 build 1612) using my default setting of ROWORDER=TOP-DOWN and AUTO detect bayer pattern, stretched the image and exported it as a PNG file. This result looks correct.

PI-debayer.JPG (46.17 KiB) Viewed 6907 times

Using ChannelExtraction, 3 separate images were produced - R, G, B.

When using PIPP (x64 v2.5.9) and selecting the RGGB pattern, this gave the split image:

debayer-PIPP.JPG (82.83 KiB) Viewed 6907 times

The same result was obtained using GBRG (to test ROWORDER). The other 2 patterns also produced the split image.

A test with Siril (v 1.2.3) correctly auto debayered the FITS image (although it was flipped, which is just a setting). The image was able to be split into R, G and B frames.

debayer-Siril.JPG (29.61 KiB) Viewed 6905 times

Astro Pixel Processor (v2.0.0 beta29) also correctly interpreted the frame.

debayer-APP.JPG (99.46 KiB) Viewed 6902 times

Summary: PixInsight, Siril and Astro Pixel Processor were able to correctly debayer the image. PIPP resulted in a split image.
Draw your own conclusions from this.

Dave

[MikeB838]

Hi Chuck and Dave,

thank you very much for giving it a try. My intention is to get the three single color files out of this raw fits file.

ASIfitsview debayers it correctly but seems not to be able to save the result as a fits file.

But trying again I now was able to debayer the file with Siril (I did not get it done beforehand).
I can now split the resulting file into the 3 color files successfully with Fitswork again and I'm happy

Thanks for nudging me in the right direction!

best greetings
Mike

[admin]

Hi folks,

glad this looks to be resolved as a (rare) PIPP bug by the look of things. Sadly PIPP seems to be no longer updated or supported, so we will have to just work around things like this.

cheers,

Robin

[turfpit]

Having dwelt on this, I have never before debayered a FITS file using PIPP. I gave it a try with one of my captured FITS file.

Captured with Altair 183C in 2019 (I don't have any SC v4.1 suitable data) using SharpCap 3.2- raw file stretched:

undebayered.JPG (93.48 KiB) Viewed 6800 times

Debayered in PIPP using RGGB, output written as a FITS file and stretched:

debayered.JPG (130.65 KiB) Viewed 6800 times

This (PIPP debayer of FITS) seems to have worked (no split image).

Puzzling.

Dave

[MikeB838]

Yes it is puzzeling.
But I see that Pipp does remove all the info from the Fits file that I need when using the file in Astrometrica.
But the solution debayering in Siril and splitting in Fitswork does work good for me.
But it is a pitty that Pipp is lo longer maintained.

Cheers,
Mike

[ikeken]

I stumbled on the same problem.
I found that ASIFitsView could read fits correctly, but it still seemed necessary to use PIPP to process thousands of photos.

As a tip about ASIFitsView (v1.15.1), you can actually select multiple files in the upper right corner of the screen. Right click and you will see the menu “Save the selected as tiff”.
It would be nice if ctrl+A could be used to select all, but that did not work.
You can select all by clicking on the first photo, then scrolling to the last photo, then holding shift and clicking on the last photo.

This allows you to convert all tiffs at once.
The output tiff was not de-bayered. However, PIPP (version 2.5.9) recognized this tiff correctly.

Ken