Codec and Format Selection
Latest stable Based on Image release 0.3.0
Separate three questions: can the API name a format, can the selected backend encode or decode it, and does the target host provide the required codec? Treating them as one question creates deployment-only failures.
Portable JVM path
Section titled “Portable JVM path”Immutable image processing uses Scrimage and ImageIO providers. JPEG and PNG are the safest general-purpose paths. TwelveMonkeys dependencies extend TIFF and metadata handling. WebP writing uses the Scrimage WebP integration. SVG is rasterized through optional Batik dependencies, so the application must add Batik when it accepts SVG input.
Animated GIF-to-WebP, TIFF, and SVG deserve explicit fixture tests. Metadata, animation, transparency, and color behavior can differ even when decoding succeeds.
libvips path
Section titled “libvips path”The common Vips API exposes image formats and encoding options, while the Java 21 and Java 25 implementations delegate capability to their native binding and installed libvips. AVIF and HEIC are incubating paths. Verify the target machine with real encode and decode fixtures; do not infer support from a developer laptop.
Selection rules
Section titled “Selection rules”- JPEG: photographs where lossy size reduction is acceptable.
- PNG: lossless output, alpha, diagrams, and exact visual fixtures.
- WebP: use after browser/client and encoder behavior are verified.
- TIFF: document and archival input; test multipage and metadata requirements separately.
- SVG: untrusted XML input needs strict size and external-resource policy before rasterization.
- AVIF/HEIC: deploy only after native codec verification and fallback design.
Record accepted input formats separately from generated output formats. A service rarely needs to accept every format it can produce.