Jupiter 13-05-2017

[vlaiv]

After seeing superb shots by Angie (U Cyg) posted here and done with 8" scope, I decided to give my RC8" a go at Jupiter.

Here is the result:

Equipment used: RC8", ASI178mcc, APM 2.7 barlow element on nose piece (giving roughly x1.5)

Data: ~45000 frames at 4ms exposure over 4 minutes, 8bit capture, stacked 60% of frames, x256 darks, x256 flats and flat darks (these taken as 16bit)

Processing: PIPP for calibration, AS!3 beta for stacking, Registax wavelets, AstraImage wavelets & multiscale sharpening, Gimp for layering images sharpened in Registax and AstraImage (two differently sharpened images layered).

Seeing was very good at the beginning of the evening - I was observing the Jupiter with 8" F/6 dob at ~ x350 - x400 and view was excellent (among the best I've had of Jupiter so far), but as I waited for more darkness in order to polar align my scope (and of course I forgot to take out RC to cool down properly, because I had good time looking at the Jupiter ) seeing started to decline, after I managed to setup everything and wait a bit for scope to cool down - seeing got quite a bit worse.

This is actually first recording of four I took that evening, but seeing just got worse later on, so this one is the best.

After processing I also noticed that choice of barlow might have not been the best. APM x2.7 is coma corrected, and probably best used with Newtonian scopes at native magnification. In one of the later images, Europa just emerged from the shadow, and was in FOV, and I noticed that it has coma like aberration - I suspect this has to do something with APM barlow being used on RC with shorter spacing (to give optimum mag for asi178). I should probably only use APM with my dob, and get myself Baader Vip for imaging.

Comments and critique are welcome.

Thanks for looking.

[MarsG76]

Nice image, and you have some great data there but I think that capturing 4 minutes of video and stacking 60% probably introduced some motion blur to the image due to Jupiters rotation.

Try splitting the video file into 4 and stacking the best 25% and do it on 4 split files... once you have the 4 stacked images, derotate and stack them in WinJupos, you might get more details with out the motion blur.

 

[vlaiv]

30 minutes ago, MarsG76 said:

Nice image, and you have some great data there but I think that capturing 4 minutes of video and stacking 60% probably introduced some motion blur to the image due to Jupiters rotation.

Try splitting the video file into 4 and stacking the best 25% and do it on 4 split files... once you have the 4 stacked images, derotate and stack them in WinJupos, you might get more details with out the motion blur.

 

Yes, that is always a concern with Jupiter and its rotational speed. I'm not sure that derotating is necessary with 4mins at this scale.

Diameter of Jupiter on this scale is roughly 240px, and given that Jupiter rotates with period of ~ 10h, in 4 minutes it will rotate ~0.042 radians - which translated into pixels at center would be ~5 pixels for complete duration. Now in single frame there sure is no motion blur that we could speak of and during the processing, different parts of Jupiter jump up and down due to seeing sometimes more than 5pixels which would be just 0.85" at this scale of ~ 0.17"/pixel, even between the frames, and AS!3 with its alignment points copes with this quite well.

But I might be wrong, and indeed your suggestion of creating mini animation which I would later derotate and stack again, sounds very reasonable, I might give it a try, my only concern with it is that I'm not sure if 25% of frames will be enough, I did try to work with 25% of total stack, and noise was just to big.

[Jeff-Colorado]

Wonderful image with nice details. Thanks for sharing the imaging info. I have an 8SE/224MC and have been experimenting with different settings. I'm new to imaging and there is definitely a learning curve. I've been limiting my Jupiter capture to 2 minutes. Perhaps I'll try 2.5 minutes and see how it turns out (with motion blur).

[MarsG76]

18 hours ago, vlaiv said:

Yes, that is always a concern with Jupiter and its rotational speed. I'm not sure that derotating is necessary with 4mins at this scale.

Diameter of Jupiter on this scale is roughly 240px, and given that Jupiter rotates with period of ~ 10h, in 4 minutes it will rotate ~0.042 radians - which translated into pixels at center would be ~5 pixels for complete duration. Now in single frame there sure is no motion blur that we could speak of and during the processing, different parts of Jupiter jump up and down due to seeing sometimes more than 5pixels which would be just 0.85" at this scale of ~ 0.17"/pixel, even between the frames, and AS!3 with its alignment points copes with this quite well.

But I might be wrong, and indeed your suggestion of creating mini animation which I would later derotate and stack again, sounds very reasonable, I might give it a try, my only concern with it is that I'm not sure if 25% of frames will be enough, I did try to work with 25% of total stack, and noise was just to big.

True, 25% can be and is a lot nosier than thousands of frames but I find that more details are retained due to lower rotation blur, later when derotated and stacked the noise is improved greatly.

[Stub Mandrel]

I can see the extra detail an 8" pulls out over my 6" scope.

The other evening I tried using 1 minute, but then stacking 20 of those using WinJupos.

One of the best one-minute runs:

Twenty runs stacked with Winjupos, with weighting of the better runs:

[vlaiv]

36 minutes ago, Stub Mandrel said:

I can see the extra detail an 8" pulls out over my 6" scope.

 

I think that we are still operating in severely seeing limited domain, nowhere near what both 6" and 8" scopes could provide in terms of optics resolving power alone.

Take for example this image:

It was taken with 130/900 newton (average optics at the best - mass produced instrument). It does not lag much in terms of detail resolved compared to above images. I took it back in 2015, about 6 months after I got into astronomy - talk about beginners luck . At the time I really had no clue how to judge the seeing, or what would be best exposure time / gain setting - but seeing must have been great on that particular night.

It really is down to seeing, I mean, look at this blurry mess:

That is raw stack image prior to processing  - and it looks like it was taken with 2" optics at the best . I'm, by the way, truly amazed how much detail can be teased out with advanced processing like wavelet and multi resolution enhancement and sharpening. It can really pull detail out of thin air (or is better term in this case thick air? ).

@MarsG76

I'm still not convinced about 1 minute split technique. Why would it be better than just derotating the whole video? WinJUPOS uses frame timestamp to judge how much derotation to apply to it. If you make 1 minute video stack with AS! what time would you assign to it? Start of video? middle one or end of the video? How can you be sure where the best frames lie? Also, how can you be sure what is the proper time for reference image created by AS! ? It looks to me that using this technique you will end up with more motion blur (because of uncertain times) then by derotating the whole video and then stacking.

By the way, does anyone know if there is option to force 16bit output from PIPP? I took x256 dark frames, and those stacked have 16bit precision, also flat frames have 16bit precision as recorded. Main video is 8bit, but I feel that after calibration more noise is injected if it is saved as 8bit rather than 16bit.

 

[Stub Mandrel]

2 hours ago, vlaiv said:

It can really pull detail out of thin air (or is better term in this case thick air? )

2 hours ago, vlaiv said:

If you make 1 minute video stack with AS! what time would you assign to it? Start of video? middle one or end of the video?

I tell PIPP to use the middle of the video and use 'winjupos compatible filenames'

I haven't tried using PIPP to derotate video, I agree with your earlier point that the drift is negligible 230s either side of a mid-point compared to the effects of seeing.

2 hours ago, vlaiv said:

By the way, does anyone know if there is option to force 16bit output from PIPP?

It will output 16 bit SER or TIFF, but I think you have to put 16 bit in? Autostakkert eats 8 bit frames and spits out a 16-bit stack.

I don't use calibration frames with PIPP; I'm not sure darks make any significant difference with such short exposures. With my lifecam I had to steer the planet away from dust bunnies, at the moment the ZWO is 'pure enough' not to need flats.

[vlaiv]

1 minute ago, Stub Mandrel said:

I don't use calibration frames with PIPP; I'm not sure darks make any significant difference with such short exposures. With my lifecam I had to steer the planet away from dust bunnies, at the moment the ZWO is 'pure enough' not to need flats.

Hm, maybe the term dark is a bit misleading here. It's more about the bias (because one is using same exposure time as light frames it's technically dark frame, but you are effectively only capturing bias signal), and you'll find that it is more than important with with such exposure. This is because bias signal can have irregularities on order of few electrons. At exposure times of 10ms or less, one is getting something like 50-100e per pixel form Jupiter. Now, if your bias signal is close to flat, then you don't have to subtract it, but if it varies by couple of electrons, you will improve your SNR quite a bit. Mind you I'm not talking about read/bias noise here but rather bias signal.

Now with flats, I might be overdoing it. I do it not only because of dust and shadows but because I noticed that CMOS chips have irregular amp/qe over pixels, so even in perfectly flat illumination there are gradients over the chip, and even pixel to pixel difference. Not sure how much in percentage it varies between the pixels (I can calculate it, by using one of my master flats), but I made it a habit to take flats as well just to be safe and remove any unwanted signal.

Ok, I just quickly examined flat frame for ASI178, here is magnified / normalized / stretched part of it:

and values here vary by much as +/- 1% (1.0 +/- 0.01).

256 flats were taken to produce master flat, with signal level around 4000e giving shot noise SNR of a single flat of 60, when stacked SNR of shot noise for master flat will be 1000 - that is +/- 0.1% so above variation is clearly not due to shot noise of recording of flat.

So by using flats I'm correcting for about 0.5e of noise on 50e signal - as I said I might be overdoing it, but that is close to level of read noise for this camera (1.4e).

[Stub Mandrel]

55 minutes ago, vlaiv said:

Hm, maybe the term dark is a bit misleading here. It's more about the bias (because one is using same exposure time as light frames it's technically dark frame, but you are effectively only capturing bias signal), and you'll find that it is more than important with with such exposure. This is because bias signal can have irregularities on order of few electrons. At exposure times of 10ms or less, one is getting something like 50-100e per pixel form Jupiter. Now, if your bias signal is close to flat, then you don't have to subtract it, but if it varies by couple of electrons, you will improve your SNR quite a bit. Mind you I'm not talking about read/bias noise here but rather bias signal.

 

Here's a single, unprocessed (edit - actually stretched to 85% white point), frame of jupiter from the other evening, more or less at random, it wasn't anywhere near astro-dark here at about 10:00pm, hence the grey background. At maximum stretch I think the variation in the background is one or two counts at 8-bits, and that with all sources of noise combined. If I capture 16-bit 9actually 12-bit) SER then I think darks and flats might be more useful.

[vlaiv]

1 hour ago, Stub Mandrel said:

 

Here's a single, unprocessed (edit - actually stretched to 85% white point), frame of jupiter from the other evening, more or less at random, it wasn't anywhere near astro-dark here at about 10:00pm, hence the grey background. At maximum stretch I think the variation in the background is one or two counts at 8-bits, and that with all sources of noise combined. If I capture 16-bit 9actually 12-bit) SER then I think darks and flats might be more useful.

Is this raw frame attached or is it some sort of screen capture / compressed with some sort of compression like jpeg?

If it is single raw frame, then its probably not worth for you to use bias / flat frames at all. This frame shows signs of compression. This is common with some webcams / wdm drivers when using avi capture and for example YUV2 codec. It introduces additional artifacts into image, often blurring the features and lowering SNR. It is often used in webcams over raw to boost fps (less data to transfer).

Calibration will work only on true raw data. Check if you are able to record raw data / ser format instead of avi.

By the way, this looks like really good frame compared to mine. My guess is it is in 20-30ms exposure?

[Stub Mandrel]

It's a screen grab of uncompressed AVI video, saved as a png. It doesn't look like that at home - much darker and somewhat smoother. The curse of SGL which chews up any less than perfect image strikes again...

I think it was 31ms.

[vlaiv]

You can do following just to make sure:

Take a single frame from avi, save it as fits (pipp will do this, just limit number of frames to 1, or couple). You can set white point but skip any other processing. You should also separate R, G and B, and then inspect any of those.

Take that mono fits frame and stretch the background. If you get following pattern, then it is probably yuv2 codec to blame (windows wdm drivers sometimes use it on webcams):

Raw read noise is much more fine grained - per pixel, so each individual pixel has different random value (even if low bit sampling, or high stretch, you should be able to pick individual pixels scattered around). The pattern that you see on this screen shot is typical of block type compression algorithms (similar artifacts can be observed with jpeg). This is because, for example in yuv2, rgb is coded into luminance and hrominance channels and each channel is encoded in special way, so instead of 8:8:8 you get 4:2:2 (being number of bits per channel), so neighbouring pixels with similar color and / or luminance end up being "bunched" up into rectangular blocks.

Another really simple way to check this would be to see the size of avi file. It should be larger than number of frames x width x height x 3 bytes. If it's less than this - there is some sort of compression in play.

If file is compressed, then switching to raw recording (if possible) should greatly improve sharpness of your images.

[Pete Presland]

Some nice detail visible in your image Vlaiv, the seeing really is critical to high resolution images. Obviously good collimation/set up ect..... is important as well, but without the seeing its a struggle. 

[MarsG76]

20 hours ago, vlaiv said:

I think that we are still operating in severely seeing limited domain, nowhere near what both 6" and 8" scopes could provide in terms of optics resolving power alone.

Take for example this image:

It was taken with 130/900 newton (average optics at the best - mass produced instrument). It does not lag much in terms of detail resolved compared to above images. I took it back in 2015, about 6 months after I got into astronomy - talk about beginners luck . At the time I really had no clue how to judge the seeing, or what would be best exposure time / gain setting - but seeing must have been great on that particular night.

It really is down to seeing, I mean, look at this blurry mess:

That is raw stack image prior to processing  - and it looks like it was taken with 2" optics at the best . I'm, by the way, truly amazed how much detail can be teased out with advanced processing like wavelet and multi resolution enhancement and sharpening. It can really pull detail out of thin air (or is better term in this case thick air? ).

@MarsG76

I'm still not convinced about 1 minute split technique. Why would it be better than just derotating the whole video? WinJUPOS uses frame timestamp to judge how much derotation to apply to it. If you make 1 minute video stack with AS! what time would you assign to it? Start of video? middle one or end of the video? How can you be sure where the best frames lie? Also, how can you be sure what is the proper time for reference image created by AS! ? It looks to me that using this technique you will end up with more motion blur (because of uncertain times) then by derotating the whole video and then stacking.

By the way, does anyone know if there is option to force 16bit output from PIPP? I took x256 dark frames, and those stacked have 16bit precision, also flat frames have 16bit precision as recorded. Main video is 8bit, but I feel that after calibration more noise is injected if it is saved as 8bit rather than 16bit.

 

I usually capture multiple 1 minute videos when imaging jupiter, so when I stack each one, in Winjupos for derotating I use the time that ICap or FireCapture creates on the file name which is the start time. I imagined that splitting the 4 min video into 4 1 min clips would have a similar effect.

 

Come to think of it.. Derotating the whole video file in WinJupos is probably a better procedure than splitting the file.