From: Milton Aupperle <milton@outcastsoft.com>
Date: September 28, 2009 1:28:36 PM MDT
To: Astro_IIDC@yahoogroups.com
Subject: Re: [Astro_IIDC] Astro IIDC, Registax, Ninox, LR Decon, a Jupiter image, and more...
Hi doodleBun;
On 28-Sep-09, at 10:28 AM, doodlebun wrote:
First, Milton, thanks for the info on converting uncompressed .mov to uncompressed .avi's. I will try that to see if it makes a difference.
Since it was originally exported at maximum quality, it likely won't make any difference - except that there likely will be more noise for Registax to deal with when you export as uncompressed "None" AVI and the file size will grow tremendously.
Personally I really don't think that if you know how to use Astro IIDC properly you do not need to drive yourself nuts with pre-massaging your files with Ninox, a command line interface, or even fooling with Registax...
Everyone claims to have a better mousetrap at doing this and that when it comes to stacking. The bottom line is does it work for you and achieve what you want in the least amount of time and the easiest fashion? If it doesn't achieve those goals, then it's not much use is it?
A command line utility for image processing with no feedback doesn't sound like the sort of tool people want to use (that's more ore less what Astro IIDC 1.x did). I certainly wouldn't want to use it unless I felt like tweaking the source code to handle each set of movies differently. From what Trevor indicated, he uses it for cropping and centering the sequence of images - but that isn't stacking, that's just preprocessing. Actually I don't see why Trevor would not use the hardware ROI in Flea camera to crop the video to the correct size when recording (TIS cameras don't support this). That saves a tonne of space and is what I do with my Grasshopper (full frame is 1384x1036 - cropped via ROI to say 512x384) when imaging planets which gives me a higher frame rate and faster post processing time. Perhaps he has poor tracking on his scope?
The concept is that instead of choosing the best looking frame as a reference frame, you should create a reference frame for more precise registration of images in the stacking process.
I don't really buy this "create an average reference frame" stuff. When you start doing intra frame pixel comparisons, you start rejecting frames due to image noise not because of image features as the average frame won't have the pixel noise and individual frames will. And you either have to reduce the image noise by blurring each frame or you increase your tolerance when comparing to the "average reference frame". If you increase the tolerance, then you wind up with more frames included that likely should not be included.
Incidentally, I unchecked the box in ASTRO IIDC that blurs the frames with a warning that "some fine details may be lost". Instead I allow a small amount of noise in the image all the way to photoshop. Once in photoshop I put a Gaussian blur of about 0.25 pixels on the final R, G or B images. This has worked better than using the noise reduction schemes inside Astro IIDC.
Which noise reduction schemes in Astro IIDC? During stacking, during image processing when exactly
And as I've said MANY MANY MANY MANY times on this list DO NOT USE "Reduce Image Noise when sharpening" EXCEPT if you are sharpening by LARGE AMOUNTS (medium or higher) OR you intentionally want to soften the resulting stacked image. I would love to turn it off permanently in code so that you can't use it EXCEPT with medium or higher sharpening, however I use it a lot when doing LRGB DSO stacks. In this case, I use "very Light sharpening" with "Reduce Image Noise when sharpening" to purposely blur the R G B channels which improves the star colors a lot when I do the L RGB combine them.
And as it says in the manual DO NOT USE more than "Light" sharpening for Lunar images or you'll get artifacts on edges of high contrast features.
Also I have now got religion. Even with a 14 inch scope, I have noticed that it really isn't a good idea to go with 60 fps on Jupiter.
Did you ever experiment with 2x2 binning so that you can reduce the use of gains, as I suggested? That will let you run at higher frame rates with much lower gains.
And the reason is that at that speed the brightness control has to be set at about 750-800 which is just too noisy. And even then image is rather dark, especially the blue one. So it seems 30 fps is the sweet spot with a C14 @ f/25 with a brightness control being set to around 450-500.
That also depends on the CCD in the Camera. My EXHad camera is 2x as sensitive as what your using now and likely 3x once one accounts for differences in pixel size (6.7 versus 5.5 microns).
Finally I should mention that Trevor uses a DragonFly2. The camera is less noisy than the DMK but are the images noticeably better? I think the jury is still out on that one as I have read alot of chatter but I have seen no direct comparisons. Of course, if Milton said: "Dave, get that camera because you will get the low noise 60fps you so badly desire", it would be different. But I don't think he will say that.
The DragonFly 2 cameras have several different CCD's available, so the camera name doesn't tell the whole story about what CCD it uses. A TIS Dxx 21xxx series camera always has a 1/4" CCD 640 x 480 5.6 micron CCD, whether it's Color, Bayer or Mono.
The noise levels depend on gain settings and to some degree temperature (hot cameras == noisy cameras and with high gains == very noisy cameras). As I've said in the past pixel size dictates how much light each pixel collects. With bigger pixels, he can use less gains and therefore will have less noisy images.
There is a caveat to this that I explained in this message #623
http://tech.groups.yahoo.com/group/Astro_IIDC/message/623
TTYL..
Milton Aupperle..