Docker image

[tenekev]

Hello, I'd like this but I realized thee is no Docker image for it. It will be a nice way to expand the userbase. I know I can install it in an LXC and whatnot but a Docker image would be much easier.

[gosku]

A Docker image has been in the plan, the honest reason it hasn't been prioritized yet is the camera side. The "push recipes to camera" feature talks to the camera over USB, and USB passthrough into a container really only works on a Linux host. So a Docker version would mainly give Linux users a third option, while the two big draws of a containerized setup ( bind-mounting your photo library and browsing the whole catalog, recipes, and relationship graph from the web UI) are already available to Linux users today through the two native install modes (lite and full). That made it hard to justify bumping up the queue.

That said, a lot of the value here is the browse/catalog/recipe side, which runs great in a container regardless, camera push just stays something you'd do from a machine with the camera physically plugged in. Let me look into it properly, and I'll follow up here once there's something to try.

[tenekev]

Appreciate the effort. In my opinion, a docker image allows for easier evaluation in the first place. And there is a lot of functionality that doesn't require a camera.

I'm just wondering here - and I might be putting the whole project on its head - but is it possible to connect the camera via the web interface? I know that applications like ESPconnect, which is a webapp, can connect to usb-connected devices on console ports. Again, I'm not familiar with the architecture of the project, so I'm just curious.

[gosku]

I'm just wondering here - and I might be putting the whole project on its head - but is it possible to connect the camera via the web interface?

It is definitely possible. While investigating the ptp connection, I found https://github.com/eggricesoy/filmkit, which implements the ptp client in typescript and connects to the camera using WebUSB, delegating all the connection responsibilities to the browser. The reason I discarded it is because

1. The PTP library filmkit implements is not complete, there were some gaps (fields that are ignored, dependencies that are not taken into account, etc...)
2. I'm not a front-end savy, and although the ptp vendor is simple enough to be implemented by AI (just functions that send values to specific memory addresses), if we moved the "push to camera" feature to the client, we would need to implement the usecases to interact with the camera, and these are more advanced, with retries with exponential back-off, failures detection and report, etc.

In summary, the decision of implementing the ptp library in python was based on familiarity with the stack, and the specifics are explained in this ADR: https://github.com/gosku/Filmcase/blob/main/docs/ADRs/001-camera-bridge.md

I would be open to consider a new client-side ptp client if someone wants to implement it, as long as it is opt-in and we can test it.