Is this poor focus?

[Stub Mandrel]

I tried Jupiter again last night with a different,cheaper webcam that promised a higher frame rate with USB1. Unfortunately despite Sharpcap reporting a higher frame rate (10 fps) it wasn't really, and from 14000+ frames PIPP only found about 140 distinct frames :-(

Sadly it clouded over after a fairly short period of captures, so I assumed the met office and not clearskies was right. In fact it cleared again, half an hour after everything packed away ... grrrr.

The seeing was so brilliant last night I was knocked out by the clarity of the images on the computer so I didn't fiddle with the focus as much as usual.

So my question today is, is the generally low-level of detail in these pics likely to be due to poor focus or the webcam itself? The top shot was taken using slightly lower resolution, but appears better to me.

[PeterCPC]

How do you get focus?

Peter

[Pete Presland]

Are these images from all 14000 frames? if so considerable blurring of the details will occur due to rotation of the disc.

[Stub Mandrel]

I've had two more goes. The two runs less than a minute apart at lower resolution gave 83 distinct frames, which I ended up selecting from manaully to get 19 decent frames and now the north temperate belt is visible. I had to use PIPP, tehn select frames in Registax, export as AVI, stack with astrostakkert then back to registax for wavelets.

No matter what I do with the higher res images, I can't get close to the above picture. I think the Webcam must have been interpolating at the higher res and actually losing detail.

I think my crummy laptop and lack of tracking are limiting my success.

[Scorpius]

These are all excellent captures and ones to be proud of for sure. My favorite is the one at the top but I'm wondering if you may have reached the limits of your current equipment as tracking and a better camera would almost certainly produce better results.

Here's my best shot of Jupiter so far captured with a Celestron 8" SCT on an AVX motorized EQ mount with the Celestron Neximage 5 planetary web cam...

Point is - a motorized EQ mount and more sensitive camera would go a long way toward maximizing your results in conjunction with your already excellent imaging skills...

[Leveye]

As stated above you really can only do about 2 minutes before you'll have rotation issues in your images. That could be part of the problem here. 

[Freddie]

At that image scale 3+ mins wouldn't be a problem. My usual is 2.5 mins at ~9m so the 2 mins is a bit too short. You need to consider image scale when determining AVI duration. 

[Stub Mandrel]

Thanks, I need to be patient and wait for a faster laptop.

[Pete Presland]

Surely 14,000 @ 10 fps is 20 minutes+ which would be too long at any focal length?

[Stub Mandrel]

Oops - 1400 frames not 14000, in fact I have 1617 over 7 minutes if I add in the first run. That's 9 runs of about 17 seconds each at about 10 fps. This is what PIPP says (set not to discard any valid frames):

  Estimating input frames:
    Total input frames: 1617
  Processing 1617 frames:
    Using 1617 RAM buffers for quality selection
  Quality processing:
    Reordered 118 images
  Processing Details:
    Calculated '-minpixel' value: 21
  Summary:
    PIPP version: v2.5.1
    Total input frames: 142
    Frames discarded with no planet detected: 14
    Frames discarded with partial planet detected: 10
    Frames discarded by quality: 0
    Total output frames: 118
    Quality Algorithm: PIPP Default
    Output Frame Type: Colour
    Output Frame Format: AVI
    Output Directory: C:/Users/Neil/Pictures/Astronomy/Sharpcap 08 pluscom/pipp_20150419_201733/
 
Runtime: 3.2 seconds
PROCESSING COMPLETE

So out of 1600-odd frames it only finds 142 distinct images (i.e. 90% are repeats - I can see this is true by running the video) and only 118 have the full disc.

On this desktop the lifecam will do a genuine 30 FPS, that would give me some 300-500 potential images from one run across the FOV, I could probably get 2,000 usable ones without needing any tracking in two minutes.

[D4N]

If you go over two minutes on Jupiter you need to consider using derotation software like winjupos otherwise your detail will just smear itself across the image.

7 mins is a long time on Jupiter.

By distinct frames do you mean that the software is just recording the last frame over and over until it gets a new one from the camera? Sounds a bit odd.

Sent from my iPad using Tapatalk

[Stargazer33]

17 second runs sound way too short. Also spreading 9 runs over 7 minutes and Jupiter will have rotated too much at your image scale to get a clean image (unless you derotate as D4N says). Do you track by hand or is your NEQ3 motorised? Either way, 2 to 2.5 min runs would be much better. You can still do lots of runs but don't stack all the runs together or you will get the same issue with the surface detail rotating and blurring the image.

Nice images btw.

[Freddie]

At that image scale I'd go for 4 min AVIs to get a decent number of frames to work on. Don't worry about derotation for that duration as it is really only needed at larger image scales, the stacking prog will take care of any marginal movement between frames from start to end of capture.

[Pete Presland]

Agreed 4 minutes at that focal length should give a decent amount of data. What settings are you using in Sharpcap?

[cgarry]

Oops - 1400 frames not 14000, in fact I have 1617 over 7 minutes if I add in the first run. That's 9 runs of about 17 seconds each at about 10 fps. This is what PIPP says (set not to discard any valid frames):

  Estimating input frames:

    Total input frames: 1617

  Processing 1617 frames:

    Using 1617 RAM buffers for quality selection

  Quality processing:

    Reordered 118 images

  Processing Details:

    Calculated '-minpixel' value: 21

  Summary:

    PIPP version: v2.5.1

    Total input frames: 142

    Frames discarded with no planet detected: 14

    Frames discarded with partial planet detected: 10

    Frames discarded by quality: 0

    Total output frames: 118

    Quality Algorithm: PIPP Default

    Output Frame Type: Colour

    Output Frame Format: AVI

    Output Directory: C:/Users/Neil/Pictures/Astronomy/Sharpcap 08 pluscom/pipp_20150419_201733/

Runtime: 3.2 seconds

PROCESSING COMPLETE

So out of 1600-odd frames it only finds 142 distinct images (i.e. 90% are repeats - I can see this is true by running the video) and only 118 have the full disc.

On this desktop the lifecam will do a genuine 30 FPS, that would give me some 300-500 potential images from one run across the FOV, I could probably get 2,000 usable ones without needing any tracking in two minutes.

Hi,

From reading your output, although the video file claims to have 1617 frames, PIPP is only actually finding 142 frames.  This is a massive inconsistency to say the least so something is going wrong.  This is not about PIPP finding distinct frames, it is only finding 142 frames of any kind.

What format is the input video?  And how big is the file?

Cheers,

Chris 

[Stub Mandrel]

The input videos are AVI and claims to be 15 FPS, although sharpcap was reporting an actual rate nearer 10 FPS. The frames captured number agreed with this.

When I play them back it's more like a series of still images being shown roughly a second apart.For example, onbe taht is 19 seconds long at 15 FPS should have nearly 300 frames, but jupiter crosses it in about 42 jerks :-(

[Cath]

You could always upload an MP4 compressed (not to much though) version of your videos to your web space or youtube to allow others to see what kind of source data you're trying to to work with.

[cgarry]

It definitely sounds as if the AVI files have only got a fraction of the frames that they should have.  The simplest way to check this is to look at the file size and compare that with a rough calculation of the expected file size.

A more accurate way is to right-click on the file in PIPP's Image Files List and click on 'Show AVI File Details'.  This will generate a detailed text description of the AVI file structure which should show what the problem is.

Cheers,

Chris

[Stub Mandrel]

Thanks Chris. This is what it shows 0x80000000 is '-1' in hexadecimal, so I'm assuming that means (in this example) about four out of five frames are missing.

  |    |    Entry 138: offset: 0x45c3e08, size: 0x240000
  |    |    Entry 139: offset: 0x0, size: 0x80000000
  |    |    Entry 140: offset: 0x0, size: 0x80000000
  |    |    Entry 141: offset: 0x0, size: 0x80000000
  |    |    Entry 142: offset: 0x0, size: 0x80000000
  |    |    Entry 143: offset: 0x4804008, size: 0x240000
  |    |    Entry 144: offset: 0x0, size: 0x80000000
  |    |    Entry 145: offset: 0x0, size: 0x80000000
  |    |    Entry 146: offset: 0x0, size: 0x80000000
  |    |    Entry 147: offset: 0x4a44208, size: 0x240000
  |    |    Entry 148: offset: 0x0, size: 0x80000000
  |    |    Entry 149: offset: 0x0, size: 0x80000000
  |    |    Entry 150: offset: 0x0, size: 0x80000000
  |    |    Entry 151: offset: 0x0, size: 0x80000000
  |    |    Entry 152: offset: 0x0, size: 0x80000000
  |    |    Entry 153: offset: 0x4c84408, size: 0x240000

[cgarry]

Yes, I think your analysis is completely correct.  That is the kind of thing you often see with a dropped frame, though that is obviously a lot of dropped frames!

I think we need to get some input from SharpCap's creator Robin (rwg here on SGL) about what is going on.  It might be worth sending him a PM in case he does not stumble across this thread.

Cheers,

Chris