Bug in using API for Capturing Image


#1

Hi,

I’m using the API for making a model (like MM) for 10micron Mounts. I’m using a QSI CCD. This cam has high speed mode for download. When using the API I can set the speed to “Normal” or “HiSpeed”, but in both cases it seems to be “Normal”. It takes about 20 seconds until the image is ready on the hard disk. Can you check this please ? Perhaps I’m doing wrong.

Remark: Per’s Model Maker uses Maxim and there is a big performance advantage, because taking an image (exposure normally between 2-3 s) takes in total max 5 seconds until solving starts. So we have 15s times 50 (number of model stars) more wait time. With hight Speed download this could be improved a lot.

I’m using the last official release 2.5.1.17

Thanks in advance,

Michel


Save Image thru API and FITS Header keywords
#2

Not all drivers support high speed mode. At one point it was disabled.

Have you tried binning? It speeds up download times significantly as well.


#3

So far I use Highspeed for focusing. There is definitive a difference you can experience in download time. So highspeed is working with the camera and SGPRo, but not through the API. It’s like the population of the FITs headers, which is different (degraded) in comparison to the program when using through the API.
THe more I am using SGPRo through the API the more differences I find. It’s a little bit disappointing for that great software showing degraded features for the same functions working really nicely from the program GUI.

Michel


#4

Michel,

Just a guess, but I don’t think the API has received the polish the rest of the software has. Very few people use it compared to the GUI.

Maybe a feature request?


#5

I wish you were wrong about this, but it’s true. If we were good software engineers, we would use our own API to function. Instead the API has formed around existing code and is kind of a dirty cellar with lots of cobwebs and stuff that bites.

I’ll take a look to see if that didn’t make it into the API.


#6

@mworion

I looked in the capture API and speed is considered. A quick test, shows this to be propagated via the API as expected. I assume you are using the QSI 683? I think the 583 does not have high speed download… I can’t remember for sure though.

Can you capture and send me the JSON payload you are using? The difference in what we are seeing surely must be located in that.


#7

Hello Ken, mads0100,

many thanks for looking into the topic. You wrote a greater software, I really like it. I’m using an QSI690 which supports high speed and I’m share the software supports it, because since the option highspeed is there, focusing is much faster.
For the JSON API, I wrote a wrapper in python just by copying the spec to code. I definitely countercheck the implementation to be sure. I try to get a original wireshark log this evening. But to say: just out of the box I used more or less all functions (telescope data, imaging, solving, device status) without any problems.
Again thanks for looking in.

Michel


#8

Hello Ken,

actual Information via testing:

Request Headers:
{‘Content-type’: ‘application/json’}

JSON Data:
b’{“ExposureLength”: 1, “Width”: 1, “FrameType”: “Light”, “Height”: 1, “Gain”: “High”, “Speed”: “HiSpeed”, “BinningMode”: 1, “X”: 0, "Y ": 0, “IsoMode”: 0, “Path”: “c:\\Users\\mw\\PycharmProjects\\mount\\test.fits”, “UseSubframe”: false}’

Full Url:
http://localhost:59590/json/reply/SgCaptureImage

Python code from wrapper:
def SgCaptureImage(self, binningMode=1, isoMode=0, exposureLength=1,
gain=‘High’, speed=‘Normal’, frameType=‘Light’,
path=’’, useSubframe=False, posX=0, posY=0,
width=1, height=1):
# reference {“BinningMode”:0,“IsoMode”:0,“ExposureLength”:0,“Gain”:“String”,“Speed”:“Normal”,“FrameType”:“Light”,
# reference “Path”:“String”,“UseSubframe”:false,“X”:0,“Y”:0,“Width”:0,“Height”:0}
data = {“BinningMode”: binningMode, “IsoMode”: isoMode, “ExposureLength”: exposureLength, “Gain”: gain,
“Speed”: speed,
“FrameType”: frameType, “Path”: path, “UseSubframe”: useSubframe, “X”: posX, "Y ": posY, “Width”: width,
“Height”: height}
try:
req = request.Request(self.ipSGPro + self.captureImagePath, data=bytes(json.dumps(data).encode(‘utf-8’)), method=‘POST’)
req.add_header(‘Content-Type’, ‘application/json’)
with request.urlopen(req) as f:
captureResponse = json.loads(f.read().decode(‘utf-8’))
# {“Success”:false,“Message”:“String”,“Receipt”:“00000000000000000000000000000000”}
return captureResponse[‘Success’], captureResponse[‘Message’], captureResponse[‘Receipt’]
except Exception as e:
return False, ‘Request failed’, ‘’

I don’t get any error message in ‘Message’ field and a ‘Success’ of True. So no hint what’s going wrong.

Attached the test I do:
print(cam.SgGetDeviceStatus(‘Camera’))
print(cam.SgGetDeviceStatus(‘PlateSolver’))
print(cam.SgGetCameraProps())
print(time.ctime())
success, message, receipt = cam.SgCaptureImage(1, 0, 1, ‘High’, ‘HiSpeed’, ‘Light’, ‘c:\Users\mw\PycharmProjects\mount\test.fits’)
print(success,message,receipt)
while True: # waiting for the image download before proceeding
success, imagepath = cam.SgGetImagePath(receipt)
if success:
break
else:
time.sleep(0.1)
print(success, imagepath)
print(time.ctime())

and the actual output to this:

(True, ‘CAPTURING’)
(True, ‘IDLE’)
(True, ‘Success’, 3388, 2712, True)
Mon Oct 3 15:08:35 2016
True Image capture started successfully. 9bbc794449f84b7e9bae63131953549a
True c:\Users\mw\PycharmProjects\mount\test-3.fit
Mon Oct 3 15:08:47 2016

So it takes about 22 seconds to get this image. The only point I can guess, that the key/value pairs are not written correctly for some reason. I try to check this out !

BTW: The camera status is also not correct all the time. Actually it says ‘CAPTURING’ which is definitely not true. If you do an image, you might get ‘IDLE’, which is the correct state. No imaging on GUI during that time.

Michel


#9

Hi Ken,

sorry to bother you again. My guess could be right. I tested different Key’s which might say Fast Download e.g. ‘Fast’, ‘FAST’, ‘HighSpeed’ instead of the spec from the program:

Speed path string No The download speed of the camera (if supported). Values are “Normal” or “HiSpeed”.

I succeed in using ‘HighSpeed’ instead of ‘HiSpeed’. The Download times are now about 11 seconds not 21. Still SGPro ist doing ‘Analyzing Star Data’. Which takes about the half of the time left (5 secs). Because actually you can’t access this data remotely, it doesn’t make sense to analyze it. Just takes time with no value.

It would be nice to countercheck the discovery, still the new bug with device status ‘camera’. The rest is like a feature request. If you plan to extend the API -> the voting place wasn’t that bad. I’ll try to test it definitely.

My personal working split between SGPro and Remote programs: let SGPro do and automate all things getting images and image plans. Setting up mount, controlling other environment (like environment data for setting refraction parameters in mount) I keep separately.

Michel


#10

Hmm. That doesn’t make much sense to me… I checked the serializer and enumeration for that setting. You can see it here:

public enum CameraSpeed { Normal, HiSpeed }

Using a value like “HighSpeed” would seemingly have no effect. I will try your request payload and see what happens.


#11

Ken,

I have to apologize. Your right, doesn’t have any effect. In my hurry I didn’t take care about my setup. With the short times I used the ASCOM CCD Simulator. With the QSI690 attached, I’m unfortunately back to 21s regardless which setting (‘HiSpeed’, HighSpeed’, ‘Normal’ etc.) I use. So it’s still open. I compared it to MaximDL (which I tested). This will have the Image does remote controlled within 5s in total. Hope you can do something about it.

Many thanks,
Michel


#12

Me too. Haven’t had time just yet. When you are not using the API, like when using frame and focus in SGPro, does the camera respect the “high speed download” flag?


#13

Hi Ken,

tried it, as expected the camera respect the high speed download. I have reduced download times from about 12s (without set) to 3 s (with set). So fast download works from GUI.

Michel


#14

@mworion

I have found and fixed the issue. It will be available in 2.5.2.4.


#15

Ken,

Great, many thanks. Will test it.

Michael


#16

Hi Ken,

tested it successful with 2.5.2.4 and it works fine ! Thanks for the bugfix and the quick fix. That’s extraordinary with you and the team.

Michel


www.mainsequencesoftware.com