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?
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. ..
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.