reasonable results of my Plato and Pitatus captures from April 23rd are still pending. I tried Registax 5.1 with the Plato AVI yesterday without success. A first run with a single alignment point to check out the AVI’s potential lead to a good but not spectacular result near the alignment point, a sharp crater rim and craterlets close to the AP well defined. Multipoint processing was not that good. The automatic MAP selection resulted in a horrible image with alignment areas washed out and harsh seams between the areas, carefully choosing 12 points manually wasn’t much better
Ok, I switched back to AVIStack. The first AS processing I tried was fine outside the crater where the harsh terrain has good contrast for the AP tracking. Only the crater floor was completely washed out. I parametrized AS as suggested by Michael Theusner himself and others with increased correlation area radius and higher smoothing factor settings. The estimated  processing time of 8 hours compared to a fraction of that before required running the job overnight. Unfortunately Windows 7 decided to reboot after updates during the night although it shouldn’t, needless to say all processings are lost Jeez, who’s programming this stuff…
I’ll retry today, if AS still has issues on the contrastless crater floor I might switch back to manual MAP processing with several single point runs and insert the crater floor into the otherwise fine AS result. It looks like these captures with high frequency seeing oscillations and prominent noise are a very hard nut to crack. A bit surprising to me since I always have been amazed how good AS is tracking alignment points on almost no contrast in the footage.

Cheers, Oliver

Emil Kraaikamp release the first public version of his stacking tool AutoStakkert yesterday. I tried the tool with my Mars captures from April 10th. The results are a tad better than those obtained before, the contrast in the red and green channel images is noticeably higher. Quite impressing since I used the tool for the very first time. The GUI is clean and pretty self explaining and I like the functionalities: All you need to stack planetary images (without multipoint alignment) is there, the user is not bothered with things not useful.
Here the result:

Excellent tool,thanks Emil!

Cheers, Oliver

Click for full size

Cheers, Oliver

Click to enlarge

Cheers,
Oliver

1. GDK/GTK+ is not thread aware under Win32
2. Polling a file descriptor under Win32 does not work using VC++2008 since GLib is compiled against msvcrt.dll and it’s almost impossible to convince VC++2008 to do so
3. GTK+ 2.18.5/Cairo has a bug on Win32 giving an incorrect Windows GDI device context for a drawing area

To continue with the project I gave up inter-thread messaging  and sacrificed the separate grabber-thread. Polling frames from the camera is now done in the idle callback of the main loop and only saving data is done in a separate thread. This should still be a sufficient task splitting on a two core processor to achieve seamless captures at high framerates.
Reverting back to GTK+ 2.16.6 fixed the window DC bug. OK, time to move on with the actual tool development, I still don’t regret not using MFC
Overall CPU utilisation looks good running the tool at 60fps, performance should be ok. I changed the provisional GUI to a one window look:

Cheers, Oliver

some drawbacks regarding Captifier: After a lot of debugging, testing and trying workarounds I finally read that GDK (and thus GTK+)  is not thread-aware under Win32 as it is under Linux. Great, I found that out, too – the hard way
I’m currently evaluating two alternative strategies to overcome the issue: Interthread-messaging to announce frames to display or integrating the grabber thread in the main thread… The decision will depend on the camera interfaces that are planned to be integrated sooner or later…

Best, Oliver

I’ve been able to fix some issues with the preview display last night, windows GDI functions are now blitting correctly into the GTK drawing area. I’ve enabled the CMU camera control window, writing to disk is working. The capture window GUI has been quickly redone to test some things, still not even preliminary and ugly.
I hope to have a roughly working version soon to use it at the scope with the Dragonfly2 or Scorpion. At least Yoda and the force are with me…

Clear skies,
Oliver

over the years I used several programs to capture my planetary, lunar and solar images at the telescope. None of them met my wishes & requirements completely. With the arrival of two new Point Grey Research cameras without software I decided to develop my own capture tool: Captifier.
Some current specs:

• IEEE1393 aka firewire support via CMU1394 library, software architecture is implemented open to other camera-interface for future support of e.g. USB cameras
• Windows based, should support XP/Vista/7
• Multithreaded buffering approach for seamless captures without dropped frames even on machines with low processing power, in the end the harddrive and bus speeds are the limits
• 16 Bit in-/output support
• Hardware ROI/Format 7 support and software cropping
• GTK+/Glade GUI (I hate MFC programming…)
• Freeware but not open source (for now…)
• Functionalities helpfull for planetary imaging according to my wish list

Basic core functionality is working quite well, a version capable of first field testing should be available soon. I will post updates here and on the subsite http://captifier.astro-imaging.de/

Clear skies!

Oliver