20090228
A Quick Peek at the RegiStax 5 beta
Well the beta is out on a 30-day trial and I downloaded the beta this afternoon to do a little testing. I first tried it with my current test subject – an AVI from a night of good seeing. I fired up RegiStax v5 and selected 64×64 alignment boxes and then let it pick how many and where to place the boxes. The area of the Moon was near Walter so there were many features to choose from. RegiStax decided to put down 230 alignment points and distributed them pretty uniformly. It also avoided the area beyond the terminator. It took 24 minutes for the initial alignment, 1 minute to make a reference from the 50 best frames, 2 minutes to optimize, and 1 minute to stack the best 200 out of 1300 frames in the AVI. Total run time 30 minutes for 230 alignment points. Not Bad. I had just run the same AVI through AviStack on the same machine the night before with 2500 alignment points. That took 36 minutes. I reran the AVI through AviStack using only 230 alignment points ( I had to manually delete nearly 160 points because I could not get AviStack’s auto placement routine to lay down fewer than 390 points). AviStack ran through that case in 20.5 minutes. So, RegiStax is faster than AviStack except when you force AviStack to use the same number of points. When I looked at the RS version compared to the AviStack result using 2500 alignment points – after wavelet enhancement (using the same tool), I could easily tell where the RS processing could have used more alignment points. The problem boils down to this – when you use 10 times as many alignment points, the distance between points is 3 times smaller. This results in 3 times less distortion (on average) from seeing within any single stacking polygon. If your skies are like mine this will make a noticeable difference in the result. The quality of the final image with RegiStax v5 is still not as uniform as with AviStack. One other thing to know about RegiStax. It aligns and stacks to sub-pixel accuracy and so if your images are not properly sampled you will lose some resolution.
My next test was my old test AVI of the region near Aristarchus. This was an AVI where RegiStax had a tough time tracking some features in the darker areas of the Mare. I could not get v5 to complete the optimize step. The program would simply crash. I did not, however, try some of the new settings – this is after all a Quick Peek of the Beta on the day of release. It also decided that only 32 alignment points were needed. I’m going to have to spend some more time on this test case and learn some of the new controls that are supposed to help in these situations.
Here are a few problems I noticed in the beta which I assume are going to be easy to fix in the final release:
The status bar along the bottom has a place where RS reports Time Used and Time Left. For some reason that line is split in two – one above the other – but the single line height of the status bar cuts the top off of the top line and the bottom off of the bottom line.
I was running RS on Win XP under Parallels in coherence mode on my Mac. The first time I ran RS, it kicked Parallels out of coherence mode into a small window with scroll bars. It had apparently changed the screen resolution from 1920×1200 to 1900×1182!!! After restoring everything back to the way it was, RS did not repeat this the next time I ran it.
Here is one thing that I think is going to remain a problem:
One of the problems the previous versions of RegiStax had was that the reference created after setting the Limit frame count still had slight geometric distortions which only really became apparent when you tried to build a mosaic from multiple AVIs. I compared the RS result to the AviStack result using the difference mode in PhotoShop. AviStack reported that the seeing in this AVI was never greater than 2-pixels of relative shift – so this is a very quiescent sky I was imaging through. The comparison between the two results showed that only one alignment point had a slight relative shift. It was an area of sharp contrast around a 40×40 pixel crater. Not a definitive test, but given the problem I had around Aristarchus I suspect RS is still going to have problems with astrometric accuracy.
So, my quick peek tells me the following. RSv5 is faster than v4. There are more features to learn that should help with problem AVIs. If you are fortunate to live in a place where your sky provides excellent seeing or you are shooting at shorter focal lengths – you are going to like RegiStax v5 and can use most of the automated features. If you are like me with a sky that rarely cooperates – the jury is still out. I will learn the new features and report back here within a week.
DISCLAIMER: I am now contributing some post processing code to the AviStack program. You may feel that this limits my ability to remain objective. Fair enough. Try these tests out for yourself and report your results here. I’d love to hear from you.
JMZ said,
March 1, 2009 @ 0106
I reran my failing test case using the Center of Gravity option and the alignment and stacking process completed successfully. The problem area that RegiStax v4 produce double craters in was not problem for v5. So, the new options work as advertised. 37 Alignment points is still not enough, but I’m going to take a look at that next.
When RS is running, the GUI is essentially unresponsive to user input. It will acknowledge input after a minute or so. As with previous versions, stopping processing and returning to an earlier stage can leave the program in an unpredictable state. Similar memory effects occur when setting up multiple alignment points. Trying out some features appears to be irreversible. It is best to quit the program and restart.
JMZ said,
March 1, 2009 @ 0120
I’m running the Matrix of 20×16 alignment points now using the Center of Gravity option again. It is going slowly so far, ~30 minutes for the initial alignment. I’m getting some tracking errors in the mare areas and an occasional ‘red circle’ near some strong features. …
I finished that test run – it took 50 minutes – not exactly speedy. Despite the uniform alignment point coverage, the uniformity of the final image quality just wasn’t there. I cannot tell if it is an inability to align low contrast features, or if it is a quality assessment problem. Judging from the shape of the edges in the final image, I suspect there are some astrometric errors as well. I’m going to play with this some more because I can’t rule out user error yet, but at this point v5 is nothing to write home about.
A closer comparison between the v5 result and the AviStack comparison from my flickr account shows some problems still remain in the darker areas.
JMZ said,
March 1, 2009 @ 1414
When I encountered the crash on one of my tests, I did not send a bug report. Cor asked that I do so, I’ve been trying to reproduce the error. I have not been able to so far. I have changed a lot of settings and RS seems to remember many if not all of them. I can’t confirm that I’m using the same alignment points or that I’ve enhanced the reference frame in the same manner. I did manage to get the Aristarchus area to process properly using 40 alignment points – several of which were in the problem area. Even though I was not using the Center of Gravity option, RSv5 completed the processing quickly and accurately. No warnings, red circles, or obvious artifacts in the result. It was very fast – maybe 10 minutes. I like the Gradient 2 quality estimator as it does a very good job selecting the best frames. Still, as you move away from the alignment points, the features tend to get soft due to residual alignment errors that arise from seeing-generated geometric distortions in the large alignment regions.
JMZ said,
March 1, 2009 @ 1454
Now I’m playing with the Matrix method for placing alignment points. This is the mode I’m most likely to use RSv5 in as it gives uniform coverage of the image. Using the Aristarchus AVI again, I laid down a 20×16 grid of alignment points. Some of these, 20 or so, were beyond the terminator. So I tab over to see the list of alignment points and select one that I wish to delete. Simply selecting the alignment point in the list causes all the (remaining) alignment points to be redrawn with the selected one in color. That takes about 3 seconds or so. Since I want to delete 5 points in a row, I hit the delete key 5 times. RS redraws the entire grid 6 times – once for the initial selection and then once for each deleted point. While this works, it is much too time consuming. Deleting a dozen or so points took about 2 minutes. Oh, I accidentally deleted a few points (the program somehow buffered a few delete keystrokes) and I could not add any points back manually. So, if you screw up, you have to go back to the very beginning. There should be a simple way to redraw the selected box in yellow. I have not found a way to select multiple alignment points so I can delete a group. I do understand the need to redraw the image and remaining alignment boxes since you do need to replace bits of the image that the box(es) covered. Perhaps a separate layer for the alignment boxes used as an overlay on the image might be a simple, faster solution.
This alignment box redraw silliness is getting on my nerves. Changing the Lum. Threshold value causes a redraw. Hit the up or down arrows associated with that control 6 times and you’ll get 6 redraws.
While I was typing this, that run finished the initial alignment and quality estimation. Setting the Limit and creating a reference produced a reference with a couple of holes in the image – 30 minutes down the drain. I’m rerunning with Center of Gravity on this time… I’m still learning.
The run with the grid and Center of Gravity option just finished. It also had a hole in the middle of the reference image. The hole was in a different place. I increased the allowed number of drift pixels to search within – we’ll see what that does.
If you think I’m being tough here, you’re right. Deep down, I’m a GUI usability guy. If I don’t like to use a program (any program), I probably won’t even if it works well. For example, I use ImagesPlus currently for its RLD capability. I use it because it is the only tool I have that works. I do, however, hate its click-happy GUI and odd way of not quite letting the user know what they are doing (is it a copy, the real thing or just a preview). That is why I plan to write my own routine.
JMZ said,
March 1, 2009 @ 2005
I’ve tried a few things, setting different first alignment points, changing the search radius, normal vs Center of Gravity, and I just can’t produce a reference image for Aristarchus using the matrix of alignment points that does not have at least one black square hole in the middle of it somewhere. Aligning on Mare areas is tough, I know, but there ought to be a more graceful way to deal with this problem. How about deleting the alignment point and restacking? I would be a little happier if the time investment (32 minutes for each attempt) was salvageable.