I've seen a few discussions about the possible applicability of the new Raspberry Pi "High Quality" 12MP camera. The issue with using it under Ekos/Indi remains the same as with the old Pi camera. It is controlled directly by the board itself and while there is Raspbian software for single images capture and video capture, there may not be an easy way to route an image anywhere but onto the Pi SD card. I'm guessing a driver does not exist for this and probably isn't on the short list of projects.

Anyone looking at this? I know it is a cheapo camera, but it has some interesting specs and the pixel size is finally almost nearly in the vicinity of respectable.

As mentioned here

www.indilib.org/forum/ccds-dslrs/2718-ra...-teammate/34231.html

I have been using an experimental driver with a Raspi camera for quite a while. It was written for the V2 camera and uses Raspiraw to generate a low-level raw image that I use for guiding. It works just like any standard camera with EKOS, with the exception of video support.

In the past week, the HQ camera support has been added to Raspiraw and I plan on updating the driver when I get a HQ camera and time to add and test it.

Another option on the horizon that I will eventually be looking into is the recently developed libcamera support for Raspi which or may not be a better option.

I've started hacking on a driver here github.com/lboclboc/indi_raspistill but its not near completion. The indi_raspicam probably would work i just learned since its using raspiraw , but the latest raspiraw does not work with the HQ camera, at least I have not made it work. Any one did?

I haven't jumped into the pond with this one yet, but I may and I am watching your work with great interest. I wonder if the maker has produced a SDK for the new camera...

You are welcome to test my first very primitive 0.0 version here github.com/lboclboc/indi_raspistill/rele...V0.0/indi_raspistill
It does not return FITS-images yet but the RAW Bayered format 4056x3040 and only works with this size.
I have not yet figured out how to convert it properly to FITS before returning to indi.
Also, it creates a temporary image file on the RPI box - very crude. But that will be removed shortly I hope.

I know there is a libcamera API but have not seen that it supports this camera. There is also the MMAL-api which raspistill uses and thus also this driver since it contain a slaughtered version of raspistill.

Thank you. I have the camera on order and it should arrive this week. I'll be happy to test as soon as it arrives. Have you considered an out-call to Linux ImageMagick "convert" for the conversion? I know it supports FITS conversion.

That is for sure an option but I have not seen other drivers does this and I think there are some built in support for this, its quite hard to find though how other drivers do this. But sure, if I don't find it I will call some external application like ImageMagick.

It sounds like you are making pretty good progress.

As I understand it, the image is returned to the client as FITS when ExposureComplete(&PrimaryCCD) is used. The image buffer to write your image to is set with the uint8_t *image = PrimaryCCD.getFrameBuffer() line in the generic_ccd example. Then write your image data to the frame buffer ('image' in this case). If the parameters such as height and width are set correctly, a conversion to FITS is performed and the image is sent to the client.

Thanks, that's what I am doing . But the automatic conversion I did not quite get right.
Your comment made me realize now that in earlier tests i did get converted to fits, but it was almost random noise, im thinking its a problem with big- och little endian format. The INDI spec for CCD-buffer says uint8 but not really the endianess what I could find. ..

And yes, that was the problem. The high/low bytes of the image buffer sent to INDI was just mixed. Now its working with preview also.

Good deal. Is there any way that you could post one of your raw files?

The full rawfile is 22M so sorry no I can't, at least not here. But think I do know everything needed not for the format. I described it the README github.com/lboclboc/indi_raspistill/blob/master/README.md

To clearify the README file a bit, the rows are in groups of three bytes. First line is repeated [Blue 8 low bits] [ Green1 8 low bits] [ Blue high 4 bits + Green1 high 4 bits << 4 ] ....
The even lines are [ G2 ] [ R ] [G2+R]

And the problem with getting a FITS-file in INDI is also working now. I just wrote the bytes in the image buffer to INDI i the wrong order.