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.

Wow, ok. Isn't that pretty inefficient? Why not have a queue that the sending thread listens on?

There is already a queue actually and you can see it creating a thread from the preview thread pool . If you can make this operation more efficient, then that's great!

@Anjo, that's awsome progress! I'll try to checkout your branch and build it by your instruction as soon as I can.

Either I'm too stupid or the options parsing is broken (as it was from the beginning, btw).

This here prints totally weird values and even crashes. Any Idea why?

<code>
static int parseArgs(char *str, char *delim, char **argv, int max)
{
int argc = 0;
char* token = strtok(str, delim);
argv[argc++] = token;
while (token != NULL) {
token = strtok(NULL, delim);
argv[argc++] = token;
if(max < argc) {
break;
}
}

return argc-1;
}

static void doArgs(char *str)
{
Options option = StillOptions();
printf("-->\n");
char *argv[64] = {};
char delim[] = " \t\n";
int argc = parseArgs(str, delim, argv, sizeof(argv));
printf("%d\n", argc);
for(int i = 0; i < argc; i++) {
char *token = argv;
printf("0x%8lx >%s<\n", token, token);
}
option.Parse(argc, argv);
option.Print();
printf("--<\n");
}

INDILibCamera::INDILibCamera()
{
char str1[] = "--config /tmp/config.txt";
doArgs(str1);
...
</code>

The config file contains this, but that doesn't really matter- even when you give a normal args string, you just get a garbage Options:

<code>
pi@astrocam:~/astro/indi-3rdparty/build/indi-libcamera $ cat /tmp/config.txt
-n -t 0 -o - --awbgains 1,1 --immediate
</code>

@Anjo, can you put link here to your development branch, so that I can test the code?