Experiments in processing lunar images. SC the winner?

[timh]

Thank you Leandro

Dave.

If you are willing and able to have a go at processing my files then I would be very grateful. I get reasonably good images following the usual SC ser file capture --> Autostakkert -> Registax --> PI (deconvolution) route but it still remains the case that I seem generally to get better results (at least in terms of resolution) when I replace the Autostakkert and Registax steps with just SC processing. It is intriguing - and potentially useful if this really is the case

It could simply be that my judgement about relative image quality is faulty -- maybe what I think is good is actually over-processed ? -- so a second and independent opinion would be very welcome. In the meantime I also attach an image of Clavius obtained via the Sharpcap route. It is a stack of only 110 frames - 5% of the total - so maybe a bit 'thin' but, again, I judged it to be a good image relative to what I could get via the alternative processing route.

Anyway -- I've put up two .ser files - Plato and Clavius - in the public folder of my one drive - about 3-4 Gb each - both RGGB - along with their Sharpcap description files - and the two final images that I got from the Sharpcap processing route -- then PI and then Affinity. Anyone is welcome to have a go -- the objective is to get an image the same or better from the data ?

https://1drv.ms/f/c/330584f8b152fa32/Eu ... A?e=Rb8how

I don't think that access will need a password but if it does it is just 'sharpcap'.

[turfpit]

Tim

I downloaded the files ok. The SER files wouldn't download on Edge but Firefox worked fine.

Your camera - ASI715MC, colour RGGB, 3864x2192, pixels 1.45µm. captured RAW8, 1600x1200 @17fps.

When I started to process one of the SER files, I realised that the figures used for my scope/camera , Autostakkert Alignment Points and Registax Wavelets, could not be directly transferred to data produced with your equipment. I came up with a fast (lazy) way to compare processing workflows. I used Autostakkert!3 and Registax 6 only to process the SER files. That helped me decide on:

• how many frames to stack

• alignment point size

• nodrizzle v drizzle15

First step is choose a suitable anchor point (note that in AS!4 this can be done automatically).

AS_anchor_point.JPG (24.28 KiB) Viewed 3917 times

Load the SER file and run Analyse. The Quality Graph was mainly below 50%. The question - how many frames to stack? I filled in the percent frames to stack at the top right of the screen with 10, 25, 50, 75. Next how many Alignment Points to place? On a Damian Peach workshop he recommended 800 for an ASI174M (which is 1900x1200). I scaled that down to 500 for your 1600x1200 capture area. Drizzle was off. Sharpen was checked which resulted in an '_conv' file being produced with each stack.

AS3.JPG (172.87 KiB) Viewed 3917 times

This is a comparison of the results (P10 = 10% of frames stacked).

comparison_no_drizzle.JPG (62.54 KiB) Viewed 3917 times

I achieved the above by using Registax 4 times - only RGB balance and gamma were used, no wavelets applied (that avoids dealing with 1,000,000 combinations of sliders).

RS6_fast_evaluation.JPG (149.38 KiB) Viewed 3917 times

The above was repeated in Registax for the 4 _conv files (sharpened stacks).

comparison_final.JPG (100.43 KiB) Viewed 3917 times

The above AS!3 + Registax processes were repeated with drizzle15 enabled. This was the final comparison for the drizzle15 stacks.

comparison_drizzle15.JPG (63.45 KiB) Viewed 3917 times

P50 was chosen and the comparison between nodrizzle and drizzle15 was made.
P50 nodrizzle was processed with wavelets in Registax. This was repeated for the 4 stacks using identical wavelets.

RS6_P50_no_drizzle_processed_Clavius.JPG (175.11 KiB) Viewed 3917 times

The best image was considered to be the top right - P50 nodrizzle _conv.

comparison_final.JPG (100.43 KiB) Viewed 3917 times

This was the final image (stack 50%, no drizzle, use sharpened stack _conv file) processed only with Autostakkert 3 and Registax 6. Further processing is possible in your favourite image mangling software.

21_30_29Z_lapl5_ap534_conv_FINAL.jpg (962.05 KiB) Viewed 3917 times

The above was repeated for the Plato image.

AS3_Plato.JPG (165.59 KiB) Viewed 3917 times

RS6_P50_no_drizzle_processed_Plato.JPG (187.25 KiB) Viewed 3916 times

The final image (50% stack and AS3 sharpened _conv file used) processed only with Autostakkert and Registax. I managed 5 craterlets on the floor of Plato.

21_15_07Z_lapl5_ap528_conv_FINAL.jpg (853.22 KiB) Viewed 3917 times

I think you had poor atmospheric conditions for your capture. This would be better data.

AS_good_quality_graph.JPG (11.62 KiB) Viewed 3917 times

The above should give you some ideas on how to tackle evaluation on this scale. Drizzle3 is left as an exercise for the reader.

Dave

[timh]

Hello Dave

Thanks so much for taking a detailed and highly instructive look at the data!

I think that settles the question of the mystery that turned out not to be a mystery -- i.e of why I was apparently getting better images from SC processing than via the more conventional As! --> Registax route.

Some specific points of learning that I took from you about the approach and decision making

1) Pay attention to optimising and choosing the initial anchor point plus optimising the number of alignment points

(here I failed from the start --- I just took the defaults without thinking it through and was using AS3!)

2) Take a systematic approach to initially deciding on numbers to stack and drizzle

(by contrast all I had done was initially set to only low percentage options to stack (10-20) based on a guestimate of the number of frames better than 50% on the quality graph and then just testing yes or no to the drizzle question - also choosing no drizzle in fact)

3) Judge what to take forward based upon the overall exposure looking right and not just apparent detail

(in judging quality I think that my eye was too much seduced by the appearance of more detail in the darker stacks of frames with lower numbers and less overall exposure whereas I note that you made the choice of 50% conv for Clavius - which is probably a better choice to take forward into wavelets etc with more information in it than the rather dark and thin 10-15% images)

4) Also interesting to note where you ended up on the wavelet sliders-- I was using the gaussian ones (more similar to SC I think)

So thanks again Dave. I think the two images you derived are in fact a real improvement

Tim

[turfpit]

Thanks for the kind words Tim.

When I thought about it, there wasn't a lot of work. Select 4 stacking percentages in AS3, set up RS6 with RGB balance, gamma, contrast and brightness (no wavelets) then just drag and drop image 2, 3 & 4. Repeat with AS3 sharpened images. The 'benefit' of Gaussian over 'Default' is that there are now 18 settings to deal with over 6. The technique I use is to move a slider up to 100%, then back off to get a better looking image. Wavelet 1 over-use just introduces noise (think small-structures=noise).

The Autostakkert Quality Graph gives 'relative quality' rather than 'absolute quality'. The leftmost frame on the green curve is the best frame (it could still be poor). Choosing 4 percentage values involves no more work when stacking but does give time to get a brew.

The trouble with sharpening is over-doing it and creating artefacts. A way to tackle the craterlets in Plato would be to close crop the big crater, then more sharpening could be applied to the crater floor. Even the LRO has to compromise on that one https://en.m.wikipedia.org/wiki/File:Plato_(LRO).png

With OSC cameras, this happens:

RGB_histogram.PNG (400.75 KiB) Viewed 3569 times

Notice the blue is weaker. The convention seems to be collect 30% more blue frames if doing RGB filter imaging of lunar. OSC lunar imaging brings its own issues when trying to use saturation to bring out the colour. I have read that vibrance is a better strategy than saturation for mineral moons
https://www.bing.com/search?q=vibrance+ ... 1&hsmssg=0

Maybe you should try out some of your other cameras, particularly mono cameras. Less to deal with in terms of balancing histograms.

At capture time, I expose enough to achieve 60% saturation (hard to do when the histogram is bouncing around). It leaves the onscreen image looking 'too dark' but this seems to leave more headroom for processing.

I have been at the lunar imaging since 2016 - they say the first 10 years are the hardest , so I have only 1 more to go. Some of my early stuff - outrageous with a $10 webcam:

viewtopic.php?t=736

Sweex_webcam.PNG (398.8 KiB) Viewed 3569 times

You might try mono cameras and reduce the capture area to enable a framerate increase. It was 17fps for your Plato & Clavius.

One thing that has intrigued me from this exercise is your pixel size of 1.45µm. I have monochrome cameras with pixel sizes of 2.4, 3.75, 5.6 and 6.45µm. I have been motivated to carry out an exercise with the different cameras when used with IR685, UV/IR Cut and Wratten#25 filters. I will have a range of 120fps down to 0.5fps and a mix of CMOS and CCD cameras. After this week, DSO work is done for me - high % lunar illumination followed by lack of astro dark at 53°N.

A useful reference point for lunar is https://damianpeach.com/lunarindex.htm

Dave

[timh]

Thanks again Dave.

Interesting comments on cameras. Yes the 1.45 um pixels are certainly tiny. I went for that particular camera also for planets and basically because F8 - with an F4 scope and 2X barlow -> 0.125 arcsec/ pixel which 4X samples the maximum theoretical resolution of a 12 inch --- but in practice I am sure something around 2.5 um or so and 2X sampling would be quite sufficient under normal conditions and offer some advantages.

The ASI715MC frame rate improves to > 40 fps at 1024 x 768 -- but of course you pay for those tiny pixels with a reduced-sized image that frames not much more than a single large crater.

Then again -- it is nice to be able to see some colour and something of a local (rather than whole moon) mineral moon effect in craters lying near the terminator i.e. I can't imagine being able to do that currently with a mono camera because such swift filter changes would be needed within the 3 minute or so window (i.e. not being equipped with an auto filter wheel or sure that my RGB filters would all shift focus identically?)

It's all trade offs isn't it!

So yes it would certainly be interesting to try mono with and without an IR filter. Of the equipment I have already the ASI294 MM looks as though it can be run in 2.3 um pixel mode with an FPS of ~ 50-60 fps if I reduce the frame size down to a size that would still yield ~ 3x the area that is possible with the ASI715MC at the same capture rate. So I will try that.

Tim