Posted 08 February 2012 - 08:34 AM
Contrary to one of your comments above, I haven't had any problems using Ninox with the larger targets in recent time, such as Saturn at present and Jupiter a month or so ago.....it's little Mars that is troubling Ninox...and the seeing between Mars and Saturn shoots has been pretty much the same so that doesn't seem to be a differentiating factor for those 2 at least...
But I'm about to give AS a go in a few minutes, and the points you've already made plus those in your last post about SAP & MAP, and particularly AP's in general are good to know beforehand - will report back when I think I have something to comment further about..!
Posted 08 February 2012 - 09:20 AM
I have found that for larger targets a gradient quality estimator works well (and Ninox uses a gradient quality estimator, althought it's not quite the same as is used in AS!2). For smaller and brighter targets a gradient quality estimator might not work that well, image distortions can sometimes be seen as 'extra detail', I have seen this happen in particular on Venus and Mars recordings. But that is where the Edge quality estimator could be used, for bright targets edge sharpness is much more robust to those seeing distortions as it only looks at the sharpest transitions from each direction, and you can't get much sharper transitions than going form the dark background to a well-defined planet.
Posted 08 February 2012 - 06:41 PM
But don't forget that Ninox does offer several other command line switches/function variations such as altering the number of downsampled images it takes it's particular form of Gradient2 quality estimation from and "-dbf=planet" which is for discarding badly-formed frames (both of which have no impact with the particular problem I've encountered of late alas! )
Also there's the morphing switches/commands.....hmmm, maybe they are actually "anti-morphing" controls and these are my next stage of inclusion in the Ninox-regulated processing comparisons which should be stacked up against AutoStakkert!'s performance in various modes - time to get to work but I have to confess that pre-processing as well as processing with my current regimens makes for a super-workload (why I haven't tried the morph switches in Ninox to date - Registaxing for the morphing sample, then Ninoxing, then final Registaxing!) so I hope I find some genuine satisfaction/advantages in your program Emil: a pity wavelet sharpening isn't part of your software, but if it really does run very fast then that's a real bonus.....as you commented earlier, one can go on a merry-go-round with all this trialling and analysing - but then again you programmers most probably think that's a wondrous pastime..!
Posted 09 February 2012 - 11:33 AM
I'm getting a much better handle on the personality of the program. One part that continues to frustrate me is the lack of file management. I would love to give the final stacked image my own naming convention and place them where they work best for me. Not a complaint, but a suggestion. Otherwise...onward and upward.
Posted 09 February 2012 - 11:41 AM
Posted 09 February 2012 - 12:31 PM
Posted 09 February 2012 - 01:04 PM
Posted 09 February 2012 - 01:26 PM
Of course, that works both ways...I'd figure on seeing an article about the software in S&T after the final release comes out... (hint).
Posted 09 February 2012 - 08:40 PM
Whether or not I do something with those suggestions depends on 1) my mood, 2) if I'm convinced it makes sense, 3) how time consuming it will be to implement.
-- 220.127.116.11 is online. List of changes: ---
- Changed name of Coarse Alignment to Image Stabilization, which makes a bit more sense.
- Added option to manually set coarse alignment window location in surface mode. You should set it around a feature that stays in the FOV at all times. The default location works 95% of the time, but sometimes AS!2 surface alignment loses track because there is nothing interesting to see in the center of the screen.
- AS!2 is now aware of OS limitations on amount of memory available per process. There should be no more lockups caused by out of memory on 32-bit OS.
- Fixed caption of frame number at bottom left, it didn’t update properly in batch processing.
- Fixed caption of frame view in batch processing.
- Fixed unable to press Cancel button in batch processing.
- Added some extra lines at the back of the quality graph at 0, 25, 75 and 100% to increase readability of this graph.
- Tiffs are now saved uncompressed (instead of LZW). Should increase compatibility with processing software.
- Added support for 8-bit single channel bmp files.
- Fixed surface alignment bug causing a more or less random lock up during buffering or image alignment.
- Should be more stable now, especially for surface recordings containing poor frames.
- Automatically turn off bad frames with horizontal or vertical shifting artifacts.
- Speed increase for surface alignment (approximately 30-50% faster).
- Introduced two Surface options: ‘Expand’ will try to make the very biggest image stack possible, the edges will contain less frames (this was the default option). ’100%’ will crop the image such that each pixel will contain the same amount of data (the edges should be fine).
- Batch processing for surface recordings. When more than one surface recording was opened, when processing, for each frame all APs are replaced by a set of automatically placed APs (in a grid, just like when you press the grid button).
Posted 09 February 2012 - 09:09 PM
Posted 09 February 2012 - 09:52 PM
I had dynamic background checked, noise robust 3 and hand selected 13 APs with the 50 box. I'm not sure (and this may be mentioned elsewhere) what dynamic background does and if it is necessary or not.
I had normalized stack 75% checked and not sure what that (or sharpened images box) does. What's your take on that.
Anyway, pretty exciting advance!
Posted 09 February 2012 - 10:01 PM
Posted 09 February 2012 - 10:55 PM
I have this on Jupiter, 15 alignment point set inside the planet, not the edges..
What are the best settings to avoid stacking lines on Jupiter? I only put the alignment boxes on the NEB and SEB no edges.
Somebody else have this with Jupiter ?
Posted 10 February 2012 - 03:53 PM
For planets you should pretty much always keep the dynamic background setting checked. It is used to automaticaly determine the brightness of the black space, which is a critical step for keeping the planet steady in AS!2 (so the image stabilization is not thrown off by a noisy background with perhaps even a changing brightness when you are processing daytime recordings).
The normalize stack option uses an automaticaly calculated guess of the background, and stretches the image stack in such a way that the maximum brightness is always at 75%. I found this to be very helpful when you are imaging under varying transparancy or during dusk or dawn to keep all the R, G and B channels with a similar brightness both at the dark and bright extremes. I also often play around with different capturing settings, and when I use the normalize stack option each stack comes out with a similar brightness. This makes it much easier to make animations.
Freddy, can you show me an example? AS!2 is virtually seem free if you cover the entire planet with APs (place your APs on Jupiter like in the second post of this thread)
Posted 10 February 2012 - 07:21 PM
I agree that the improvement mostly comes from a better placement of APs. Part of learning the program. Sure is fun to work with good data.
Posted 10 February 2012 - 07:26 PM
Posted 10 February 2012 - 08:13 PM
I've been handicapped by pc glitches (which now seem sorted) and actually had to retrieve avi's from my laptop using Pandora Recovery for the trials.....
But I have to say that once I got a very basic hang of the operations (and for this I had to resort to looking at your videos for the much earlier version of AS! Emil) I am pretty darn impressed..!
Lawd knows what I first did (took about 3/4 hour for AS! to process..! ) but after that I was quite astounded.....loading avi's into it and it whirring through in a minute or two (although I do use an 8-thread machine )
I'm quite impressed with what seems like a substantial jump in image quality output - and I'm still right at the elementary stage of getting to know the software.....I just placed 4 overlapping MAP boxes (size=80) centred around the limb peripheries and a smaller (40) one encompasssing the NPC but I'll retry the "Edge" method also and play with the boxes a bit more and see what transpires.....
A couple of things to comment upon - being a lazy son-of-a-gun who uses his handpiece to correct whilst capturing (I'm a travellin' imager most of the time ) I'm finding that there is that slight difficulty with RGB alignment that I'd also get if I didn't Ninox (crop & centre) in my prior processing regimens.....would Castrator used before AS! assist therein as Ninox used to....?
Also doubly-impressed 'cos even though I only used 5 alignment boxes and the Mars avi I used isn't fantastic.....with R6 I couldn't use MAPs without ending up with seams - and had to resort to CofG alignment with selfsame Ninox'd avi's..!
I took to assigning a folder/directory to each avi prior to AS! so that it deposited the stacks (with prefixes) where I knew/wanted them, so that wasn't any real problem.
Pretty sure I'm going to be a convert after only very brief elementary play-around.....lawdy, all that preparatory work with Vdub and Ninox and then Reggie chugging away.....I'd almost be prepared to kiss you Emil - if your chickens wouldn't get jealous..! :rofl5:
Posted 11 February 2012 - 03:27 AM
Tied again with the same alignment settings as in your example and after sharpening in Registax 6 I had this result.
Nobody else has this ?
Posted 11 February 2012 - 08:23 AM
Not really, AS!2 uses the same centering method as Castrator does, and applying it once or ten times shouldn't make a difference. A COG measurement of the blue channel is often shifted towards the polar cap a bit (because compared to the rest of the planet, the polar cap is much more bright in blue than in red light). I think this, and other such differences in brightness regions, might cause a slight mis-alignment between the channels.
Freddy, those are seems alright. If you open that recording in AS!2, which Image Stabilization settings do you use (dynamic background?), and if you browse through the recording (using the slider at the top of the image window), does the planet stay perfectly centered throughout all frames?
How big are the APs that you use, and how are they placed?
Could you provide a screenshot of both of the AS!2 windows?
Posted 11 February 2012 - 02:09 PM
Just for now, those where ninoxed frames, BMP's.
I did not have a good Avi' so I did not load the Avi, but the ninoxed frames like around 7000 into AS2.
I will get that screenshot.
Posted 11 February 2012 - 04:21 PM
This is a recent processed Jupiter Avi,
No ninox, just straight the Avi into AS.
Posted 11 February 2012 - 04:22 PM
Let me know what I'm doing wrong..
I love the program it looks better then R6.. but only have those **** seems,
Also Processing my Mars images from this morning and have the same seems. Use different computers..
Posted 11 February 2012 - 04:50 PM
Posted 11 February 2012 - 05:04 PM
Just want to add that I do not have any problems with my moon images processed in Surface mode.
Posted 11 February 2012 - 06:01 PM
You should do all these things Freddy, and the image should improve.
- Use the width and height sliders to crop the data to make sure you don't run into memory problems. AS!2 loves to buffer, but I see your pc does not have a lot of RAM available (450mb free is not a lot these days) so buffering to increase processing speed is out of the question. Set a width of around 320 and a height of 300.
- an AP size of 50 is WAY too low for this data, AS!2 simply won't be able to align the data in those tiny windows. Try again with an AP size of 120, and place overlapping APs ALL OVER THE PLANET (there shouldn't be any gaps there like you have in the center of the planet. Where there is overlap, there is backup for a potential troublesome AP - AS!2 will sort that out automaticaly)
- increase the gradient estimator to 4
- Don't use drizzle. Only experiment with drizzle when you know the data is undersampled and of high quality, otherwise just stay away from this setting for now.
Please report back with the results.
Edit: just to repeat one question to make sure the image stabilization works: "if you browse through the recording (using the slider at the top of the image window, just drag it along with the mouse), does the planet stay perfectly centered throughout all frames?"