Fast, safe, and complete libvips bindings for Java/JVM projects using the Foreign Function & Memory API.
vips-ffm is a Java library that provides fast, safe, and complete bindings to the libvips image processing engine using the Java Foreign Function & Memory API. It enables JVM applications to perform high-performance image operations like resizing, format conversion, and thumbnail generation with minimal overhead and broad format support. The library solves the problem of slow or cumbersome image processing in Java by leveraging native libvips speed through modern Java native interop.
Java and Kotlin developers building applications that require efficient image processing, such as web services, media pipelines, or desktop tools handling large volumes of images in various formats.
Developers choose vips-ffm because it offers the performance of native libvips with the safety and convenience of Java, using the latest FFM API to avoid JNI pitfalls. Its generated bindings ensure completeness and compatibility, while helper classes simplify usage without sacrificing speed.
Fast, safe, complete libvips bindings for image processing in Java / JVM projects
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Leverages Java FFM API and code generation to achieve speeds that often outperform other Java image libraries, as the README claims it's 'usually the fastest image processing library available for Java.'
Handles modern formats like HEIC, JXL, and WebP through the underlying libvips engine, providing extensive image compatibility out of the box.
Uses arenas and lifetime management via helper classes like VImage and Vips.run to prevent memory leaks and segfaults, ensuring safer native interop.
Tested on macOS, Windows, and Linux across multiple architectures, with Docker tests included to verify behavior in different environments.
Requires JDK 23 or higher due to its use of the Foreign Function & Memory API, locking out projects on older Java versions and limiting adoption.
Does not bundle libvips; users must manually install and configure native libraries on each target system, adding deployment complexity and potential cross-platform issues.
As a relatively new project, it may have undiscovered bugs or lack polish compared to established libraries, with the README admitting it's 'relatively new' and seeking more user feedback.
Requires JVM flags like --enable-native-access=ALL-UNNAMED, careful thread management (usage must be from the thread that called Vips.run), and operational tweaks for long-running applications, increasing initial overhead.