Apache Commons Imaging Alternative for Java: JDeli

If you’ve used Apache Commons Imaging, it was probably to pull EXIF out of a JPEG or edit some XMP. That’s what it’s good at, and it does it well: reads EXIF, IPTC, and XMP straight out of your files without re-encoding anything, free and pure Java. We see it go wrong when a team wires it in as their general image library and then discovers it can’t write a JPEG, only reads a narrow slice of JPEGs to begin with.

I want to compare it here with JDeli, our own image library, on the ground that actually matters for image processing: which formats you can read and write, how fast each one runs on the same set of test images, and which tool earns a place in which job. Both are pure Java, and for plenty of projects the sensible setup uses both.

What Is Apache Commons Imaging?

Apache Commons Imaging is a pure-Java image library from the Apache Commons project, and you may know it by its old name, Sanselan. Their latest version was released in the year 2025. The API is modeled on ImageIO: static calls on an Imaging class, Imaging.getBufferedImage() to read and Imaging.writeImage() to write. The library runs on the Apache 2.0 license with no native dependencies and runs on Java 8.

Two things are worth knowing before you commit to it. It’s still in alpha, the current release being 1.0.0-alpha6, and the project has been going under one name or another since 2007 without ever cutting a stable 1.0. And it leans toward metadata rather than image encoding, which the format table makes obvious.

What Is JDeli?

JDeli is our commercial pure-Java image library. It supports 16+ formats, including AVIF, BMP, DICOM, EMF, GIF, HEIC, JPEG, JPEG 2000, JPEG XL, PNG, PSD, SGI, TIFF, WebP, and WMF, with no native code and no third-party dependencies.

You read with JDeli.read() and write with JDeli.write(), it needs Java 17 or later, and it comes with a processing API for things like crop, resize, rotate, and watermark. The formats Commons Imaging never picked up, the modern ones coming off phones and out of browsers and medical scanners, are the ones we built JDeli around.

Format Coverage

The gap here is wide and it runs both ways. Commons Imaging reads and writes a decent spread of older raster formats, but it has no modern format support and can’t write JPEG. JDeli covers the modern formats but skips some of the older niche ones (PCX, the X pixmap family) that Commons Imaging still handles.

The JPEG row catches people out. Commons Imaging’s own documentation says its JPEG reader handles only simple grayscale and YCbCr baseline sequential images, 8 bits per component, Huffman encoded, with no RST markers, and it won’t write JPEG at all. For a format that common, that alone keeps it out of most real pipelines.

Commons Imaging also reads and writes a set of formats we never targeted, including PCX/DCX, ICNS, ICO/CUR, PNM/PGM/PBM/PPM, WBMP, XBM, and XPM, and it reads HDR.

Both handle the usual TIFF compression schemes (LZW, Deflate, PackBits, CCITT). The difference is JPEG-compressed TIFF, which Commons Imaging doesn’t do and JDeli does.

Metadata: Where Commons Imaging Wins

Commons Imaging is better suited to metadata work. It reads and writes EXIF on JPEG and TIFF without re-encoding the image, reads IPTC, and reads and writes XMP across GIF, JPEG, PNG, PSD, and TIFF. Editing EXIF in place, leaving the pixels untouched, is exactly what it was built for.

Reading metadata is a one-liner:

final ImageMetadata metadata = Imaging.getMetadata(new File("photo.jpg"));
System.out.println(metadata);

Say you’re auditing camera EXIF, or stripping GPS data before images go public, or rewriting copyright fields across a whole library. JDeli is a codec and processing library, and can read metadata, however it is limited in regard to metadata as a whole.

Benchmarks

These come from our performance comparison page, run with JMH. The write tests use a shared set of 166 images, the read tests run over a smaller set. Scores are operations per second, so higher wins.

The write tables also show how many files each library failed to produce readable output for, the average output size, and SSIM, which measures how close the output is to the original (1.0 being a perfect match). Commons Imaging only appears where it can actually do the work, so you won’t see it in the JPEG, JPEG 2000, or WebP tables.

It holds up fine on the formats it supports, and it beats us on GIF write. We’re ahead on every read test and most writes, and on BMP we produce cleaner output.

BMP

Reading:

Writing:

GIF

Reading:

Writing:

Commons Imaging takes GIF write on both speed and fidelity. Neither of us optimizes heavily for GIF, but on this one Apache is the better writer.

PNG

Reading:

Writing (default modes shown; JDeli also offers fast and quantized modes):

PNG read comes in around 1.9x faster for JDeli. On write the default speeds are neck and neck, though we hold a perfect SSIM where Apache lands at 0.967, and our fast mode is about 2.5x quicker again if you care more about throughput than a few kilobytes.

TIFF

Reading:

Writing (JDeli offers several compression modes; Apache uses a single default):

TIFF read is about 1.7x faster for JDeli. On write, both hit lossless quality on the Deflate and LZW modes that line up, with JDeli faster. We also offer JPEG-compressed TIFF, which Commons Imaging can’t produce, handy when you’d trade some fidelity for a much smaller file.

API Comparison

Both APIs are static-method designs in the ImageIO mold, so neither should feel foreign.

Commons Imaging reads into a BufferedImage and writes with an explicit format enum plus a parameter map:

BufferedImage image = Imaging.getBufferedImage(new File("input.png"));
Imaging.writeImage(image, new File("output.bmp"), ImageFormats.BMP);

That trailing null is the optional parameter map. For resizing or rotating or cropping you’re back on Graphics2D, same as plain ImageIO.

JDeli reads and writes the same way, and adds a processing chain so a transform happens in the same pass:

BufferedImage image = JDeli.read(new File("input.png"));
JDeli.write(image, "bmp", new File("output.bmp"));

To resize during a conversion, build an ImageProcessingOperations and pass it to JDeli.convert():

ImageProcessingOperations operations = new ImageProcessingOperations();
operations.scale(1.2);
JDeli.convert(new File("input.tiff"), new File("output.webp"), operations);

The scale factor is a double. convert() also takes InputStream/OutputStream and byte[], so the same code works in a servlet or a cloud function where you never see a file handle.

Production Considerations

Both libraries are pure Java, so you avoid the native memory trouble and JVM crashes that come with ImageIO’s native JPEG/TIFF code or with JAI. This becomes crucial in a commercial setting where costs could add up further down the line.

It’s worth noting that Commons Imaging has never shipped a stable release, a permanent alpha states can become a procurement headache for developer teams. Support for Commons Imaging is provided through the Apache mailing lists and issue tracker, whereas JDeli has a dedicated support team which originally developed the java image library.

When to Use Which

Reach for Apache Commons Imaging when the job is metadata: reading EXIF, editing it in place, rewriting XMP or IPTC without re-encoding. It’s also a fair free pick if you specifically need one of the older formats it writes, like PCX or the X pixmaps or WBMP, and you don’t need JPEG or anything modern. Apache makes the metadata case in more detail if you want their take before deciding.

Reach for JDeli when the job is the image itself: reading and writing JPEG, decoding or encoding HEIC, AVIF, WebP, or JPEG 2000, converting between formats, resizing and transforming at speed. It’s also your only option of the two the moment JPEG output is involved, since Commons Imaging can’t write it, or when the alpha status and volunteer support model won’t fly for production.

Running both is common and sensible: Commons Imaging pulls the metadata, JDeli does the decode and encode. If you go that way, disclosure: JDeli is our product, and we’d genuinely rather you benchmark it against Commons Imaging on your own images than take my word for any of the above.

Getting Started

Apache Commons Imaging, from Maven Central:

<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-imaging</artifactId>
    <version>1.0.0-alpha6</version>
</dependency>

JDeli is served from the IDRsolutions repository and needs your trial or license credentials:

<repositories>
    <repository>
        <id>IDRsolutions</id>
        <name>IDR Solutions</name>
        <url>https://maven.idrsolutions.com</url>
    </repository>
</repositories>
<dependencies>
    <dependency>
        <groupId>com.idrsolutions</groupId>
        <artifactId>jdeli</artifactId>
        <version>2025.05</version>
    </dependency>
</dependencies>

BufferedImage image = JDeli.read(new File("photo.heic"));
JDeli.write(image, "webp", new File("output.webp"));

Frequently Asked Questions

How do I read a HEIC or WebP file that Commons Imaging can’t open?

Commons Imaging has no decoder for either, so ImageIO won’t help through it. With JDeli it’s a single call: BufferedImage image = JDeli.read(new File("photo.heic")); and the same works for WebP, AVIF, JPEG 2000, and JPEG XL. If you’re tied to the ImageIO API, JDeli’s ImageIO plugin registers HEIC and AVIF so ImageIO.read() picks them up without a code change.

Can I use Commons Imaging and JDeli in the same project?

Yes, and it’s a reasonable setup. They’re separate libraries with no shared classes, so there’s no conflict on the classpath. A common split is Commons Imaging for reading and writing metadata and JDeli for decoding, encoding, and format conversion. You call each directly rather than through a shared registry, so there’s nothing to configure.

Can JDeli read or edit image metadata like Commons Imaging does?

JDeli exposes some metadata during decode, but it isn’t built for in-place EXIF or XMP editing the way Commons Imaging is. If your job is rewriting metadata without re-encoding the pixels, Commons Imaging is the better fit. If you’re decoding and re-encoding anyway, JDeli handles the image and you can carry metadata across as part of that pipeline.

// Read an image
BufferedImage bufferedImage = JDeli.read(avifImageFile);

// Write an image
JDeli.write(bufferedImage, "avif", outputStreamOrFile);

// Read an image
BufferedImage bufferedImage = JDeli.read(dicomImageFile);

// Read an image
BufferedImage bufferedImage = JDeli.read(heicImageFile);

// Write an image
JDeli.write(bufferedImage, "heic", outputStreamOrFile);

// Read an image
BufferedImage bufferedImage = JDeli.read(jpegImageFile);

// Write an image
JDeli.write(bufferedImage, "jpeg", outputStreamOrFile);

// Read an image
BufferedImage bufferedImage = JDeli.read(jpeg2000ImageFile);

// Write an image
JDeli.write(bufferedImage, "jpx", outputStreamOrFile);

// Write an image
JDeli.write(bufferedImage, "pdf", outputStreamOrFile);

// Read an image
BufferedImage bufferedImage = JDeli.read(pngImageFile);

// Write an image
JDeli.write(bufferedImage, "png", outputStreamOrFile);

// Read an image
BufferedImage bufferedImage = JDeli.read(tiffImageFile);

// Write an image
JDeli.write(bufferedImage, "tiff", outputStreamOrFile);

// Read an image
BufferedImage bufferedImage = JDeli.read(webpImageFile);

// Write an image
JDeli.write(bufferedImage, "webp", outputStreamOrFile);