Ansel in the cloud

[aurelienpierre]

Ansel can run in CLI, using ansel-cli binary. We use that in CI bots, on Github action runners, to ensure Ansel starts and can process a dummy picture, on top of compiling. The CLI variant takes a raw image and an XMP file as input, and outputs any JPG/PNG/TIFF you want.

GPU are becoming increasingly expensive, and buying one might force you to change your whole computer for motherboard compatibility, or will just not be worth it if you edit pictures a couple of hours every week. Not to mention electrojunk and recycling issues.

The solution could be to share a server instance with a big fat GPU between users, and running ansel-cli on that server. The architecture could be simple (famous last words) and we are almost there:

• init a tunnel between client (Ansel desktop) and server (Ansel CLI),
• user starts editing a picture: send the raw input to server,
• user changes module parameters:
  1. save them immediately to XMP, (*)
  2. send XMP to server,
  3. render the output JPG on server using cached raw input + new XMP, through ansel-cli, (*)
  4. fetch the JPG output from server,
  5. paint the JPG in the desktop application. (*)
• same for export.

(*): those steps are already part of the default Ansel architecture and require none to minimal changes.

Also, Ansel already has a Docker image ready to boot on any server within minutes. Remains to configure remote access (sockets ? Ngingx ? SSH ?).

Challenges:

• (BIG) write a server-side scheduler to share GPU compute time uniformingly among users,
• redundancy/instanciability to dynamically start new remote compute instances to meet demand spikes,
• secure remote-local bridge and cached data for privacy,
• managing abuse/unfair use by some users (tiered subscription ? throttling strategies ?)

Benefits:

• recurring income for an Ansel cooperative, through subscriptions,
• cheaper, better scaled and more eco-friendly than buying each their own GPU,
• falling back from remote to local rendering (in case of network loss or overloaded server) is transparent.

[pedrorrodriguez]

This could be something interesting both as a revenue stream and as a community service. Particularly for professionals with many images to export

[mmoqui]

Why writing a server-side scheduler to share GPU resources to users (id est to Ansel clients)? IMHO, for a first step, we should leave the GPU resources sharing to the underlying Linux kernel and, instead of implementing a resources planner, we could implement an infra in which an ansel-cli process is bootstrapped (thanks to Docker swarm for example or by using Kubernetes) for each new Ansel client (Ansel Desktop). And each connection closing with the server process shutdowns that process. By doing, we can then see the benefit of a such solution to users (independently of how it is implemented), monitor the limitation of such a mechanism (and then the ways to improve it by baby steps), and so on.

[aurelienpierre]

Docker has a lot of overhead though, swarming it seems wasteful.