Capabilities describes the static capability profile of a Processor. It's safe to embed in HTTP responses — nothing here changes between requests, so callers can cache for the lifetime of the binary.
| 75 | // It's safe to embed in HTTP responses — nothing here changes between |
| 76 | // requests, so callers can cache for the lifetime of the binary. |
| 77 | type Capabilities struct { |
| 78 | // ImageFormats are the canonical lowercase format names the backend |
| 79 | // can decode AND encode (i.e. fully supports for transformation). |
| 80 | // Pure-Go: ["png", "jpeg", "gif", "bmp", "tiff"]; libvips adds |
| 81 | // "webp", "avif", "heic" on top. |
| 82 | ImageFormats []string `json:"image_formats"` |
| 83 | |
| 84 | // CanTranscode reports whether the backend can re-encode between |
| 85 | // formats. Pure-Go is true (it can decode any supported format and |
| 86 | // encode to PNG / JPEG); libvips is also true. Effectively a |
| 87 | // future-proofing flag — false would indicate a degraded build. |
| 88 | CanTranscode bool `json:"can_transcode"` |
| 89 | |
| 90 | // MaxPixels is the hard ceiling on input image area (width * height). |
| 91 | // Decode rejects bigger images before allocating decoded pixel |
| 92 | // buffers — the rejection is on raw dimensions read from the file |
| 93 | // header, not on the decoded buffer. 64 megapixels (8000 * 8000) |
| 94 | // is generous enough for high-end DSLRs and low enough that the |
| 95 | // decode buffer (~256 MiB at 4 bytes/pixel) doesn't OOM the server |
| 96 | // under concurrent uploads. |
| 97 | MaxPixels int `json:"max_pixels"` |
| 98 | } |
| 99 | |
| 100 | // MaxPixelsDefault is the default value used by the pure-Go backend. |
| 101 | // Public so the Capabilities struct's MaxPixels field has a single |
nothing calls this directly
no outgoing calls
no test coverage detected