TwelveMonkeys ImageIO provides extended image file format support for the Java platform, through plugins for the javax.imageio.* package.
The main goal of this project is to provide support for file formats not covered by the JDK. Support for these formats is important, to be able to read data found "in the wild", as well as to maintain access to data in legacy formats. As there is lots of legacy data out there, we see the need for open implementations of readers for popular formats.
| Plugin | Format | Description | R | W | Metadata | Notes |
|---|---|---|---|---|---|---|
| Batik | SVG | Scalable Vector Graphics | ✔ | - | - | Requires Batik |
| WMF | MS Windows Metafile | ✔ | - | - | Requires Batik | |
| BMP | BMP | MS Windows and IBM OS/2 Device Independent Bitmap | ✔ | ✔ | Native, Standard | |
| CUR | MS Windows Cursor Format | ✔ | - | - | ||
| ICO | MS Windows Icon Format | ✔ | ✔ | - | ||
| DDS | DDS | MS Direct Draw Surface Format | ✔ | - | Standard | |
| HDR | HDR | Radiance High Dynamic Range RGBE Format | ✔ | - | Standard | |
| ICNS | ICNS | Apple Icon Image | ✔ | ✔ | - | |
| IFF | IFF | Commodore Amiga/Electronic Arts Interchange File Format | ✔ | ✔ | Standard | |
| JPEG | JPEG | Joint Photographers Expert Group | ✔ | ✔ | Native, Standard | |
| JPEG Lossless | ✔ | - | Native, Standard | |||
| PCX | PCX | ZSoft Paintbrush Format | ✔ | - | Standard | |
| DCX | Multi-page PCX fax document | ✔ | - | Standard | ||
| PICT | PICT | Apple QuickTime Picture Format | ✔ | ✔ | Standard | |
| PNTG | Apple MacPaint Picture Format | ✔ | - | Standard | ||
| PNM | PAM | NetPBM Portable Any Map | ✔ | ✔ | Standard | |
| PBM | NetPBM Portable Bit Map | ✔ | - | Standard | ||
| PGM | NetPBM Portable Grey Map | ✔ | - | Standard | ||
| PPM | NetPBM Portable Pix Map | ✔ | ✔ | Standard | ||
| PFM | Portable Float Map | ✔ | - | Standard | ||
| PSD | PSD | Adobe Photoshop Document | ✔ | (✔) | Native, Standard | |
| PSB | Adobe Photoshop Large Document | ✔ | - | Native, Standard | ||
| SGI | SGI | Silicon Graphics Image Format | ✔ | - | Standard | |
| TGA | TGA | Truevision TGA Image Format | ✔ | ✔ | Standard | |
| ThumbsDB | Thumbs.db | MS Windows Thumbs DB | ✔ | - | - | OLE2 Compound Document based format only |
| TIFF | TIFF | Aldus/Adobe Tagged Image File Format | ✔ | ✔ | Native, Standard | |
| BigTIFF | ✔ | ✔ | Native, Standard | |||
| WebP | WebP | Google WebP Format | ✔ | - | Standard | |
| XWD | XWD | X11 Window Dump Format | ✔ | - | Standard |
Important note on using Batik: Please read The Apache™ XML Graphics Project - Security, and make sure you use an updated and secure version.
Note that GIF, PNG and WBMP formats are already supported through the ImageIO API, using the JDK standard plugins. For BMP, JPEG, and TIFF formats the TwelveMonkeys plugins provides extended format support and additional features.
Most of the time, all you need to do is simply include the plugins in your project and write:
BufferedImage image = ImageIO.read(file);This will load the first image of the file, entirely into memory.
The basic and simplest form of writing is:
if (!ImageIO.write(image, format, file)) {
// Handle image not written case
}This will write the entire image into a single file, using the default settings for the given format.
The plugins are discovered automatically at run time. See the FAQ for more info on how this mechanism works.
If you need more control of read parameters and the reading process, the common idiom for reading is something like:
// Create input stream (in try-with-resource block to avoid leaks)
try (ImageInputStream input = ImageIO.createImageInputStream(file)) {
// Get the reader
Iterator<ImageReader> readers = ImageIO.getImageReaders(input);
if (!readers.hasNext()) {
throw new IllegalArgumentException("No reader for: " + file);
}
ImageReader reader = readers.next();
try {
reader.setInput(input);
// Optionally, listen for read warnings, progress, etc.
reader.addIIOReadWarningListener(...);
reader.addIIOReadProgressListener(...);
ImageReadParam param = reader.getDefaultReadParam();
// Optionally, control read settings like sub sampling, source region or destination etc.
param.setSourceSubsampling(...);
param.setSourceRegion(...);
param.setDestination(...);
// ...
// Finally read the image, using settings from param
BufferedImage image = reader.read(0, param);
// Optionally, read thumbnails, meta data, etc...
int numThumbs = reader.getNumThumbnails(0);
// ...
}
finally {
// Dispose reader in finally block to avoid memory leaks
reader.dispose();
}
}Query the reader for source image dimensions using reader.getWidth(n) and reader.getHeight(n) without reading the
entire image into memory first.
It's also possible to read multiple images from the same file in a loop, using reader.getNumImages().
If you need more control of write parameters and the writing process, the common idiom for writing is something like:
// Get the writer
Iterator<ImageWriter> writers = ImageIO.getImageWritersByFormatName(format);
if (!writers.hasNext()) {
throw new IllegalArgumentException("No writer for: " + format);
}
ImageWriter writer = writers.next();
try {
// Create output stream (in try-with-resource block to avoid leaks)
try (ImageOutputStream output = ImageIO.createImageOutputStream(file)) {
writer.setOutput(output);
// Optionally, listen to progress, warnings, etc.
ImageWriteParam param = writer.getDefaultWriteParam();
// Optionally, control format specific settings of param (requires casting), or
// control generic write settings like sub sampling, source region, output type etc.
// Optionally, provide thumbnails and image/stream metadata
writer.write(..., new IIOImage(..., image, ...), param);
}
}
finally {
// Dispose writer in finally block to avoid memory leaks
writer.dispose();
}For more advanced usage, and information on how to use the ImageIO API, I suggest you read the Java Image I/O API Guide from Oracle.
import com.twelvemonkeys.imageio.path.Paths;
...
try (ImageInputStream stream = ImageIO.createImageInputStream(new File("image_with_path.jpg")) {
BufferedImage image = Paths.readClipped(stream);
// Do something with the clipped image...
}See Adobe Clipping Path support on the Wiki for more details and example code.
The library comes with a resampling (image resizing) operation, that contains many different algorithms to provide excellent results at reasonable speed.
import com.twelvemonkeys.image.ResampleOp;
...
BufferedImage input = ...; // Image to resample
int width, height = ...; // new width/height
BufferedImageOp resampler = new ResampleOp(width, height, ResampleOp.FILTER_LANCZOS); // A good default filter, see class documentation for more info
BufferedImage output = resampler.filter(input, null);The library comes with a dithering operation, that can be used to convert BufferedImages to IndexColorModel using
Floyd-Steinberg error-diffusion dither.
import com.twelvemonkeys.image.DiffusionDither;
...
BufferedImage input = ...; // Image to dither
BufferedImageOp ditherer = new DiffusionDither();
BufferedImage output = ditherer.filter(input, null);When using the normal patterns for loading images, trying to load a damaged image will result in an IOException being thrown.
BufferedImage image = null;
try {
image = ImageIO.read(file);
} catch (IOException exception) {
// Handle, log a warning/error etc
}In this scenario, if the image is damaged, and ImageIO.read throws an exception, image is still null - it's not possible for a function to both return a value and throw an exception.
However, in some cases it may be possible to get usable image data from a damaged image. The way to do this is use an ImageReadParam to set a BufferedImage as a destination.
int width = reader.getWidth(0);
int height = reader.getHeight(0);
ImageTypeSpecifier imageType = reader.getRawImageType(0);
BufferedImage image = imageType.createBufferedImage(width, height);
ImageReadParam param = reader.getDefaultReadParam();
param.setDestination(image);
try {
reader.read(0, param);
}
catch (IOException e) {
// Handle, log a warning/error etc
}In theory this should work for all plugins, but the result is very much plugin/implementation specific. With some formats and some forms of damaged file, you may get an image that is mostly useful. However, you should be prepared for the possibility this just gives a blank or empty image.
Download the project (using Git):
$ git clone [email protected]:haraldk/TwelveMonkeys.git
This should create a folder named TwelveMonkeys in your current directory. Change directory to the TwelveMonkeys
folder, and issue the command below to build.
Build the project (using Maven):
$ mvn package
Currently, the recommended JDK for making a build is Oracle JDK 8.x.
It's possible to build using OpenJDK, but some tests might fail due to some minor differences between the color management systems used. You will need to either disable the tests in question, or build without tests altogether.
Because the unit tests needs quite a bit of memory to run, you might have to set the environment variable MAVEN_OPTS
to give the Java process that runs Maven more memory. I suggest something like -Xmx512m -XX:MaxPermSize=256m.
Optionally, you can install the project in your local Maven repository using:
$ mvn install
To install the plug-ins, either use Maven and add the necessary dependencies to your project, or manually add the needed JARs along with required dependencies in class-path.
The ImageIO registry and service lookup mechanism will make sure the plugins are available for use.
To verify that the JPEG plugin is installed and used at run-time, you could use the following code:
Iterator<ImageReader> readers = ImageIO.getImageReadersByFormatName("JPEG");
while (readers.hasNext()) {
System.out.println("reader: " + readers.next());
}The first line should print:
reader: com.twelvemonkeys.imageio.plugins.jpeg.JPEGImageReader@somehash
To depend on the JPEG and TIFF plugin using Maven, add the following to your POM:
...
<dependencies>
...
<dependency>
<groupId>com.twelvemonkeys.imageio</groupId>
<artifactId>imageio-jpeg</artifactId>
<version>3.12.0</version>
</dependency>
<dependency>
<groupId>com.twelvemonkeys.imageio</groupId>
<artifactId>imageio-tiff</artifactId>
<version>3.12.0</version>
</dependency>
<!--
Optional dependency. Needed only if you deploy ImageIO plugins as part of a web app.
Make sure you add the IIOProviderContextListener to your web.xml, see above.
-->
<dependency>
<groupId>com.twelvemonkeys.servlet</groupId>
<artifactId>servlet</artifactId>
<version>3.12.0</version>
</dependency>
<!--
Or Jakarta version, for Servlet API 5.0
-->
<dependency>
<groupId>com.twelvemonkeys.servlet</groupId>
<artifactId>servlet</artifactId>
<version>3.12.0</version>
<classifier>jakarta</classifier>
</dependency>
</dependencies>To depend on the JPEG and TIFF plugin in your IDE or program, add all of the following JARs to your class path:
twelvemonkeys-common-lang-3.12.0.jar
twelvemonkeys-common-io-3.12.0.jar
twelvemonkeys-common-image-3.12.0.jar
twelvemonkeys-imageio-core-3.12.0.jar
twelvemonkeys-imageio-metadata-3.12.0.jar
twelvemonkeys-imageio-jpeg-3.12.0.jar
twelvemonkeys-imageio-tiff-3.12.0.jar
Because the ImageIO plugin registry (the IIORegistry) is "VM global", it does not work well with
servlet contexts as-is. This is especially evident if you load plugins from the WEB-INF/lib or classes folder.
Unless you add ImageIO.scanForPlugins() somewhere in your code, the plugins might never be available at all.
In addition, servlet contexts dynamically loads and unloads classes (using a new class loader per context).
If you restart your application, old classes will by default remain in memory forever (because the next time
scanForPlugins is called, it's another ClassLoader that scans/loads classes, and thus they will be new instances
in the registry). If a read is attempted using one of the remaining "old" readers, weird exceptions
(like NullPointerExceptions when accessing static final initialized fields or NoClassDefFoundErrors
for uninitialized inner classes) may occur.
To work around both the discovery problem and the resource leak,
it is strongly recommended to use the IIOProviderContextListener that implements
dynamic loading and unloading of ImageIO plugins for web applications.
<web-app ...>
...
<listener>
<display-name>ImageIO service provider loader/unloader</display-name>
<listener-class>com.twelvemonkeys.servlet.image.IIOProviderContextListener</listener-class>
</listener>
...
</web-app>Loading plugins from WEB-INF/lib without the context listener installed is unsupported and will not work correctly.
The context listener has no dependencies to the TwelveMonkeys ImageIO plugins, and may be used with JAI ImageIO or other ImageIO plugins as well.
Another safe option, is to place the JAR files in the application server's shared or common lib folder.
For those transitioning from the old javax.servlet to the new jakarta.servlet package, there is a separate
dependency available. It contains exactly the same servlet classes as mentioned above, but built against the new Jakarta EE
packages. The dependency has the same group name and identifier as before, but a jakarta classifier appended, to
distinguish it from the non-Jakarta package.
See the Maven dependency example for how to enable it with Maven. Gradle or other build tools will have similar options.
The recommended way to use the plugins, is just to include the JARs as-is in your project, through a Maven dependency or similar. Re-packaging is not necessary to use the library, and not recommended.
However, if you like to create a "fat"
JAR, or otherwise like to re-package the JARs for some reason, it's important to remember that automatic discovery of
the plugins by ImageIO depends on the
Service Provider Interface (SPI) mechanism.
In short, each JAR contains a special folder, named META-INF/services containing one or more files,
typically javax.imageio.spi.ImageReaderSpi and javax.imageio.spi.ImageWriterSpi.
These files exist with the same name in every JAR,
so if you simply unpack everything to a single folder or create a JAR, files will be overwritten and behavior be
unspecified (most likely you will end up with a single plugin being installed).
The solution is to make sure all files with the same name, are merged to a single file, containing all the SPI information of each type. If using the Maven Shade plugin, you should use the ServicesResourceTransformer to properly merge these files. You may also want to use the ManifestResourceTransforme to get the correct vendor name, version info etc. Other "fat" JAR bundlers will probably have similar mechanisms to merge entries with the same name.
The latest version that will run on Java 7 is 3.9.4. Later versions will require Java 8 or later.
Common dependencies
ImageIO dependencies
ImageIO plugins
- imageio-bmp-3.12.0.jar
- imageio-dds-3.12.0.jar
- imageio-hdr-3.12.0.jar
- imageio-icns-3.12.0.jar
- imageio-iff-3.12.0.jar
- imageio-jpeg-3.12.0.jar
- imageio-pcx-3.12.0.jar
- imageio-pict-3.12.0.jar
- imageio-pnm-3.12.0.jar
- imageio-psd-3.12.0.jar
- imageio-sgi-3.12.0.jar
- imageio-tga-3.12.0.jar
- imageio-thumbsdb-3.12.0.jar
- imageio-tiff-3.12.0.jar
- imageio-webp-3.12.0.jar
- imageio-xwd-3.12.0.jar
ImageIO plugins requiring 3rd party libs
Photoshop Path support for ImageIO
Servlet support
- servlet-3.12.0.jar for legacy Java EE (javax.servlet)
- servlet-3.12.0-jakarta.jar for Jakarta EE (jakarta.servlet)
This project is provided under the OSI approved BSD license:
Copyright (c) 2008-2022, Harald Kuhr
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
o Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.
o Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
o Neither the name of the copyright holder nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
q: How do I use it?
a: The easiest way is to build your own project using Maven, Gradle or other build tool with dependency management, and just add dependencies to the specific plug-ins you need. If you don't use such a build tool, make sure you have all the necessary JARs in classpath. See the Install section above.
q: What changes do I have to make to my code in order to use the plug-ins?
a: The short answer is: None. For basic usage, like ImageIO.read(...) or ImageIO.getImageReaders(...), there is no need
to change your code. Most of the functionality is available through standard ImageIO APIs, and great care has been taken
not to introduce extra API where none is necessary.
Should you want to use very specific/advanced features of some of the formats, you might have to use specific APIs, like setting base URL for an SVG image that consists of multiple files, or controlling the output compression of a TIFF file.
q: How does it work?
a: The TwelveMonkeys ImageIO project contains plug-ins for ImageIO. ImageIO uses a service lookup mechanism, to discover plug-ins at runtime.
All you have to do, is to make sure you have the TwelveMonkeys ImageIO JARs in your classpath.
You can read more about the registry and the lookup mechanism in the IIORegistry API doc.
The fine print: The TwelveMonkeys service providers for JPEG, BMP and TIFF, overrides the onRegistration method, and
utilizes the pairwise partial ordering mechanism of the IIOServiceRegistry to make sure it is installed before
the Sun/Oracle provided JPEGImageReader, BMPImageReader TIFFImageReader, and the Apple provided TIFFImageReader on OS X,
respectively. Using the pairwise ordering will not remove any functionality form these implementations, but in most
cases you'll end up using the TwelveMonkeys plug-ins instead.
q: Why is there no support for common formats like GIF or PNG?
a: The short answer is simply that the built-in support in ImageIO for these formats are considered good enough as-is. If you are looking for better PNG write performance on Java 7 and 8, see JDK9 PNG Writer Backport.
q: When is the next release? What is the current release schedule?
a: The goal is to make monthly releases, containing bug fixes and minor new features. And quarterly releases with more "major" features.
q: I love this project! How can I help?
a: Have a look at the open issues, and see if there are any issues you can help fix, or provide sample file or create test cases for. It is also possible for you or your organization to become a sponsor, through GitHub Sponsors. Providing funding will allow us to spend more time on fixing bugs and implementing new features.
q: What about JAI? Several of the formats are already supported by JAI.
a: While JAI (and jai-imageio in particular) have support for some of the same formats, JAI has some major issues. The most obvious being:
- It's not actively developed. No issue has been fixed for years.
- To get full format support, you need native libs. Native libs does not exist for several popular platforms/architectures, and further the native libs are not open source. Some environments may also prevent deployment of native libs, which brings us back to square one.
q: What about JMagick or IM4Java? Can't you just use what's already available?
a: While great libraries with a wide range of formats support, the ImageMagick-based libraries has some disadvantages compared to ImageIO.
- No real stream support, these libraries only work with files.
- No easy access to pixel data through standard Java2D/BufferedImage API.
- Not a pure Java solution, requires system specific native libs.
We did it