Camera image download not completing

[CheekyMonkey]

INDIGO Version 2.0-236 APT version 4.20 ASCOM 6.5 SP1 6.5.1.3234

INDIGO Client: Windows 10 laptop, connected over Gigabit LAN INDIGO Server: Raspberry [i 4 (8 gigabytes memory), connected over Gigabit LAN

Camera connection via INDIGO->ALPACA->ASCOM successful but any image capture attempt results in the camera image download not completing at the client end

On the INDIGO server device (Raspberry Pi 4) I do observe that the image file is getting created ok

INDIGO trace log attached (split into two zipped files indigo1.log, indigo2.log) covering the duration of the issue for the Canon 700D (from start to "ctrl C" stop of the INDIGO service at the end)

Cameras tested: Canon 700D, ZWO ASI224MC

NB The issue occurs when attempting to capture an image on the camera via N.I.N.A.(v3.0) or via A.P.T (V4.20), namely the camera connects ok in each application but the image download attempt never completes following capture

With INDIGO Ain Imager (v0.99-1 (64 bit)) and INDIGO Control Panel (v0.13-2 (64bit)) running on the same Windows 10 laptop the camera image capture and download completes every time without issue. I observe that after an image capture attempt with the same camera, the image file gets created on the client and also on the server without issue

The same issue occurs with my ZWO ASI224MC camera. The camera connection is made but any image capture results in the image download not completing

my.indigo.config.zip

indigo1.zip

indigo2.zip

[rumengb]

I see your problem, for some reason, you are using the ill-designed (unusable) Alpaca data transfer which even alpaca designers admit it is next to useless. It would transfer a single image I'm something like a minute or so... That is why they implemented something a bit better but far from the efficiency of native INDIGO. Please use the "ImageBytes" transfer method:

or alternatively, try "BestAvailable", both work for me:

However, I discovered an issue that we introduced recently. See the several broken lines at the top. I know what exactly is wrong. and I am going to fix it...

[CheekyMonkey]

Thank you @rumengb

I selected the "ImageBytes" option Outcomes as follows:

A.P.T. ZWO ASI224MC: camera image now downloads without any issues (with "ImageBytes"). Canon 700D: camera image now downloads without any issues (with "ImageBytes")

N.I.N.A. ZWO ASI224MC: camera image now downloads without any issues (with "ImageBytes"). Canon 700D: now presents an error at the client after the image download attempt (both with "ImageBytes" and also with "Best Available")

Canon 700D: N.I.N.A trace log: 2023-05-21T20:25:10.1564|ERROR|AscomCamera.cs|DownloadExposure|626 System.InvalidCastException: Unable to cast object of type 'System.Int32[,,]' to type 'System.Int32[,]'. at NINA.Equipment.Equipment.MyCamera.AscomCamera.<>c__DisplayClass173_0.<b__0>d.MoveNext() in C:\Projects\nina\NINA.Equipment\Equipment\MyCamera\AscomCamera.cs:line 618 2023-05-21T20:25:10.1568|TRACE|AscomCamera.cs|ASCOM Download|39|Start: 21.05.2023 07:25:04.341; Stopped: 21.05.2023 07:25:10.156; Elapsed: 00:00:05.8149848 2023-05-21T20:25:10.1569|ERROR|ImagingVM.cs|CaptureImage|225 NINA.Equipment.Exceptions.CameraDownloadFailedException: Camera download failed. Exposure details: Exposure time: 3, Type: SNAPSHOT, Gain: -1, Filter:

I'll set trace logging at the INDIGO server, reproduce the issue and will then share the INDIGO log here shortly

Edit: INDIGO trace log now attached

myindigo.zip

[rumengb]

If APT works but NINA does not, the problem is not related to INDIGO or ASCOM/Alapaca, is most likely related to NINA and the best thing to do is to contact NINA maintainers for support.

[CheekyMonkey]

Thanks @rumengb I just now ran the ASCOM conformance check on both the Canon DSLR driver and also on the ZWO ASI 224MCS driver

The ZWO ASI driver passed the ASCOM conformance test with 0 errors The Canon ASCOM driver failed the ASCOM conformance test with 1 error

I've attached the conformance log output here for reference

I have a feeling that although no error was given in the APT UI, the camera image may not have actually downloaded. I have the camera outside on my OTA currently covered so will do a proper test once I have the camera uncovered and pointed at something

Canon 700D ASCOM conformance.txt ZWO ASI224MC ASCOM conformance.txt

[rumengb]

I am not sure what is the difference between: /camera/{device_number}/imagearrayvariant and /camera/{device_number}/imagearray

But the problem is that 10s are not enough for imagearrayvariant to transfer the data. The log clearly states that it timed out. On the other hand imagearray barely managed - it took 7s to download the image.

Looking at the 224 log: 21:22:42.794 ImageArray OK Successfully read 32 bit integer array (1 plane) 1280 x 960 pixels in 147ms. 21:22:43.571 ImageArrayVariant OK Successfully read variant array (1 plane) with System.Int32 elements 1280 x 960 pixels in 758ms.

imagearrayvariant took 5x more time, so if it is poportional for 700D it would take 35s which is obviously more than 10s

So please increase the timeout.

[CheekyMonkey]

Thanks @rumengb

I see a 10 second timeout setting as shown below

I've now increased this value to 60 seconds

I still see the following in the conformance checker log

22:57:36.172 ERROR System.TimeoutException: The "StartExposure" operation exceeded the timeout of 10 seconds specified for this operation. at ConformU.AlpacaProtocolTestManager.WaitWhile(String actionName, Func1 waitFunction, Int32 pollInterval, Int32 timeoutSeconds, Func1 statusString) in C:\Users\peter\source\repos\ASCOMInitiative\ConformU\ConformU\AlpacaProtocolTestManager.cs:line 2155 at ConformU.AlpacaProtocolTestManager.<>c__DisplayClass38_0.b__0() in C:\Users\peter\source\repos\ASCOMInitiative\ConformU\ConformU\AlpacaProtocolTestManager.cs:line 545

Is there some other place in the configuration to set the timeout value?

[rumengb]

No idea. Maybe the conformance checker has it hard coded. The conformance checker is intended to check ASCOM which is not network-enabled and was never intended to be, that is why Alpaca is more of a cludge rather than a real fix to the problem, that comes with the downsides of all cludges: clumsy, inelegant and inefficient.

Is not surprising that there is only one real Alpaca driver out there. And it is not for a camera but for a focuser (Optec). Until very recently (maybe a year ago) image transfer was so inefficient that you had to send at least 10x the amount of data than necessary, and even now with their enhancement, it is far from being efficient. This is what they say about the performance:

So please increase this timeout to 100s and try NINA directly.

[polakovic]

Canon 700D: N.I.N.A trace log: 2023-05-21T20:25:10.1564|ERROR|AscomCamera.cs|DownloadExposure|626 System.InvalidCastException: Unable to cast object of type 'System.Int32[,,]' to type 'System.Int32[,]'. at NINA.Equipment.Equipment.MyCamera.AscomCamera.<>c__DisplayClass173_0.d.MoveNext() in C:\Projects\nina\NINA.Equipment\Equipment\MyCamera\AscomCamera.cs:line 618 2023-05-21T20:25:10.1568|TRACE|AscomCamera.cs|ASCOM Download|39|Start: 21.05.2023 07:25:04.341; Stopped: 21.05.2023 07:25:10.156; Elapsed: 00:00:05.8149848 2023-05-21T20:25:10.1569|ERROR|ImagingVM.cs|CaptureImage|225 NINA.Equipment.Exceptions.CameraDownloadFailedException: Camera download failed. Exposure details: Exposure time: 3, ...

The problem is, that monochrome sensor is reported but RGB image is sent. I'll look at it.

[polakovic]

So I fixed sensor type request, it reports color for any camera handled with indigo_ccd_ptp driver now, but it doesn't change N.I.N.A behaviour, it still tries to cast 3D array (colour image) to 2D array (mono image). No idea why, the same configuration with ASCOM conformance tester works without problem and image size is correct.

https://github.com/indigo-astronomy/indigo/commit/88375297ca1030beb757c875b554f1b3369fcb7e

[rumengb]

I have fixed the image shift.

[CheekyMonkey]

Thanks for the speedy updates @rumengb and @polakovic :)

I've compiled the latest INDIGO build on my Pi with your updates Some observations from my side

As of now both NINA and APT continue to fail to bring back the captured image from my Canon 700D, although I can see that the image does get generated on the server as a .raw file N.B. I've set the standard response time out value to 120. See below:

When taking an image either through NINA or APT with the Canon 700D via the INDIGO/ALPACA/ASCOM connection I observe that an image file gets created on the Raspberry Pi as expected The file has a .raw extension. See examples below (screen captured from the Raspberry Pi)

I've tried to view the .raw file in a .raw file viewer but the raw file viewer (FastRawViewer) returns a "broken file or unsupported format message" and will not display the image file

When taking an image with the Canon 700D either through AIN INDIGO Imager (on a Windows 10 laptop) or via ASTRODSLR (on a Mac), I observe that the image file gets created on the Raspberry Pi as a .cr2 file which I am able to read without any issue N.B. The .cr2 image file is also successfully transferred from the Raspberry Pi to the client when the image is taken with either AIN INDIGO Imager or ASTRODSLR

I'm attaching here an example .raw file and a .cr2 file for reference. N.B. Both images will show darkness as the cap is over the telescope under cover right now DSLR700D__2023-05-22_Dark_nofilter_51c869edd544352754b7489377499c98.zip

Canon700D_May_22_2023__2023-05-23_Dark_nofilter_f1453c780ab6d95483ebb726c442c38e.zip

[rumengb]

Peter knows better this part, but to be honest we do not really know what is expected from the clients. maybe they do not support this pixel format. I know Ivo the crater of APT and I will try to work with him to figure this out. I am not aware if there are ASCOM drivers for dslrs at all so i suspect nobody ever tested Alpaca in this context with DSLRs.

By the way, why do not you use Ain if you are on windows or linux and Astrodslr on Mac, it is way more efficient to use native INDIGO?

On Tue, May 23, 2023 at 2:15 PM Acapulco Rolf @.***> wrote:

Thanks for the speedy updates @rumengb https://github.com/rumengb and @polakovic https://github.com/polakovic :)

I've compiled the latest INDIGO build on my Pi with your updates Some observations from my side

As of now both NINA and APT continue to fail to bring back the captured image from my Canon 700D, although I can see that the image does get generated on the server as a .raw file N.B. I've set the standard response time out value to 120. See below:

[image: image] https://user-images.githubusercontent.com/537672/240245103-a692b024-efa4-4ceb-9ddc-f2e1f6894f55.png

When taking an image either through NINA or APT with the Canon 700D via the INDIGO/ALPACA/ASCOM connection I observe that an image file gets created on the Raspberry Pi as expected The file has a .raw extension. See examples below (screen captured from the Raspberry Pi)

[image: image] https://user-images.githubusercontent.com/537672/240246033-e7c6ded1-ca01-4976-841e-d1e5bf7ca3c7.png

I've tried to view the .raw file in a .raw file viewer but the raw file viewer (FastRawViewer) returns a "broken file or unsupported format message" and will not display the image file

When taking an image with the Canon 700D either through AIN INDIGO Imager (on a Windows 10 laptop) or via ASTRODSLR (on a Mac), I observe that the image file gets created on the Raspberry Pi as a .cr2 file which I am able to read without any issue N.B. The .cr2 image file is also successfully transferred from the Raspberry Pi to the client when the image is taken with either AIN INDIGO Imager or ASTRODSLR

I'm attaching here an example .raw file and a .cr2 file for reference. N.B. Both images will show darkness as the cap is over the telescope under cover right now DSLR700D__2023-05-22_Dark_nofilter_51c869edd544352754b7489377499c98.zip https://github.com/indigo-astronomy/indigo/files/11543016/DSLR700D__2023-05-22_Dark_nofilter_51c869edd544352754b7489377499c98.zip

Canon700D_May_22_20232023-05-23_Dark_nofilter_f1453c780ab6d95483ebb726c442c38e.zip <https://github.com/indigo-astronomy/indigo/files/11543007/Canon700D_May_22_20232023-05-23_Dark_nofilter_f1453c780ab6d95483ebb726c442c38e.zip>

— Reply to this email directly, view it on GitHub https://github.com/indigo-astronomy/indigo/issues/479#issuecomment-1559086527, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE5EZBLSIRH4ETS4NQTCIFDXHSL3TANCNFSM6AAAAAAYJQFFOE . You are receiving this because you were mentioned.Message ID: @.***>

[CheekyMonkey]

Thanks again for the guidance @rumengb

For me, this is just an INDIGO/ALPACA/ASCOM trial/experiment to see if I could get this setup working so I could choose an imaging client that I'm used to and use with my other setups e.g. N.I.N.A or A.P.T.

In the mean time, I'll see how things go and will experiment with AIN INDIGO imager until the INDIGO/ALPACA/ASCOM DSLR image download "bug" is ironed out with A.P.T. and N.I.N.A. clients

N.B. An ASCOM DSLR driver does exist but it is not used as part of the INDIGO/ALPACA/ASCOM setup (as far as I understand how this all works, at least)

[rumengb]

I have tested it with real alpaca and it works so the problem is definitely in the alpaca agent. We need to trace the communication and see what is wrong.

[CheekyMonkey]

Thanks @rumengb Last night I did some investigation under the stars

My observations below: I used CCDciel (V0.9.82) as the client running on a Windows 10 laptop

CCDciel was able to capture and download the images from my Canon 700D DSLR without issue using the ASCOM.Alpaca connection

The camera image download worked with both a LAN connection and also a WIFI connection back to the Raspberry Pi server, although with WIFI, camera image download time performance was pretty poor, but on reading the guidance in the CCDciel documentation, that's to be expected With a LAN connection image download time performance was so much better, as expected

So something is up with the way that APT and NINA are doing the image data download Did you get a chance to speak to Ivo (APT developer) about it all?

FYI some info from the CCDCiel documentation below for reference

[rumengb]

Yes, I tried INDIGO Alpaca agent against CCDCiel... and it works... but only if the client is ASCOM/Alpaca, the CCDCiel Alpaca implementation does not even discover the Indigo Alpaca exports... the mystery deepens...