Proposing Efficient Memory Based ImageIO ImageInputStream
Fabian Lange
lange.fabian at gmail.com
Fri Oct 26 05:47:22 PDT 2012
Hi all,
this is my first message to this group, so please be gentle. I tried to
follow the contributers guide :)
While writing code that does lots of image manipulation, I noticed that
there is no implementation in the standard Java ImageIO libs that allows
parsing/reading images directly from memory.
ImageIO uses implementations of ImageInputStream. Because of its nature of
streams, you cannot re-read bytes. But this is something the parsers need
to do, to find out if they support the image (they basically read the
header bytes).
So there are two Implementations that allow this:
* FileCacheImageInputStream
* MemoryCacheImageInputStream
FileCache is obviously a bad choice for high performance. It involves disc
I/O that might not be acceptable in some cases.
MemoryCache sounds better, but the implementation is designed for a case
where you consume an actual InputStream. It involves some re-reading and
System.arraycopy.
However a common use case is the following.
"I do already have a byte[] in memory, which contains the image data, and I
want to manipulate it."
I think this is common, because not only I did it so far every time I used
ImageIO, but also Google searches reveal that it is a common question.
To do this, one would today create a ByteArrayInputStream and would pass it
to ImageIO. But then ImageIO would read it and write it to one of the
caches.
My proposed ImageInputStream class is very simple, and it reuses some code
from MemoryCacheImageInputStream.
It can be constructed by passing in a byte[] and this byte array is then
reused by ImageIO directly, without any caching overhead.
While I did benchmarks (i was actually led to implement this by profiling),
I don't think that it is worth to discuss the numbers.
It is clear that this implementation is superior to the other two when the
byte[] is available.
I really would have liked to write unit tests for this class, but I was
unable to find any existing infrastructure for similar ImageIO
functionality where I could plug it in.
So, do you think this would be a good addition to ImageIO? Who would be
willing to work with me to integrate the code? (I signed the OCA)
Fabian
More information about the jdk8-dev
mailing list