Red Spot Transit tonight (Thur 2 Sept)

[MarkS]

Jupiter's red spot will transit at 00:45BST early Friday morning when Jupiter is relatively high.
Sky will be clear and the seeing might be good.

[MarkS]

Here it is - taken at 00:25 BST Fri 3 Sep - just before the clouds rolled in to obscure the transit.

I realised tonight that my laptop will now cope with more than 5 fps (my previous laptop only had a USB1 port)  So this is 20 fps with the Philips SPC900 webcam on the Celestron C11 with x2 Barlow.  I used Registax to process 1600 frames out of 3600.  Gaussian deconvolution applied with my own software.

There is a little more detail waiting to be pulled out but I wanted a natural result, avoiding that "overprocessed" look



Mark

[PhilB]

That's a seriously nice image, Mark

[Tony G]

Excellent image Mark.   

Tony G

[The Thing]

Stonking picture of the Red Spot. Shows up so well since the SEB went AWOL. Potential magazine submission?

[mickw]

Loads of detail there Mark very nice

[Fay]

Perfection Mark!

[RobertM]

That's another really a great image Mark.

Q.  The disk at the top right shows more of a clean edge but the rest has a fuzzy grey strip around it.  Is that a sharpening artifact ?

[MarkS]

Q.  The disk at the top right shows more of a clean edge but the rest has a fuzzy grey strip around it.  Is that a sharpening artifact ?

I noticed the same myself - it's a very interesting question.  Pete Lawrence's recent Jupiter images on UKAI show exactly the same phenomenon.  Deconvolution should turn the fuzzy planetary edge of the stacked image into a single sharp edge - but instead we see more than one edge.  I think this is a problem of the registration of the images due to the seeing conditions.  Watching the video stream I created, it is obvious that the seeing tends to squash the planet in and out in multiple directions as "waves" of seeing pass over the planet.  So the stacking algorithm has a big problem trying to stack the frames containg the "squashed" planet with the frames containing the "unsquashed" planet.  This does not become obvious until deconvolution comes along and reveals this mis-registration.  Note that this is only a hypothesis.  I have also used the Avistack program - it is a lot slower than Registax but I think it uses a better algorithm for "unsquashing" all the frames so they register more precisely.

[The Thing]

See Martin Moberly Tech Talk on 'Artefacts' in Astronomy Now July 2010 Page 74.
He explains that the rind effect is produced by the seeing. The example he gives is of Mars where the effect can be very pronounced.

[Rocket Pooch]

Hi Mark,

I hope you don't mind but I tweaked it a bit, I think you might be better off using the Waveletts in Ragistax or Maxim, it looks pushed a bit.  Still better than any Jupiter I have done though

Chris


jup3sep10regdcon by chrissuddell, on Flickr

[MarkS]

I think that tweak works well - it certainly cleans up the edge or "rind" effect.

This image was definitely more pushed than my previous one because with the camera working at 20fps instead of 5fps the final stack had a reduced S/N ratio, since each frame only collects 1/4 of the photons but has the same CCD read noise.  We could have a long and interesting discussion about the compromises involved in selecting the optimum frame rate.  I think it should be as low as possible but dependent on the seeing conditions .

Mark