My currrent (relatively inexpensive!) CCD, an Orion StarShoot G3 Mono, has 752 x 582 pixels, with a pixel size of 8.5 microns. When fitted to a short-focal-length ED80T with a FR (FL = 384 mm), the image scale works out to be 4.65 arcseconds per pixel. Quite undersampled!
The obvious solution is to use the Hubble method - Drizzle. Nebulosity 3 software provides a good algorithm for this. So, taking 25 x 5 min subs (dithered), I had a play around with various settings to see what suited my gear best.
Attached are snapshots of a zoomed in part of an image, ordered as follows:
1. Single frame
2. Traditional align + combine stacking
3. Drizzle with pixel reduction = 0.6, image scale = 1.5 (Nebulosity default)
4. Drizzle, PR = 0.5, IS = 2
5. Drizzle, PR = 0.4, IS = 2.5
All have been pre-processed (bias, darks, flats) so they are clean.
In theory, provided I have enough subs, the PR = 0.4 and IS = 2.5 should be about optimal -- but a coarser Drizzle would be required if I had fewer subs, to avoid leaving holes in the image.
For reference, PR = 0.4 and IS = 2.5 gives me an effective resolution for the camera of 1880 x 1455, and a simulated pixel size of 1.85 arcseconds/pixel.
By the way, here is the mono image of M20 that resulted from the Drizzle PR = 0.4, IS = 2.5. This is obviously a work in progress and not meant to be indicative of the final image (no RGB has been collected yet, and I want more Luminance integration) but you can see that it looks considerably better than a typical 752 x 582 pixel camera, when done this way!
I assume that would be the equivalent of PR = 0.5 (x2) and 0.33 (x3). Unfortunately DSS typically throws memory errors when Drizzling, unless you use a tight subframe. Remember too, you only get an advantage of this if your image train is under sampling (above seeing threshold).
Do you have software to measure FWHM? Be interesting to see if you got a resolution gain, since Drizzle is part of super-res family.
Nebulosity does drizzle really well. FWIW, I have had some trouble getting equivalent results from Pixinsight, but suspect it may require a different approach to the standard registration method.
A critical part of the process is adequate dither to obtain subpixel offsets - what dither scale do you use?
Ray, I was using a "High" dither in PHD2 for the above test, which I think is 4 pixels or about 18 arcseconds.
Not sure how to compare the FWHM or HFR across images, because the image scale changes (increases) as one drizzles more. Thus the reported HFR increases from examples 1-5 above. I guess you'd have to rescale it all back to the same resolution to do a fair comparison?
On my setup, I dither 4 pixels per frame. This equates to about 14 arcseconds.
H
thanks for the info H. is that plus and minus or the total? I guess it doesn't really matter - should be plenty anyway.
Quote:
Originally Posted by Amaranthus
Ray, I was using a "High" dither in PHD2 for the above test, which I think is 4 pixels or about 18 arcseconds.
Not sure how to compare the FWHM or HFR across images, because the image scale changes (increases) as one drizzles more. Thus the reported HFR increases from examples 1-5 above. I guess you'd have to rescale it all back to the same resolution to do a fair comparison?
I guess the most reliable way would be just to scale it all back to arcseconds - then it could be compared with what others get as well.
Thinking about it a bit more though, the dither has to introduce frame to frame offsets that are not just whole numbers of pixels (must include a fraction). That will happen using standard dither if the pixel scale on the guide camera is different from that of the imager. But there might be a relationship that determines how much dither you need for a given ratio of scales. For example if upscaling by 2x, you need data at half pixel offsets to fill in the holes. I think that random offset may do a fair job, but is possibly less efficient than fixed dither - needs more thought. Any ideas?
Also need to ensure that the registration process does not allow distortion of the images - that is probably why Neb's simple registration works so well, but PI is a bit more hit and miss - it's default registration may be a bit too smart - must try dumbing it down.
Four pixels per frame in a spiral pattern (that's what CCD Commander does).
4 pixels right, 4 pixels down, 8 pixels left, 8 pixels up, 12 pixels right, 12 pixels down, 16 pixels left, 16 pixels up, and so on.
Because I am refocusing every 30 minutes (my typical exposure is 7.5 minutes, as per yours/Stan Moore's algorithm), I only get to the 8 pixels up, before having to start again. But, I think there's enough variability between exposures at 3.51"/pixel, that it's good enough. Seems to be producing the goods so far.
I've been capturing RGB at bin 2x2, and hoping that dithering by a factor of 2 should suffice for registration against bin 1x1 luminance, instead of the traditional resize of the bin 2x2 frames.