[dschmidt]

The dev stack made previews with the built-in resizer, which reads the formats Go reads. imagor with libvips reads more, and the server speaks the same endpoint either way, so this points WEBDAV_THUMBNAILS_GENERATOR_URL at an imagor container and adds nothing else to the server.

heic, heif and avif are then added to the announced types, so oc:has-preview and the graph thumbnails relationship say yes for them. One name covers both halves: webdav, graph and ocdav all read OC_THUMBNAILS_ADDITIONAL_SOURCE_TYPES, and for an image type it is at the same time the claim that the generator reads it, so the file is handed over untouched instead of being refused.

image/heic-sequence and image/heif-sequence are announced too. reva maps .heics and .heifs to them, and such a file carries a cover image as its primary item next to the frame track (MIAF requires one), which libheif reads like a plain heic. Checked with the Nokia HEIF conformance files: an animation (MIAF005) and a burst (MIAF006) uploaded as .heics and .heifs get has-preview 1 and a jpeg from the preview endpoint at 64 and 1024. A sequence without a primary item (C026, brands msf1/hevc/iso8 only) still gets has-preview 1 but libheif refuses it ("No or invalid primary item"), the endpoint answers 404 for it.

Nothing else needs naming. The formats both resize backends read, webp and tiff among them, are in the server's own default list and are already announced and previewed without configuration.

Measured against shumc/imagor:1.9.11, with the multipart part typed the way webdav types it: a real .heic (libheif encoded) and an .avif both come back as a resized JPEG, 200. Then end to end on this stack, uploaded over webdav: has-preview is 1 for both and the preview answers 200 at 64, 384 and 1024, as image/jpeg. Worth knowing for anyone debugging later: with the part left as application/octet-stream imagor answers 406 unsupported format from its upload loader, not from libvips. And a heic above the 7680 px input limit (an 8256x5504 one, say) is refused with "image is too large" by the server itself.

The limits in the service are the ones the built-in resizer uses, so both sides refuse the same requests.

imagor is only called by the server, so it stays out of the traefik network and both server instances join the default one to reach it. That makes the traefik.docker.network label effective for the first time, and it was pointing at traefik while docker calls the network web_traefik, so traefik picked whichever network it found first and answered 504. The label now carries the name docker gives it, without hardcoding the project: ${COMPOSE_PROJECT_NAME:-web}_traefik.

Needs a server image newer than the merge of opencloud-eu/opencloud#3397, which is what the stack pulls by default (opencloudeu/opencloud-rolling:daily).

Not part of this: the preview app's own format list is compiled in, so a heic shows a thumbnail in the file list but does not open in the viewer yet. That is #4009, stacked on this.