Yes sir, that solved the issue for me. I updated to the latest, setup a capture of 300 and let it run. No issues to report. Thank you for taking the time to get that update in there so quickly.

Hello i have this error:
Found LIBCAMERA Library: /usr/local/lib/aarch64-linux-gnu/libcamera.so
CMake Error at /home/masseris/Projects/indi-3rdparty/cmake_modules/FindLibCameraApps.cmake:43 (message):
LIBCAMERAAPPS Library not found. Please install rpicam-apps
Call Stack (most recent call first):
CMakeLists.txt:14 (find_package)

Ettore

Details please what os, what device, and did you follow stepps I posted on previous page?

This is error, correct in "git clone --depth=1 github.com/indilib/indi-3rdparty"
I resolved with github.com/aaronwmorris/indi-allsky/blob...c/build_libcamera.sh
Ettore

I can't find a way to delete post. I learned that the FITS images need to be deabayered. I did not do that, so I think the issues are artifacts of not using a debayer filter and binning.
Sorry for the post. Like I said, I am a newbie to this.

I am fairly new to INDI stuff.
System:
- RPi Zero 2W
- RPi HQ Camera mounted at backfocus of 16"LX600
- bullseye arm64 lite. Update and upgrade
- apt install -y libcamera-apps indi-bin python3-picamera2 python3-lxml python3-astropy python3-pi
- pip3 install indi_pylibcamera
- indi_pylibcamera_postinstall
- indiserver -v indi_pylibcamera

The INDI driver started ok. Connected CCDCiel from my laptop. Connected to RPi INDI and camera indi_pylibcamera.
I was able to loop th epreview and manually focus and center the start (Procyon.) The preview was mono, of course. Then I started a sequence of 10 images. They were all uploaded to my laptop as FITS files. These images were all binned 2x2.
The next day I was looking at them and they only have a mono images and they have odd gaps every other row and column. I probed the FITS files and it only has that one image.
Did I set something up wrong in the INDI driver? If I capture using libcamera I get color images on the RPi I can move to my laptop, but the FITS images are weird.

@Prof Huster: indi_pylibcamera and indi_libcamera drivers are not the same. indi_pylibcamera is developed with python languege and indi_libcamera is developed in c++. Those are totaly diferent drivers with slightly diferent functionalities, but both are using libcamera underneath.

For questions about indi_pylibcamera you should contact scriptorron at GitHub here: github.com/scriptorron/indi_pylibcamera.

Hello Prof Huster,

please open an issue in github.com/scriptorron/indi_pylibcamera/issues
It would help me a lot when you add one of your FITS images to the issue.

Best Regards,
Ronald

It sounds like your camera uses a Bayer filter to produce color images. This means that in front of each pixel on the sensor, there's a color filter—either red (R), green (G), or blue (. For example, if your camera's Bayer pattern is RGGB, in the first row, you'd have pixels arranged as RGRGRG..., and in the second row as GBGBGB... and so on. When you perform 2x2 binning, you're essentially averaging the values of pixels with different colors, which results in a monochrome (grey) image.

To capture color images, you should avoid using binning. After capturing the image without binning, you'll need to debayer the image to reconstruct the full color. Debayering is the process of interpolating the Bayer matrix to produce a color image. This should give you color images similar to those you obtain when using libcamera directly on the Raspberry Pi.

Thanks for differentialting the two for me. I didnt know that.

OK. I don't think that is the issue because the camera has 4608x2592 color pixels and the 2x2 binned image has 2304x1296 mono pixels. If your hypothesis was true I would expect 4608x2592 monopixels.
Also, in the setup I didn't ask for mono images.
Thanks for the suggestions, though. Next clear night I'll set up for unbinned images.

@Joaquin: Thank you for the good explanation. You hit the nail on the head.

The indi_pylibcamera issue #65 is closed. Prof Huster got raw Bayer images. The tool he used interpreted the data as monochrome. That was also the reason for the checkerboard pattern in the lighter regions of his image.

The header of the FITS image has an attribute "BAYERPAT" which tells the color order in the Bayer pattern. A monochrome FITS image does not has this attribute. As far as I know this makes the difference between monochrome and raw Bayer images in FITS format.

KStars has a setting to enable debayering before showing FITS images on the screen. That allows to see colored images in the preview window. It does not affect the stored image data. Likely CCDCiel has a similar feature.

For my opinion using raw Bayer images is preferred over RGB images. All color cameras I know use Bayer filter. The RBG images are generated in an image signal processor which does the debayering. But this image signal processor usually calculates with integer numbers which leads to loss of information. This is not critical for good exposed images. But in astrophotography the interesting parts of the images are extremely underexposes: the faint nebulas between bright stars are often hidden by the camera noise. Only a special processing makes these details visible:

• Correction of pixel errors: You should use Dark frames to subtract individual pixel bias. If you are a professional you can also use Flat frames to compensate for individual pixel sensitivities. I do not have the equipment for doing Flat frames. But the HQ camera has very homogeneous pixel sensitivity and my optics do not produce vignetting. So I don't use Flat images.
• Debayering: The best debayer algorithms are nonlinear. That's the reason why you need to do debayering after the correction of linear pixel errors.
• Aligning and stacking: This improves your noisy pixel data: the mean grows with the number of frames while the standard deviation grows with the square root of the number of frames. The stacking of hundreds of frames makes details visible which were hidden by noise in the single frames.
• Postprocessing: Here you correct colors/contrast and apply filter.

All these steps should be done with floating point arithmetic! There is a lot of good astro software available for doing this. My preferred free software for deep-sky images is Siril .

The 2x binning of the RPi HQ camera is aware of the Bayer pattern and done in hardware. It only bins pixel of the same Bayer color. The resulting is still a raw Bayer color image.

The indi_pylibcamera indi_pylibcamera driver runs in my setup (2 telescopes with 3 cameras: 2x RPi3 and one RPi0) since over a year without any major issues. In particular of the bad seeing conditions (very bad light pollution due to a near town) I am proud of the pictures I make. See attached image of M27, made of 68 exposures with each 20 second.

I just want to confirm that libcamera(not py) works perfectly with arducam imx462 from arducam(b0333) without their
privtiry module.

Both capturing and streaming.