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
PhD2 Dithering Control ETA?
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.
'+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.
-
- Posts: 408
- Joined: Fri Apr 28, 2017 1:28 pm
- Location: Central Florida
- Contact:
Re: PhD2 Dithering Control ETA?
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
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
- admin
- Site Admin
- Posts: 13344
- Joined: Sat Feb 11, 2017 3:52 pm
- Location: Vale of the White Horse, UK
- Contact:
Re: PhD2 Dithering Control ETA?
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
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
Re: PhD2 Dithering Control ETA?
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.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
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.