PhD2 Dithering Control ETA?

Got an idea for something that SharpCap should do? Share it here.
Forum rules
'+1' posts are welcome in this area of the forums to indicate your support for a particular feature suggestion. Suggestions that get the most +1's will be seriously considered for inclusion in future versions of SharpCap.
umasscrew39
Posts: 316
Joined: Fri Apr 28, 2017 1:28 pm
Location: Central Florida
Contact:

Re: PhD2 Dithering Control ETA?

Post by umasscrew39 » Wed Oct 02, 2019 2:14 pm

Oh- I did not have this option. I just downloaded the 30th Sept version and it now appears. Thanks so much, Nick. Greatly appreciated. I only had a very thin black border on one side but I think I will reduce the 20 steps a little.

Regards,
Bruce

celkins
Posts: 33
Joined: Fri Apr 20, 2018 10:58 pm

Re: PhD2 Dithering Control ETA?

Post by celkins » Thu Oct 03, 2019 3:02 am

Hi, Robin,
further to the above discussions, I've tried to use the Live Stacking approach tonight, and whilst it is an improvement, it just shows up that the PHD interface state machine isn't sufficiently clever: I run 2 instances, controlling 2 cameras; I set one of these to dither, say every 180 seconds, which corresponds to every 2 frames for this instance: for the other instance, this corresponds to every 3 frames, but because it doesn't notice that a frame has been spoilt by the other instance dithering, I end up with bad frames in the stack - tried to use the FWHM filter, but failed...
The situation just becomes worse if both initiate dithering, because both then suffer ruined frames.

When I used to use Nebulosity 4 for image capture, it was possible to get the 2 instances running synchronously by starting a run simultaneously on both, having both set to initiate dithering, but with a "wait" (say, 5 seconds) between frames to provide for jitter - your option of minimum settle time sort of provides this, but only for the instance that initiated the dither: the other instance ignores it... With Neb4, his resulted in the second-issued dither command being ignored, since a dither was already under way, but both instances then sat watching & waiting for PHD to settle to the specified degree, before carrying on with their next frame: frame exposures had to be very close, doing this, but rarely were any subs lost...

Hope this makes sense - 8 hours into a session, now, 'cause it's not very often that the clouds clear...

Carl

User avatar
admin
Site Admin
Posts: 4760
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: PhD2 Dithering Control ETA?

Post by admin » Thu Oct 03, 2019 6:57 pm

Hi,

I understand what you're getting at, but I think that's beyond the scope of what I'm aiming for at the moment – right now I'm keen just to get things working right for those using the simpler setup of one camera and one copy of SharpCap controlling PHD directly.

Cheers, Robin

chongo228
Posts: 119
Joined: Fri Nov 24, 2017 3:34 am

Re: PhD2 Dithering Control ETA?

Post by chongo228 » Sun Oct 06, 2019 10:41 pm

celkins wrote:
Thu Oct 03, 2019 3:02 am
Hi, Robin,
further to the above discussions, I've tried to use the Live Stacking approach tonight, and whilst it is an improvement, it just shows up that the PHD interface state machine isn't sufficiently clever: I run 2 instances, controlling 2 cameras; I set one of these to dither, say every 180 seconds, which corresponds to every 2 frames for this instance: for the other instance, this corresponds to every 3 frames, but because it doesn't notice that a frame has been spoilt by the other instance dithering, I end up with bad frames in the stack - tried to use the FWHM filter, but failed...
The situation just becomes worse if both initiate dithering, because both then suffer ruined frames.

When I used to use Nebulosity 4 for image capture, it was possible to get the 2 instances running synchronously by starting a run simultaneously on both, having both set to initiate dithering, but with a "wait" (say, 5 seconds) between frames to provide for jitter - your option of minimum settle time sort of provides this, but only for the instance that initiated the dither: the other instance ignores it... With Neb4, his resulted in the second-issued dither command being ignored, since a dither was already under way, but both instances then sat watching & waiting for PHD to settle to the specified degree, before carrying on with their next frame: frame exposures had to be very close, doing this, but rarely were any subs lost...

Hope this makes sense - 8 hours into a session, now, 'cause it's not very often that the clouds clear...

Carl
If you ran both of your instances in live stacking I think the alignment failure would automatically discard the frame that was smeared while the other frame dithered. At some point you might ruin two frames because the dither would start and end in two different frames but you wouldn't have to sort through them.

I believe a future/next version of SC is going to have the ability to set up a sequence. I'm guessing you could set up some step for your second camera to perform every time the other one would dither.....maybe tell it to focus or shift filters for 30 seconds and then start taking photos again.

Post Reply