×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

INDI LibCamera Driver

  • Posts: 74
  • Thank you received: 11

Replied by Anjo on topic INDI LibCamera Driver

For me it does, but again not for raw images. They don't change at all unless you shoot jpegs first.
1 year 3 months ago #89221

Please Log in or Create an account to join the conversation.

  • Posts: 74
  • Thank you received: 11

Replied by Anjo on topic INDI LibCamera Driver

Thanks for this, I hope I'll get try it in the next few days.

Frankly, if I had time I would have written a pure python command line driver (ie, not using picamera2, but forking to a new process and getting stdout or the file it produces). Otherwise libcamera is just too flaky for my tastes.

I'd just have used a pre-exisitng lib like github.com/MMTObservatory/pyINDI/tree/mmtcam_stuff

I think they have a CCD template floating around. But I also definitely wanted video, and have no idea on how to show that on the client and how many props I would have to implement for it.
The following user(s) said Thank You: Ronald Schreiber
1 year 3 months ago #89222

Please Log in or Create an account to join the conversation.

  • Posts: 27
  • Thank you received: 4
@Anjo

Thank you. Last week I started to write the driver based on the mentioned pyINDI package. But then I found too many things to work around and decided to implement the protocol by myself. It was not difficult.

I agree that having the possibility to get processed pictures has advantages. At least when you focus your telescope on a bright star you don't need raw images. In this situation it is more important to have short dead time between changing focus and seeing the effect on the image. With smaller JPG images you can save a lot transmission time. My Raspberry Pi needs about 13 seconds to transmit the Raw image - searching focus becomes a nightmare.
1 year 3 months ago #89224

Please Log in or Create an account to join the conversation.

  • Posts: 74
  • Thank you received: 11

Replied by Anjo on topic INDI LibCamera Driver

OK, so I re-added CloseCamera/OpenCamera calls so the cam is now locked only for the duration of shots.

Playing with the text props will still crash, so be careful with them. Probably best leave them at the first item.

And I added width/height setting. You need to do this on the "Image Setting" page - and make sure your width is divisible by 2.

I also noticed that you can't compile the driver on buster, as there are changes in libcamera (exposure is a long, not a pointer and a few other things). Then again, it probably won't run the newer cams anyway.
1 year 3 months ago #89229

Please Log in or Create an account to join the conversation.

  • Posts: 74
  • Thank you received: 11

Replied by Anjo on topic INDI LibCamera Driver

@OUTTA Have you seen this: github.com/raspberrypi/libcamera-apps/issues/344

I have the waveshare module and contrary to what it reports

2022-12-22T16:38:58: Driver ../build/indi-libcamera/indi_libcamera_ccd: ExposureTime : [14..7229147]

it seems like it does expose for 15s?
1 year 3 months ago #89230

Please Log in or Create an account to join the conversation.

  • Posts: 123
  • Thank you received: 13

Replied by Outta on topic INDI LibCamera Driver

Interesting I have IMX462 but it does not seem to work as expected.
Do you run V4L2 command before or that is in driver? Is that PR in latest version?

Also one thing i noticed about gain, do you use "gain" or "analoggain" parameter. Gain is digital, and analoggain is one we are interested in.
1 year 3 months ago #89231

Please Log in or Create an account to join the conversation.

  • Posts: 74
  • Thank you received: 11

Replied by Anjo on topic INDI LibCamera Driver

From the core and help texts both gains are synonymous
1 year 3 months ago #89232

Please Log in or Create an account to join the conversation.

  • Posts: 123
  • Thank you received: 13

Replied by Outta on topic INDI LibCamera Driver

Indeed you are right,and I have been writing "analog" to terminal for nothing whole last year or so :D
1 year 3 months ago #89233

Please Log in or Create an account to join the conversation.

  • Posts: 27
  • Thank you received: 4
Libcamera knows:

"analogue_gain": This tunes a physical amplifier between pixel circuit and ADC on the camera chip. It influences raw and processed frames.

"digital_gain" and "colour_gains": These are parameters of the software running in the ISP for processing the frames. They are digital multiplication factors and influence only the processed frame. The "colour_gains" are used to set the white balance.
1 year 3 months ago #89234

Please Log in or Create an account to join the conversation.

  • Posts: 74
  • Thank you received: 11

Replied by Anjo on topic INDI LibCamera Driver

Yeah, but:

www.waveshare.com/wiki/IMX519-78_16MP_AF_Camera#libcamera-jpeg

"The gain parameter set will first set the analog gain parameter inside the photosensitive chip. If the set gain exceeds the maximum built-in analog gain value of the driver, the maximum analog gain of the chip will be set first, and then the remaining gain multiples will be used as numbers. gain to take effect. "

So you unless you exceed the analog gain max, you'll never use the digital gain.
1 year 3 months ago #89275

Please Log in or Create an account to join the conversation.

  • Posts: 27
  • Thank you received: 4
That "gain" is implemented by the "libcamera-jpeg" application. But the "libcamera" library distinguishes between analogue and digital gains.

The "libcamera" has algorithms for automated gain control (AGC) and automated exposure control (AEC). As long as these algorithms are not disabled the gain and exposure time settings are ignored (or used as start values for the optimization). I do not know if "libcamera-jpeg" disables the algorithms automatically when you set values for gain and exposure time. But when you use "libcamera" directly you need to disable the algorithms explicitly. Otherwise you will have no control over final exposure time and gains.

The AGC/AEC algorithms do experimental exposures to find optimized values for exposure time and gains. Not only that you do not have control over the final exposure time and gains you will also wait much longer until you get the frame.
1 year 2 months ago #89302

Please Log in or Create an account to join the conversation.

  • Posts: 27
  • Thank you received: 4
Happy New Year!

I pushed a new version of my Python driver to GitHub: github.com/scriptorron/indi_pylibcamera

Screenshots are attached. New in this version is:
  1. selection of different raw modes provided by libcamera
  2. raw frames with Bayer pattern and processed frames as RGB images
  3. processed frames can be scaled to configurable sizes (size of raw frames is defined by camera hardware and libcamera)
  4. the exchanged R ang B channel in the Bayer pattern is fixed

It is tested with HQ camera on Raspberry Pi Zero, controlled by KStars/EKOS from laptop.

The Raspberry Pi Zero is very limited in RAM. The current driver will run out of RAM when you capture a processed frame in full size. Capturing scaled down frames or raw frames in full size works fine.

The driver is still not finished and I will work on it in the next days. There are still some open issues I need to solve. Maybe you know answers to that:
  1. I implemented a "Fast exposure" mode in the driver. Everytime when an exposure finished a new exposure is started and runs in paralell to the processing and transmission of the finished exposure. That works fine when I press "Capture a preview" in EKOS. But EKOS freezes when I pressing "Start framing (looping)": it shows "Downloading..." without ending. Does EKOS do something different when "Fast exposure" ("CCD_FAST_TOGGLE" switch vector) is enabled?
  2. When I configure the HQ camera for RGGB raw frames I get BGGR data. When configuring for BGR processed frames I get RGB data. Is that a bug in "picamera2" or libcamera? Or has that something to do with the global camera info "Rotation"=180?
  3. EKOS allows to safe the images "Locally", "Remotely" and "Both". Is it true that these options set the "UPLOAD_MODE" switch vector? Is it also true that the driver and not the indiserver needs to take care for the local saving?
1 year 2 months ago #89353

Please Log in or Create an account to join the conversation.

Time to create page: 2.296 seconds