Play back stacking - problems

[MunichAtNight]

Hello.

I work now for some month with sharpcap 3.2 pro and almost all problems by handling the software I could solve and I get really impressive results and I love the software.
Only when doing a "restacking" of saved single frames I am not able to come to a quite similar result as before in the real live-stacking. I use a Colour ASI294MC camera and I had to learn, that it is necessary to debayer first the by sharpcap before saved single frames in 16 bit .png format. Thanks to the forum here I was directed to PIPP and in all web pages I found the debayer pattern for the ASI294MC is described as RGGB.

Nevertheless after debayering with PIPP RGGB and when using Sharpcaps Folder Monitor Camera I get strange results. The blue colour is very, very much stronger as the other colours R and G. And the histogramm shows not a smooth, round curve for R and G. It is more a very sharp triangle curve. This causes when moving the dark-level a very, very little bit, that the image results gets very hard and galaxies shrink dramatical. In the end a "replay-Stack" gives a complete different result as the Live stack before! Why?


Here a JPG live stack from sharpcap still with satellite trails




Here a JPG "replay"-stack from sharpcap with removed satellite trails


I wasn't sure if I had to use the same dark file when replaying the stack as I had used when doing the real live-stack. I got the feeling when using the same dark file, when replaying the debayered frames the above described problems went even worse.

Here is a screenshot of Sharpcap to show the histogramm and another problem that there is a sort of grid visible, I have never been seen by live stacking with Sharpcap.






When looking with Photoshop in frames which were debayered by PIPP it is easy to see that "blue" is much more stronger as R and G. I am afraid that I did something wrong within PIPP or I missed something to select correctly.







I was wondering if it wouldn't be necessary to control each colour channel (gamma) somehow by a level to advise PIPP what does R, G and B mean in detail how it should define it. But I found only the selection for the different debayer patterns but nothing else in direction of colour control.

Any help and hint is very welcome.

Kind regards - MunichByNight - Ewald

[admin]

Hi,

it certainly seems that the images converted via PIPP may not be correct, which could lead to both the weird colours and potentially the grid effect.

The effects of using the wrong bayer pattern are as follows:

Correct pattern => Image looks OK
Swapped pattern (RGGB instead of GBRG or BGGR instead of GRBG) => red and blue channels swapped
The other two wrong patterns => Grid seen on the debayered image, often with a purplish colour cast.

Anyway, to confirm you could share one of the saved FITS files and one of the images saved from PIPP so we could check - the files will be too large to attach here, but you could upload to dropbox, google drive, etc and share a link.

I'm also surprised that you need to perform the PIPP processing - that should not be necessary. I have just tested and RAW (RGGB) FITS files saved with an ASI174MC camera are loaded by the folder monitor camera with correct colours with no processing needed.

cheers,

Robin

[MunichAtNight]

Hi Robin,

thanks for your help! I thought initially, too that I can use the "raw-stacking-files" as they are. Based on your feedback now, I am afraid I made something wrong in my Sharpcap setup from the beginning. Sorry! Stupid User! I think and hope you agree, it will be better to find out why I can't use the stack files directly for "Play-Back" / "Restacking" instead of trying to find out what is now wrong with my rawfiles, based on a wrong or not perfect setup for this purpose.

The files I found in the directory "rwaframes" created by sharpcap aren't *.fit files, they are 16 Bit .PNG files. Here a link to frame 00100 out of the directory rawframes. This might be the major problem. Do I have to read your above answer like this, when storing the rawframes as fit-files than I can use them directly for "replay" the stack? And has it to be understood, that 16 Bit-PNG files can't do this directly without beeing "PIPP"-ed before, so I have simply to change, that the stored Rawframes are *.FIT file format?

In this case my upto now saved rawframes can't be used. It doesn't hurt me. it is only important to me for future usage to understand and to do it correctly in future.

When finished with stacking I saved the stack with Sharpcap additional, but initiated by hand as a fit file as well. Here the link for it. And here the link to the corresponding text-file.

Thanks for your support - Ewald

[admin]

Hi,

if you have saved your RAW frames in PNG, all is not lost - open those in the folder monitor camera. They will initially appear monochrome with a grid pattern due to the lack of debayering, but you can fix that by setting the 'Debayer Preview' option to 'Force XXXX' (probably RGGB). That should let you replay the stack in full colour without needing to process in PIPP.

Sometimes it can be hard to check the right bayer pattern on faint astro images - if you take a daytime image you can check much more easily.

Hope this helps,

Robin

[MunichAtNight]

Hello Robin!

Success! Thank you very much! Perfect! And yes your are right the Paddern is RGGB.



(Standard stacking without nine (removed) frames which contains satellite trails - Finally = no trails)



(Sigma stacking without nine (removed) frames which contains satellite trails - Finally = no trails)

I tested as well if SIGMA Stacking will remove Elon-Musks trails. But it didn't work perfectly!


(Sigma stacking with all frames, nine of them contains contains satellite trails - Finally = still some trails)

I could identify the nine responsible Raw-frames with satellite trails and removed them simply before stacking so it wasn't a problem.

Interesting is that Sharpcap is mentioning for the duration a very different time. The very first above live image in the starting post was a stack with 4240s ( = 8s x 530 ). I used the raw frames (each 8 s) to restack and did the above images. I thought finally it will gives a corresponding length of time. But the "restacked" images show much different length of time. The image of the first restacked image is a stack with 523 frames and 1317s, the second 495 frames and 1959s and the last restacked trail image is 541 frames with 1793s. Why does Sharpcap when restacking calculate different time?

Thanks again for your support and this wonderful software!

Ewald

[admin]

Hi,

glad to hear that you have it working. I actually struggled to spot satellite trails in the third image, but maybe they are more obvious if you know where they are. If there are trails in the first 10 or so frames that are used to establish the image variability statistics then they will not be removed, beyond that you can try adjusting the sigma threshold - a lower threshold will do a better job of eliminating the trails at the expense of possibly throwing away more data elsewhere (a balance needs to be found).

When loading images from PNG, SharpCap does not know the exposure length that was used to create the PNG, so the frames get processed without exposure info. In that case, live stacking 'guesses' that the exposure for a frame is the time between the previous frame arriving and the current frame arriving, leading to the figures you saw. If you are loading FITS files then the correct exposure should be retrieved from the FITS headers.

cheers,

Robin

[MunichAtNight]

Hi Robin!

but maybe they are more obvious if you know where they are.

You are right! It's always a question what's the purpose, usage and idea behind an image. I use Sharpcap for EAA usage and therefore myidea is not a 1000% perfect Astro-Photography Photo, it is more the joy to watch live the DSO within a short time. Some trails you (and me, too) have to struggle to find, doesn't harm! Right! But it is great knowing to handle such a problem to have with sharpcap a mighty tool which may help!

SharpCap does not know the exposure length that was used to create the PNG, so the frames get processed without exposure info.

Interesting! I understand! Thanks again!

Ewald