It should be 16 bit pixel format. The raw image may be packed 5 bytes for every 4 pixels (10 bit ADC). They have to be converted to 2 bytes per pixel. Is there any way that you could post one of your raw files?
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.
Support was added to raspiraw for the Sony IMX477 in the last few days, but I have not updated my fork that is on my github page. Since my driver is hard-coded from the V2 camera, if the V2 specific constants were changed, it may work with the HQ. These are RAWBLOCKSIZE, ROWSIZE, HPIXELS, VPIXELS. Also, the mode that is requested in the raspiraw command.
I have a HQ camera ordered and cannot test until it arrives. My goal is to have the driver use both the V2 and HQ.
If you have a link to what you have worked on, I would be interested in seeing it.
I apologize, I just noticed how old this thread is and what I think your actual question is. If you are trying to unpack a raw file, take a look at
github.com/jdhill-repo/indi-picamera/blo...er/indi_picamera.cpp lines 870 to 900. I can't remember exactly where I got the format. Hope this helps.
A couple of things to keep in mind that I discovered when I wrote my driver is that there is a 1 second limitation when using V4L2. Also, the response from Raspistill will seem slow because the first few frames are always dropped by design. This results in a 1 second exposure actually needing 7 or 8 seconds to complete.
As mentioned here
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.
Thanks. This is a feature that I have needed for some time. Looking forward to trying it out.
The source for wiringPi was pulled from the public domain several months ago. That is why you are running into the link errors. Try this link to get and install the .deb file for the Pi 4:
Sounds strange, but I can apparently duplicate the memory leak with those options disabled. Using Canon T6s, Astroberry over VNC. I duplicated with upload to client set. After a few images, I get the "Unsufficient Memory" errors.
I did some testing with the CCD Simulator (with the same frame size as the Canon) and did not notice a memory leak, even looping to the FITS viewer.
The 3rdparty drivers were recently moved to their own repository. The link on that page is the old location.
This tutorial may help get you started if you decide to write the driver for the relays :
Also, this may be of interest:
I personally use the WiringPi library with INDI drivers for GPIO control. I have recently used it to add ST4 capability to an INDI raspberry pi camera driver and it works pretty well and is easy to use.