They are merged onto the built-in defaults, the way the proxy's additional_policies and OC_ADD_RUN_SERVICES are, so the name says it: env variable, yaml key and field all carry the prefix. The two that take key:value entries are named in the plural like the other map-shaped settings in this repo, and the README says which of the three takes bare mime types.
Every service that configures thumbnails now carries one thumbnails section whose keys are named like the setting itself, so webdav's thumbnails.max_input_image_file_size and the thumbnails service's thumbnail.max_input_image_file_size read the same, and a key's path matches its env name. Env names are unchanged.
png.Decode and gif.Decode hand back the source colors untouched, so a wide gamut image came out oversaturated where a jpeg, read through imaging, was converted. Real imagor passes the profile on to the client instead.
Environment names keep working, a yaml configuration does not: its keys belong to the section of the service that reads them, and an unknown key is ignored without a word.
CI runs imagor as a service instead of through testcontainers, so the frame limit never reached it and the animation case answered differently there than locally.
Internal only: the fields in webdav, graph and frontend now read Thumbnails like the keys and the variables they carry. The generator keeps its released thumbnail block, field and key alike.
The keys are new in this PR, nothing has them set: a yaml file configures webdav's thumbnail settings under the webdav section, so the key now reads like the variable without its service prefix.
The service is thumbnails and its released variables say so; the new ones said THUMBNAIL. None of them has shipped yet, so they are renamed rather than aliased. The input file size gains the shared OC_THUMBNAILS_ name, because webdav and the generator have to agree on it.
An animated png carried every frame through imaging.Decode, which only the gif path guarded: a 465 KB file with 200 full-canvas frames allocated 226 MB, now 10 MB. png.Decode reads IDAT and ignores an animation's fdAT chunks.
imagor's own defaults are looser, so a difference could pass as agreement. With the frame limit set it truncates the animation where the built-in refuses the file, which the override now records.
The source ceiling had to stand in for the box a request may ask for, two limits with different reasons under one name. webdav decides the preview size and never asks for more than its largest resolution; this is the net for everything else.
The largest rung is the largest box a generator is asked for, and fill and stretch enlarge a small source to fill it, so the rungs above 2048 let a tiny image cost whatever 8K costs. Web asks for 1200 at most.
Only the source was bounded, while fill and stretch upscale, so a tiny image asked for at 7680 allocated accordingly. The pixel budget for animations and webdav's ladder above this are a follow-up.
THUMBNAILS_FILESYSTEMSTORAGE_ROOT named the directory the old service kept files/ in, so reading it as the cache directory moved the cache one level up and left the existing thumbnails behind.
A 429 or 413 is answered without reading the body, which breaks the write; the broken pipe used to mask the status. A 413 now reads as too large, not as a server fault.
A cropping resize now carries imagor's smart segment, which is how the libvips
build and a real imagor keep the region that carries the image, the way main
cropped before the generator moved out. A build without libvips answers the
same request with a centre crop, and the parity suite records that.
Both builds and imagor now crop the same region, a gif is bounded by its
declared frames, the posted body by THUMBNAILS_MAX_INPUT_IMAGE_FILE_SIZE and an
image extracted from a container by the configured input size. The s3 cache
reads a miss where minio reports it.
The push endpoint's HTTP behaviour is asserted in the parity suite now, where
imagor answers the same request, so 41 duplicated service specs are gone and
the 32 that remain are what a non-default config or a helper decides.
Two readme sentences promised a startup refusal without saying that nothing reads these settings when OC_DISABLE_PREVIEWS is set, so a typo surfaces when previews come back on.
André Duffeck