Page 1 of 1

Anomaly with RestartPreview command

Posted: Sun Dec 23, 2018 6:00 am
by SteveJP
Hi,

I am experiencing an anomaly when using the "SharpCap.SelectedCamera.RestartPreview()" command.

I have a script that moves the mount every once in a while for dithering purposes, but of course the previews continue to run. Whilst I wait until the mount has stopped moving before grabbing the frame with "SharpCap.SelectedCamera.CaptureSingleFrame()", the frame is blured because the capture has continued whilst the mount was moving.

My solution to this is to use "SharpCap.SelectedCamera.RestartPreview()" when the mount has stopped moving so the blurred frame is effectively discarded, but the RestartPreview command has some weird side effects. Most notably, in the frame caputured after the restart, the colour balance is upset and there are other changes in the image.

It maybe that the restart command is re-initialising the camera or similar, rather than just ditching the current capture. Does that make sense?
My actual script has too many dependancies to make posting it here viable, but the effect can also be seen by invoking the "SharpCap.SelectedCamera.RestartPreview()" manually in the IronPython Console window whilst a preview is in progress. (I've set up my camera pointing at a daytime scene with a very dark filter to make 5 to 10 second exposures practical.) If the restart command is executed whilst captures are running, every few frames the displayed image is corrupted.

I'm using an OSC ASI178MC capturing to PNG files with SharpCap 3.2.

Thanks
Steve

Re: Anomaly with RestartPreview command

Posted: Sun Dec 23, 2018 8:27 pm
by admin
Hi Steve,

for now I'd suggest looking for a workaround to find an alternative way of achieving your goal without using the restart preview option. For instance you might try doubling the exposure value (which should cause the current frame to be dropped in a new frame to be started) and then setting it back to the normal target value. Another option might be to use the pause functionality to stop the next frame from being saved.

Hope this is helpful, Robin

Re: Anomaly with RestartPreview command

Posted: Sun Dec 23, 2018 11:04 pm
by SteveJP
admin wrote: Sun Dec 23, 2018 8:27 pm Hi Steve,

for now I'd suggest looking for a workaround to find an alternative way of achieving your goal without using the restart preview option. For instance you might try doubling the exposure value (which should cause the current frame to be dropped in a new frame to be started) and then setting it back to the normal target value. Another option might be to use the pause functionality to stop the next frame from being saved.

Hope this is helpful, Robin
Hi Robin,
I had implemented a delay after the movement stops before the next "SharpCap.SelectedCamera.CaptureSingleFrame()", so I increased this to greater than the exposure time which means I don't capture the blurred frame. Main issue is that it wastes a lot of time, especially if you want to dither after every frame. I might try changing the exposure as you suggest.
Many thanks
Cheers Steve

Re: Anomaly with RestartPreview command

Posted: Thu Dec 27, 2018 12:44 am
by SteveJP
admin wrote: Sun Dec 23, 2018 8:27 pm Hi Steve,

for now I'd suggest looking for a workaround to find an alternative way of achieving your goal without using the restart preview option. For instance you might try doubling the exposure value (which should cause the current frame to be dropped in a new frame to be started) and then setting it back to the normal target value. Another option might be to use the pause functionality to stop the next frame from being saved.

Hope this is helpful, Robin
Robin, setting the exposure as suggested works like a charm.
Thanks

Re: Anomaly with RestartPreview command

Posted: Thu Dec 27, 2018 11:53 am
by admin
Hi Steve,

that's good to hear I thought that would work because I spent a lot of time trying to make sure that when the user tweaks the exposure value a new frame with a new exposure started as soon as possible (i.e. cancelling any frame currently in progress).

Cheers, Robin