@Jasem can you create libcamera dev branch and give access for few of us so we can freely push and then we can do PR when we have something.

What do you mean libcamera dev branch? Each project has their own repos. You indi indi-libcamera driver? you can fork that. We're using libraw to decode any raw files, I already implemented that in the driver.

Anjo, I have never use it before, but I thing git submodules could help you with that: git-scm.com/book/en/v2/Git-Tools-Submodules

What he means is a common branch at indi to work on without needing PRs. I don't know if that's possible though.

If you guys send me your github nicks, we can use my fork and I'll invite you.

As a sidenote, when you set video to MPEG, it now works just fine. Only raw doesn't and crashes.

No it wouldn't, as we need 3 things: have the code locally, being able to change it and integrate it to the indi driver build so you don't need the shared libs installed.

With submodules you just pull in the code into your dir structure. You could make patch scripts and integrate them into your builds, but for now that's just too slow. I really don't want to learn cmake.

Also submodules are not accepted in INDI GIT.

Understandable. Anyway, we should copy and modify the code for now and maybe later strip it apart if someone feels like putting in the time.

Can you give me a hint on how to get the builds to use the local libcamera-apps dir? I got includes to work, but not the actual code, it still requires the .so being installed.

OK, JPEG exposures work now, too. DNG doesn't work as it expects raw, but gets yuv420. Should be easy to fix, though. There's a yuv_save method.

Jasem, I'm a bit fuzzy on what does what... can the indi stuff really handle raw data from the camera or do we need to transfer it to RGB anyway to send it into the ekos pipeline? The DNG/JPEG are just for the exposure, not what is being sent, right?

Streams are apparently unstable. I see lots of pthreads being created while streaming. I doubt that this is normal.

In INDI there is concept for CAPTURE FORMAT and TRANSFER/ENCODING format.

Capture format can be anything supported by the hardware. Transfer format is FITS or NATIVE.

To take JPG as example, if encoder format is NATIVE, then the JPG data is sent as is. If encoder format is FITS, then you need to break it into RGB in Primary camera buffer and send this over. This is already implemented in the driver.

So the conversion is just needed for fits. Got it.

OK, I fixed the libcamera build files to built statics. So you can now

mkdir build && cd build && cmake .. && make

and get a fully static built driver which does not rely on the shared libs. So that's one step less and should make debugging easier as you can now set breakpoints in the libcamera app code

The most pressing issues are:

- provide a way to set and parse the options. Again, for now I'd strongly advise to just use a string field and let the Options parse it. UI can come later
- first step for UI should be gain, I guess
- fix DNG. Apparently when doing raw exposures, you'll get yuv instead of dng, so the saving stuff should consider that.
- figure out the stablity issues when doing video. It works for a few times, until it doesn't and crashes. What I see is a LOT of threads getting created but I haven't figured out why or how.

Also, there seems a link between image exposure type and stream type.

You have the stream thread + each time a new frame is dispatched, a thread is created to upload the image to the client and then destroyed. This is why you see so many threads.