How did this happen? Well you have ever needed to read or write any images in Java, you have probably come across the Java Advanced Imaging (JAI) API and the ImageIO class. Here at IDRsolutions we originally used ImageIO and JAI when working with image file formats. But we noticed that we were getting less than satisfactory results.
What is JDeli?
Back in 2015, we decided to move away from using ImageIO and JAI, and released our own image library: JDeli. JDeli has a high level of support for images and wide range of image support. JDeli is a library created by IDRSolutions which fixes some to most of the bugs which can be found in ImageIO and JAI and adds support for other image formats.
How did we make the comparisons on the speed?
We were curious to see how JDeli performed against ImageIO and JAI. Therefore we decided to run some tests to compare how long it took to read and write several different file types.
How did we make it a fair test?
Every test was carried out on the same Windows machine, using the same sample of image files where the file type was supported. The times given are the time it took to read or write all of the relevant image files in the directories.
To ensure a fair test we discounted the following image formats: WebP, Dicom, PSD, SGI. These formats can be read with JDeli but are not supported by ImageIO or JAI and therefore have not been included in these tests.
How did we run these tests?
To begin with we tested ImageIO against JDeli using our first directory which contained the following file types:
Once those tests were completed we knew we would have to create a second directory with different files because ImageIO is not capable of decoding file types such as TIFF and JPEG2000.
Our second file directory contained the following file types:
ImageIO / JAI vs JDeli
Before running the tests, I was unsure which would be faster. JDeli was created as a superior alternative to ImageIO and JAI, but this was the first time I had made a full set of tests to find a definitive answer. I would however expect JDeli to be slower when writing JPeg files, as it uses native calls.
Speed is an important factor to consider when choosing an image library, especially if you are decoding or encoding a large number of files. However other important considerations include what file types are available. For example JDeli does not currently have support for writing JPeg2000 files, but ImageIO and JAI do not support reading WebP, Dicom, PSD, or SGI. Other factors to consider are pricing and the support available. What you see as the “best” image library depends on your criteria.
The results from our test are given in seconds and are the time it took for all of the 50 image files in the directories to be read or written.
All of the file formats were tested with ImageIO, but TIFF and JPEG2000 files also require JAI and therefore the results are in a separate column.
|File types||Number of file||ImageIO||ImageIO/JAI||JDeli|
These results show that our software, JDeli, performed the best with PNGs, BMPs, TIFFs and JPeg2000s. However with JPegs, ImageIO was faster. This could be due to the fact that ImageIO uses native calls. However as an overall result JDeli proved to be the quickest in comparison to to ImageIO and JAI. It also manages to fix some bugs. For example, when reading Tiff files I found that lots of the more complex files threw Illegal Argument Exceptions when I tried to read them using ImageIO and JAI. In the interests of fairness I removed them from the tests and replaced them with images which both libraries were able to read.
These results confirm that, in terms of speed, JDeli is overall a better image library. As I mentioned above, “better” is not necessarily just about speed. JDeli also fixes some of the problems with ImageIO, examples of which can be found in our previous blog article on what JDeli offers.
Feel free to try out the tests for yourself as there is a trial download of the JDeli image library you can use.
Start reading and writing images with one line of code
BufferedImage image = JDeli.read(streamOrFile);
JDeli.write(myBufferedImage, OutputFormat.HEIC, outputStreamOrFile)