Which software to align CH4 videos of Jupiter?

Google+ Pinterest LinkedIn Tumblr +

I briefly go back to Jupiter CH4 images. On my tutorial I said that the best processing method was the stacked image of WinJupos video de-rotation instead of the “corrected video”. I made again some tests with my last CH4 image and this is confirmed!

When making video de-rotation with WinJupos, you are able to choose between having a fully stacked imaged (to be processed later in any classical software) and a getting only a corrected video, that requires tracking and sorting under Registax or Autostakkert. The first choice does not seem attractive since you can’t select the best frames – WJ stacks all the frames even the worst ones. And why should it be more efficient in aligning frames than the usual softwares ?

This is of course logical but there is one exception – CH4 images. For any reason, the “stacked image” option delivers noticeably better results – but sometimes really better! I have compared the results obtained with the stacked image and those obtained with a corrected video processed with Registax 5, Registax 6, and Autostakkert.

Results

First here are the best results (the image has been taken on October 13th, 2013 – click to see full size):

jupCH4succeed

The chain of alternatively dark and bright spots in mid-SEB (this is an eruption) is a good zone of comparison. The “stacked image” WinJupos result is clearly the best one. Registax 5 is not far behind (processing done with a reference image) but the image is already less sharp. Autostakkert is used with an alignment point (AP) of 25 but its result is slightly less good than Registax 5 – however the SEB spots are still resolved. Now here are the unsatisfactory results:

jupCH4failed

AS2! has again lost sharpness with an larger AP size (75) and the spots are becoming undistinct. But the worst is given by Registax 6, whose image shows a completely melted dark streak.

In conclusion

There is a difference between the “pure” WinJupos image and all the others: the presence of a limb artefact on the following limb (at right here). This artefact found on a 20 mn de-rotated video is already visible on the (corrected) raw frames. The softwares look to have been fooled by it and they are not in consequence able to correctly align frames on such special images (the true limb is invisible due to the strong limb absorption)…

Of course the case is very particular and this is not a negative judgment of the other softwares that will work finely with any other filter ;). But in CH4, the “stacked image” option of the video de-rotation has a clear edge on any other method.

Share.

Leave A Reply