3 layer images

I’ve written a ASCOM driver for the newly released Raspberry Camera v3, a 12.3Mpx CMOS color sensor with 1.55 uM pixels (see https://www.kiwi-electronics.nl/landing-release/raspberry-pi-hq-camera, data sheet: https://www.gophotonics.com/products/cmos-image-sensors/sony-corporation/21-209-imx477).

One of things I noticed that I couldn’t get SQP working with a 3 layered color ImageArray (type 1 COLOR sensor); even worst SGP crashes when it is offered such an image (which is defined as valid by the ASCOM standard, stating: For color or multispectral cameras, will produce an array of [NumX] * [NumY] * NumPlanes. If the application cannot handle multispectral images, it should use just the first plane.

When I offer a sensor type 2 (debayered) picture SGP works ok but this means the developed driver need to de-color the sensor data, bayer it and by performing this proces introduce lots of unwanted artifacts.

Is it indeed true that SGP can’t deal with sensor type 1 (color) sensors using a 3 dimensional arrays (x * y * 3 planes)?

Correct, I’ve never met an astro camera that wanted to send 3X the data across the line while also doing the work to break the CFA data into 3 channels. Most cameras don’t care about the Bayer matrix. They read the raw bytes, apply gain and offset and then send the 2D array across without ever knowing that they’re a color camera.

If you look in your log you’ll probably see this:
SGPro does not support multi-plane image data. Please adjust settings in order to produce single plane image data.


Ok, good to know. Then I don’t need to search any further for issues in the developed driver… Thanks for replying!


I also notice SGP is calling the ASCOM function ImageArray twice causing download times to be twice as long as necessary. Why is SGP doing this because it seems if I only return the image the second time the ImageArray function is called it works just fine?

I notice this behavior when I use Frame and Focus and when a frame was captured during a sequence…

I’m guessing it’s because of how we’re requesting the type from the image

Logger.debugln($"ASCOM Camera: Data type -> {cam.ImageArray.GetType()}");
imageData = (uint[,]) cam.ImageArray;

You can give this version a shot where I’ve altered that behavior. I believe most ASCOM drivers tend to cache the image array locally so it’s not a download speed issue…but we would incur the COM marshalling…either way this is better.

Thank you,

Hi Jared,

Thanks, it is fixed now. Will this be in future versions of SGP?

PS my driver reads the image via a http request from a Raspberry Pi and was therefor not using the file cache. This made the download periode app. 1,5x as long as necessary…

Yes, it will be in our next release.

Thank you,

1 Like