First Experience with Mosaics

Hi Peter and thanks for trying out APP!

I must say, missing channels is a completely new issue to me. So I'm thinking towards the capture process here. Why are you using PNG files for instance? It's better to go with raw data and doing the processing on those.

Thanks Vince. I think the issue here is why are the PNG files not working, rather than why am I using them 😊. On further investigation here is the behaviour I have observed:

Step 1 – integration of the PNG subs for each panel using RGGB, Ha-OIII color, Force de-bayer in tab (0).  Two of the six resulting FITS files have ‘normal’ coloration. The other four have color issues. Taking one example, it shows a severe blue cast in the image viewer and the histogram is all blue. Reviewed in FITS Liberator, only the blue channel has data. I used the APP image viewer filters to review the subs after each stage. The colors are OK until Normalization, at which point the blue cast is introduced. I re-ran the Integrations omitting the Normalization step and the problem disappeared. I now have six good integrations.

Step 2 – integration of the six FITS files from step 1 using the appropriate parameter settings for Mosaics. Results were depressingly similar to step 1 – remember these are FITS files now, not PNG!  In the final image, color cast issues re-emerge on the same panels which had them in step 1. Again the Normalization step is the culprit, but if I omit normalization in the Mosaic integration the result is not pretty!

These images were all shot over three consecutive clear nights, same time, same image train. Only the moonglow would be different, but with Ha-OIII filter the effect should be minimal. Target was high to the East.  I’m Bortle 4 so no significant LP. The symptoms seem to point to a PNG processing issue. As PNG support is new for this release I thought it might be helpful to diagnose the problem.

Thanks

Peter

Alright, let me hand this over to Mabula as he knows a lot more about that image-loader. My suspicion is that something is going wrong using PNG's, because maybe you now have a low bitdepth or the data is not linear anymore?

Hi Peter @peterd,

Thank you very much for your feedback from your first experience with Astro Pixel Processor and for being so detailed about what you did. That really helps 😉

If you’re wondering how I tested the Mosaic functions, let me explain. I use Sharpcap’s live stacking feature for data capture, saving the individual subs as PNG files together with a 16-bit FITS stacked version. I was able to use all six FITS stacks for the Mosaic integration. Is there some issue with de-bayering of PNG files in APP? I noticed that the Color Space column in the file listing says ‘8b Gray’.

It is very likely that the answer to your problems with PNG processing is mentioned here. APP reports them as being only 8bit... that means that the lowlights in your data have so little information that the normalization process is suffering. Chances are very high that if you use 16bits PNGs all works perfectly well 😉 . Shooting in 8bits is simply a waste of you data... After calibration, the sky background could become 0 for instance and then I think the problem that you experience might be created..

And.. I must point out, that using PNGs instead of FITS is not the best way to go I think. The PNGs have metadata that is simply not suitable for astrophotography processing. It is not impossible, but it can only be managed by creating lots of customized metadata tags (SharpCap would do that) and we do not have any clue about their customized tags... If you use FITS, the well-known fits conventions will make sure that different packages will be able to completely read and understand the metadata and use it for processing...

Regarding debayering with PNGs, perhaps we have not yet implemented the correct PNG tag that denotes the Bayer pattern in the header... again, very likely, SharpCap might use a customized tag here creating issues between software packages.

If you want me to have a look at your data, to be able to fully confirm the problem, that is perfectly fine 😉

You can upload it here

https://upload.astropixelprocessor.com/

username and password: upload

Let me know once uploaded and I will check it 😉

Mabula

@mabula-admin

Thanks Mabula!

I have uploaded two sets of files to PeterD/PeterD_PNG and PeterD_FITS.

The FITS files are three of my Veil Nebula panels integrated from PNG subs using the process described above, bypassing Normalization. If you integrate these using the ‘N’ file as the reference you will find that the NW panel acquires a blue cast during normalization. If you integrate only the N and NE panels there is no problem.

The PNG files are the subs used to create the NW integration. If you repeat the integration process, you will again see that a blue cast is created during normalization. Parameters were RGGB, Ha-OIII color, Force de-bayer – everything else per defaults. No calibration necessary.

I follow your logic with respect to minimal signal levels and would agree that these images are not the greatest Veil Nebula examples - they were made as a test run – my first try at Mosaics! However, I don’t believe you want the Normalization feature to be removing signal, as is apparently the case.

I hope the examples will help you research the behaviour. Oh, and I promise to switch to using FITS files for capture 😊

Peter

Hi Peter @peterd,

Thank you very much for uploading the data and further explanation. I will check the data tomorrow and will investigate why normalization fails (this is very likely a bug from using 8bits data 😉 ) and will fix it so it will work next time.

Most importantly, switch to capture in 16bits 😉 Your camera captures the data in 14bits already. If you save it immediately to 8bits.... well that is just a waste of your nice data 😉 And a technical operation like data calibration will never work nicely... if it works nicely, like with 16bits data, your results will improve greatly !

I will report back when I have checked the data and have found the issue.

Mabula