Back to forums

Debayering issue in moon video processing?

Cor Berrevoets et al. Registax ZWO ASI678MC Processing Solar System Troubleshooting
18 replies•245 views
Carlo Paschetto avatar
Carlo Paschetto avatar
Hi everyone,

I’m trying to process an AVI video of the lunar surface captured with an ASI678MC at 1080p, with a Bayer pattern that should be RGGB. I’m using the classic PIPP -> Autostakkert -> Registax workflow, which usually works perfectly for me with videos captured using DSLRs. However, with the AVI file produced by the ASI678MC (but the same happens with the ASI533MC PRO) , no matter how I handle the debayering parameters both in PIPP and Autostakkert, for some reason the final TIFF image has always a sort of checkerboard pattern and appears "pixelated", as if the Bayer pattern was incorrectly processed at some point in the workflow.

Among the many attempts, I’ve tried telling PIPP either to ignore the debayering, or to apply it, or to force the RGGB pattern and color image detection, and so on. I’ve done the same in Autostakkert, which in many cases interprets the output SER files generated by PIPP as monochromatic, leading me to manually force the pattern there as well.
Regardless of the parameter combinations I try in these two programs, every time I load the resulting images into Registax, I end up with TIFFs that look like the one I’ve attached here.

From my searches online and going through countless tutorials, I’ve seen that this is a fairly common issue, but each thread seems to have its own recipe, and none of them actually seem to work for me. What am I doing wrong, and what is the correct sequence?

Thank you for your kind support!

Carlo


Well Written Respectful Engaging
Tony Gondola avatar
Tony Gondola avatar
I've not seen this issue with ZWO cameras. What capture software are you using?
Well Written Respectful
Carlo Paschetto avatar
Carlo Paschetto avatar
Tony Gondola:
I've not seen this issue with ZWO cameras. What capture software are you using?

It's the embedded one in the ASIAIR Plus. Then I download the AVI files directly from the ASIAIR.
Tony Gondola avatar
Tony Gondola avatar
I don't now anything about the AIR but try using SharpCap. It's free, just load it up and do a test during the daytime. You'll know right away if it's the camera or the AIR.
Carlo Paschetto avatar
Carlo Paschetto avatar
Tony Gondola:
I don't now anything about the AIR but try using SharpCap. It's free, just load it up and do a test during the daytime. You'll know right away if it's the camera or the AIR.

I don't have a PC and my whole ordinary workflow (and any other task) is based on ASIAIR + MacOS. Generally is working perfectly, don't understand what I'm wrong with ASI video, I guess there is some checkbox or step I'm missing in the procedure when processing AVI files either in PiPP or AS4!
First, every time I load files in PiPP it asks me to choose whether controlling on my own debayering and set the right pattern, or let it to manage automatically. Any of the two method seems working, I guess there is some checkbox or parameter I set wrong in both cases. Depending on the way I process on PiPP, AS4! loads SER files either in gray scale or RGB. Not depending on I set AS4! debayering options or force Bayer pattern, the stacking result is always wrong. 
I read in many places that I should not let PiPP manage Debayering, and this is I actually do when process DSLR MOV files, where everything goes fine with default parameters in the entire process from start to end, without any intervention of mine. Clearly there is something different in the ASI AVI files management.
Carlo Paschetto avatar
Carlo Paschetto avatar
BTW, notice that images management does not have any issues and FIT images are perfectly processed by PixInsight and any other application. This happens only when managing AVI files through PiPP and AS4!
Tony Gondola avatar
Tony Gondola avatar
Could be as simple as that. When does the problem show up, after export from the AIR or after PIPP?
Carlo Paschetto avatar
Carlo Paschetto avatar
Tony Gondola:
Could be as simple as that. When does the problem show up, after export from the AIR or after PIPP?

It's visible only in the stacked TIF image after AS4! processed the SER file. To say it all, I realized it in Registax, as the effect is amplified by wavelets (the attached image is from Registax). In the original TIF got out from AS4! is barely visible and I only noticed it after I saw the result of the Registax deconvolution. Source AVIs appear to be perfectly fine, and cannot check SER files. But as I told, browsing the web I found out that this seems to be a known issue due to a wrong Debayering management in the process, but with different approaches suggested, so that I can't figure out which one is the right one.
Jan Erik Vallestad avatar
Jan Erik Vallestad avatar
I use the same camera with the new Asiair, I have not seen this issue before either. The image you posted looks like it hasn't been debayered at all. However I don't force a bayer pattern in software, but I have noticed that Registax doesn't recognize it as RGGB if I simply stack it directly there without using PIPP. I usually don't use PIPP unless I'm using my SLR in order to convert my files.

What are the settings you use in PIPP, could you post some screenshots?


EDIT: I just re-installed PIPP on my laptop as I didn't want to get on my desktop to process some SLR images tonight. What I found was that I had to adjust quite a few[b] [/b]of the standard settings to get results. I had issues with both this checker pattern as well as colors being off. Most notably I had to activate histogram equalization to get the colors right and (as always) un-check the convert color to monochrome option. The debayer options seemed ok though.
Helpful Engaging Supportive
Carlo Paschetto avatar
Carlo Paschetto avatar
I use the same camera with the new Asiair, I have not seen this issue before either. The image you posted looks like it hasn't been debayered at all. However I don't force a bayer pattern in software, but I have noticed that Registax doesn't recognize it as RGGB if I simply stack it directly there without using PIPP. I usually don't use PIPP unless I'm using my SLR in order to convert my files.

What are the settings you use in PIPP, could you post some screenshots?

True, looks like it hasn't been debayered.

I have tried many combinations of the parameters in the attached PiPP windows. I have read that the default should be to answer "no" to the initial question about enabling debayering (which is interpreted incorrectly by PiPP, because the correct one would be RGGB), no matter the input file, as debayering should be left at AS4! stage.

If I answer "no" to the initial PiPP question, the output SER files look like are always interpreted by AS4! in grayscale, and if I force an RGGB interpretation in AS4! the stacking result is an RGB image with perfectly equal histograms, therefore still in grayscale.

If I answer "yes" to the initial PiPP question, I can set the debayering parameters there and force RGGB, then the output SER files will be seen in color by AS4!, but the stacking result is a TIF image like the one I attached, incorrect, which seems not debayered.

In Registax I usually do nothing, I just apply wavelets for deconvolution.
Jan Erik Vallestad avatar
Jan Erik Vallestad avatar
Carlo Paschetto:
True, looks like it hasn't been debayered.

I have tried many combinations of the parameters in the attached PiPP windows. I have read that the default should be to answer "no" to the initial question about enabling debayering (which is interpreted incorrectly by PiPP, because the correct one would be RGGB), no matter the input file, as debayering should be left at AS4! stage.

If I answer "no" to the initial PiPP question, the output SER files look like are always interpreted by AS4! in grayscale, and if I force an RGGB interpretation in AS4! the stacking result is an RGB image with perfectly equal histograms, therefore still in grayscale.

If I answer "yes" to the initial PiPP question, I can set the debayering parameters there and force RGGB, then the output SER files will be seen in color by AS4!, but the stacking result is a TIF image like the one I attached, incorrect, which seems not debayered.

In Registax I usually do nothing, I just apply wavelets for deconvolution.


Another thing I've never done is export as .SER from PIPP. Since I don't see any reason to use PIPP at all I would encourage you to test a direct stack in Autostakkert. In my experience forcing a bayer pattern always yield colors that are way off so I've just accepted whatever the software interprets. 

Btw: Are you sure that it isn't a result of Autostakkert trying to debayer already debayered data from PIPP?

Edit: Removed some inaccuracies. If you want to let AS! debayer your images make sure you un-check all the debayer options and check the "Protect Bayer Pattern" box.
Tony Gondola avatar
Tony Gondola avatar
If you can access the original .ser file it can be processed directly in AstroSurface but, that might again be a Widows only solution, I haven't checked. Registax is getting a bit long in the tooth, last update was 2011. I do remember it being fussy about file formats.
Carlo Paschetto avatar
Carlo Paschetto avatar
Jan Erik Vallestad:
Edit: Removed some inaccuracies. If you want to let AS! debayer your images make sure you un-check all the debayer options and check the "Protect Bayer Pattern" box.

See attached screenshot. This is the situation if I don't let PiPP to manage the debayering, and un-check everything apart from Protect Bayer Pattern. What's happen is that if I let AS4! to autodetect the pattern, it gets gray scale. If I force RGGB , get a TIF image whose histogram are perfectly equal, that's grayscale again.
Jan Erik Vallestad avatar
Jan Erik Vallestad avatar
Have you made sure to de-click this option?


Just curious, why do you need to run PIPP before Autostakkert?
Carlo Paschetto avatar
Carlo Paschetto avatar
Have you made sure to de-click this option?


Just curious, why do you need to run PIPP before Autostakkert?

Yes, de-clicked.
I use PiPP mainly for letting it to reduce the number of frames by ordering them per quality and converting the AVI in SER for an easier processing in AS4! as PiPP is generally very effective and fast in this task, at least with my huge MOV files from the DSLR.
I just noticed that the issue in my workflow seems to be exactly in the way PiPP process the AVI. If I skip the PiPP stage and go directly in processing the original AVI in AS4!, then in Registax there is no problem at all and the TIF stacked image is perfectly aligned.
So now I'm curious to understand what the hell should be the right parameters combination in PiPP for it not doing mess when converting in SER....
Engaging
Jan Erik Vallestad avatar
Jan Erik Vallestad avatar
Carlo Paschetto:
Yes, de-clicked.
I use PiPP mainly for letting it to reduce the number of frames by ordering them per quality and converting the AVI in SER for an easier processing in AS4! as PiPP is generally very effective and fast in this task, at least with my huge MOV files from the DSLR.
I just noticed that the issue in my workflow seems to be exactly in the way PiPP process the AVI. If I skip the PiPP stage and go directly in processing the original AVI in AS4!, then in Registax there is no problem at all and the TIF stacked image is perfectly aligned.
So now I'm curious to understand what the hell should be the right parameters combination in PiPP for it not doing mess when converting in SER....


Alright, I'm not sure then. I find AS! to be better at quality estimation anyway so I really don't see why PIPP is relevant anymore tbh. After AS! has done the quality estimation it only processes the set percentage of frames anyway. It probably depends on computing power, but AS! isn't any slower than PIPP for me at least, unless you have stellar seeing and want to drizzle. As long as AS! handles AVI just fine I don't see a reason to convert to SER format. I'm pretty sure that any advantages of SER require the native format to be SER not AVI, which is impossible with the Asiair. But to each their own! 

As for SLR's I avoid shooting video and stick with single exposures due to compression. Mainly because my camera don't support uncompressed video format - unless I ship it to Nikon and pay for an upgrade. I rarely use it for this purpose though. If your camera can do uncompressed format it's fine, but yeah you need to convert it using PIPP or some other software. Again AVI would serve well.
Carlo Paschetto avatar
Carlo Paschetto avatar
Carlo Paschetto:
Yes, de-clicked.
I use PiPP mainly for letting it to reduce the number of frames by ordering them per quality and converting the AVI in SER for an easier processing in AS4! as PiPP is generally very effective and fast in this task, at least with my huge MOV files from the DSLR.
I just noticed that the issue in my workflow seems to be exactly in the way PiPP process the AVI. If I skip the PiPP stage and go directly in processing the original AVI in AS4!, then in Registax there is no problem at all and the TIF stacked image is perfectly aligned.
So now I'm curious to understand what the hell should be the right parameters combination in PiPP for it not doing mess when converting in SER....


Alright, I'm not sure then. I find AS! to be better at quality estimation anyway so I really don't see why PIPP is relevant anymore tbh. After AS! has done the quality estimation it only processes the set percentage of frames anyway. It probably depends on computing power, but AS! isn't any slower than PIPP for me at least, unless you have stellar seeing and want to drizzle. As long as AS! handles AVI just fine I don't see a reason to convert to SER format. I'm pretty sure that any advantages of SER require the native format to be SER not AVI, which is impossible with the Asiair. But to each their own! 

As for SLR's I avoid shooting video and stick with single exposures due to compression. Mainly because my camera don't support uncompressed video format - unless I ship it to Nikon and pay for an upgrade. I rarely use it for this purpose though. If your camera can do uncompressed format it's fine, but yeah you need to convert it using PIPP or some other software. Again AVI would serve well.

In fact, I don’t often use video capture. Until not long ago, I used to photograph the Moon with single shots using my Canon 90D. However, with the purchase of a new telescope and a decent Barlow lens, considering the much greater magnification factor, I’ve switched to recording videos and processing them using this workflow that I’ve often seen recommended online.

Filming in 4K with the Canon, despite the obviously large size of the original files, the workflow seems to work very well (or maybe I just never noticed similar issues? Who knows…). However, while working with ZWO cameras, I only realized after some time that the final images were actually grayscale, not color. I had been misled by the apparent coloring of the Moon itself and hadn’t bothered with the usual mineral processing.

These past few days, I finally realized that the TIFs produced by AS4! using SER files coming from PiPP, converted from the original AVIs, were grayscale, so I went back through the entire process to figure out how to retain the original colors.
That’s when I ran into issues with debayering, and from there, all the final images turned out messed up…

Anyway, at this point, I’ll follow the advice and remove PiPP from the workflow, leaving all the processing to AS4!, as it indeed seems to handle it well.

And of course, thank you for the support!
Respectful Supportive
Jan Erik Vallestad avatar
Jan Erik Vallestad avatar
Glad you got it sorted! I've only used video mode with my Z7 a couple of times but the compressed video format left me very disappointed. Sadly no way to counter in the un-modified settings that I know of, I can convert it to AVI, but it would still come from a compressed source so I don't really bother.

Another thing to be wary of that just came to mind, which I haven't noticed before the latest ZWO updates, is that "mono bin" is actually ticked off in the Asiair. I use the 256G and the  678MC and had a couple of failed attempts on Jupiter due to that fact. I can't remember exactly where in the menu it is, but it's something to check out. If your video file had colors after doing the AS! stacking then it's fine, but for anyone else reading this it might be helpful.
Helpful Supportive
Carlo Paschetto avatar
Carlo Paschetto avatar
Jan Erik Vallestad:
Another thing to be wary of that just came to mind, which I haven't noticed before the latest ZWO updates, is that "mono bin" is actually ticked off in the Asiair. I use the 256G and the  678MC and had a couple of failed attempts on Jupiter due to that fact. I can't remember exactly where in the menu it is, but it's something to check out. If your video file had colors after doing the AS! stacking then it's fine, but for anyone else reading this it might be helpful.


Thank you for this tip too.
I haven’t yet checked if the color curves are truly correct and independent, because AS4! is still batch processing the queue of videos I recorded for my lunar mosaic, but I’ve checked that AS4! now automatically recognizes the correct Bayer pattern and processes the AVIs correctly.
I also did a quick test in Registax with the first TIF produced by AS4!, and I saw that the issue has finally disappeared.Once the processing is complete, I’ll verify in Photoshop whether the RGB curves are indeed independent. If they aren’t, then it likely means I need to double-check that parameter on the ASIAIR. provided I find where it is , so thanks again!