Accepts a picture with its annotations already drawn into it, and stores that rendering as display variants.

Why the client renders it

The browser has the annotation layer on screen, drawn by the same engine that will draw it next time. Composing there means the stored picture IS what the user was looking at: the same fonts, the same label plates, the same smooth marker strokes, and no second renderer to keep in step with the first. Etcher.Raster remains the server-side path for backfill and for files nobody has open, where an approximation is the right trade.

What this means for trust

The bytes come from a client, so they are treated as a picture and nothing more: re-encoded through ImageProcessor.sanitize/3 into the variant slot, never served back as uploaded. The caller must be signed in and allowed to edit the file, and the annotation set is not consulted — this endpoint replaces a rendering, it cannot change what the file's annotations ARE.

What gets written

The burn arrives at full resolution and is resized into whichever slots the caller names (thumbnail by default) in one request — making one is expensive enough that nobody should have to send it twice.

Writable slots are thumbnail (list rows), burned (grid cards, fit inside an 800px box) and burned_large (the copy the media viewer opens with, fit inside 1920px). small, medium, large and original are not writable. The editor opens on small and climbs medium → large → original, drawing the live shapes on top; a burn stored in any of those would paint every annotation a second time. original stays the picture as uploaded for the same reason a rendering must stay removable.

The client sends source_version, the v query of the original URL it composed over. When that names an original this file no longer has, the write is refused.