Can the order of operations be modified so that a dither command is sent as soon as the current image is known to be complete or the image download has begun? My images take about 10 seconds to download and it seems like it would be good to allow the dither/settling process to happen during that time.
Thanks,
Jeff
If doable, that sounds like a great idea to me.
An ASCOM camera does not provide a “downloading” status. The image is either ready or it is not. The downloading status you are seeing in SGP is a slight of hand. SGP thinks the exposure time has past so it assumes the image must be downloading. It would be a bit dangerous for SGP to do anything to move the mount during this pseudo downloading time since the camera has not really provided any new status.
In an ASCOM camera, you start the exposure and then you wait for the camera to indicate that the image is ready (exposure completed). Then you must issue additional commands to transfer the pixel array from the camera to your program. For my QSI683 binned 2x2, that transfer takes about 7 seconds. Then another second (or less) to convert the pixel array into a FITS image and save to disk.
So, theoretically, you could issue a dither command just before starting the pixel download so the dither would be performed by PHD2 while the pixel data was downloading from the camera. Once the FITS file was saved, the code would have to wait for the dither to complete before starting another image. But that’s a lot of coding (and testing) to save 7 seconds.
Charlie
We receive this request a lot and we intend to look at it again in 4.0. Early versions of SGPro 2 did this and it ruined so many images that we removed it. Abiding purely by the ASCOM spec, we can determine when it is safe to dither, but even a slight miscalculation by the camera driver in state could allow the dither to ruin a perfectly good image in the last fraction of a second. Technically, this was not an SGPro issue, but this issue was widespread enough on popular cameras that we forced these actions to execute serially. That said, it has been many years since this existed and we will be overhauling and optimizing “between image” actions in SGPro 4.
Fwiw… an example of “slight miscalculation” would be if thew camera driver set the state to “downloading”, but the shutter was still open or is in the middle of closing.
There is no such command for an ASCOM camera. You check the status and then access the pixel array to get the data. The standard says nothing about what accessing the pixel array involves. It might start a download or the data might have already been downloaded. As Ken, said it is problematic to assume how the download works for any particular camera.
We may be having a semantics issue here but there is an ASCOM command to initiate an exposure:
myCamera.StartExposure( ExposureTime, LightFrame );
and an ASCOM command to wait for the camera to complete the exposure:
while( ! myCamera.ImageReady )
{
Sleep( OneSecond );
}
followed by the command to download the pixel array from the camera:
int[,] PixelArray = ( int[,] )myCamera.ImageArray;
Then convert the PixelArray into the actual FITS image and save it. This code is taken straight from the ASCOM documentation.
Charlie
“From the camera” is actually not from the camera at all…but “from the driver”.
This code is almost never reading the data from the camera over the USB. For every ASCOM camera that I’ve ever encountered once ImageReady is true the actual ImageArray has already been populated with data from the camera.
Thus reading the ImageArray is basically instantaneous from our perspective.
Hope that help,
Jared
I certainly can’t make any comments about ASCOM cameras in general, as I only own a QSI683 and a LodeStar X2 but I have time stamps bracketing the
int[,] PixelArray = ( int[,] )myCamera.ImageArray;
command and it takes 7 seconds to execute when the QSI683 is 2x2 binned. If the pixel data was already in the driver, this command would take milli seconds; not the 7 seconds I am seeing. Seven seconds is just about exactly the same amount of download time I see reported by SGP.
In fact, I have timers around the “StartExposure()” and the “ImageArray” commands. When I make a 300 second exposure, I see exactly 300 seconds reported for the exposure command followed by the 7 seconds of the download command. I don’t know what I would see using other cameras, of course.
The initial question was whether or not there is time between the end of an exposure and the start of the download to issue a dither command to run in parallel with the download. It looks like that answer will vary depending on the model of camera as it would depend on when the “ImageReady” flag becomes true; that is, does the ASCOM driver set it to true before the pixel download from the camera or after?
Charlie
Not defined by ASCOM.
Some may, some may not. The best we could hope to accomplish is to start a timer for the frame duration when we issue the start, 
that it started when we asked it too and do the dither after the timer completes which would (on most cameras) mean that the dither would likely happen as the image was being downloaded but prior to ImageReady being set. Waaaay back in the day we did not have the “Super Dangerous Loop” to wait on the ImageReady and lots of images were lost as the dither kicked off while the last few seconds were exposing. You can see this interaction in our logs:
This signifies our timer has completed:
[01/26/20 21:54:50.616][DEBUG][Camera Thread][SQ;CC;] ASCOM Camera: exposure complete, waiting for camera to report image ready...
[01/26/20 21:54:50.625][DEBUG][Sequence Thread][SQ;CC;] Entering super dangerous loop to await image completion...
We have no idea what is happening at this point…camera could still be exposing, image could be downloading. All we know is ImageReady = false. 15 seconds later ImageReady returns true.
[01/26/20 21:54:50.628][DEBUG][Sequence Thread][SQ;CC;] EventMarker(16) - t:M42-1 (0); e:0; f:1; o:
[01/26/20 21:55:05.746][DEBUG][Camera Thread][SQ;] SGM_CAMERA_CAPTURE complete...
The above shows a camera that downloads the image prior to setting ImageReady to true. I’ve added some additional logging around the ImageArray read time so we’ll see what comes out of that.
Thanks,
Jared
Seems like a lot of complexity just to get a 10 second head start on a dither.
Charlie
There is an ImageState property which is intended to be used by the driver to report what is going on during the exposure, before ImageReady is true. In theory it could be used to start movement after the exposure has completed and before ImageReady is true.
But I think that would be a recipe for streaked images where drivers have changed the state at the wrong time or applications have misinterpreted the states.
Using a timer, then hoping the image had completed would be even more risky because there’s no guarantee that the camera will start when StartExposure is called, there can be states before Exposing.
I think the intent was that ImageReady would only go to true when everything to do with generating an image was completed and the image was sitting in the PC memory ready for use. But the specification does not say that explicitly and it looks as if some drivers only read the image from the camera when imageArray is called. I think that’s wrong, an application could call something like:
int pixel = camera.ImageArray(100, 200);
If that was in a loop and every time it was called the driver took 7 seconds to read the data from the hardware it wouldn’t run very fast.
It’s very difficult to write specifications that can’t be misinterpreted.
Maybe a different procedure / algorithem for CMOS camera’s?
Should be nice if possible…
JM
A note of caution. There could be something else to consider. I purposefully disable guiding during image download to prevent USB conflicts. These high MP cameras are susceptible to USB interruptions, no matter how big the memory buffer appears to be.