commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Lucas <gwlu...@sonalysts.com>
Subject [Apache Commons Imaging] Seeking ideas for performance improvements
Date Fri, 08 Jun 2012 19:54:33 GMT
I am making this post to the developers mailing list to see if anyone has ideas about areas
in the Apache Commons Imaging project that would benefit from performance enhancements.  Last
year, I had a requirement through my job to support TIFF images in Java.  I selected the Apache
Imaging package (which was called Sanselan at the time) because it offered a pure Java solution
and avoided the hassles associated with the Java Advanced Imaging add-on.   Since then, I've
put in some of my own time polishing up the image-reading operations to improve the speed
of rendering.   I've had some success and was wondering if there were other file formats supported
by Apache Imaging that might benefit from similar attention.   Of course, the situation for
TIFF is a little different from that of the more mainstream formats such as JPEG, PNG, and
GIF which are directly supported by image ImageIO.    I'd be less inclined to work on formats
that already have good support, but if there were special requirements that could be addressed
through Apache Imaging I'd be willing to take a look at them.
 
Just to give a sense of what's possible, consider the speed improvements to the TIFF format.
This morning, I used a test application called ApacheImagingSpeedAndMemory from the Apache
Imaging code distribution to run time trials on the original Sanselan 0.97 incubation version
of Apache Imaging and the lastest code trunk.  For a largish 10,000 by 10,000 pixel image,
the original version required 15.9 seconds and used 679.8 megabytes of memory to load the
image.  The new version required 1.9 seconds and used 383.2 megabytes.   For a smaller 3,600-by-1,800
pixel image, the load times were reduced from 0.89 seconds to 0.095.    I wish I could say
that I did something really cool to get these improvements, but the truth is that it was just
old-fashioned coding and recognizing areas where redundant processing could be avoided.
 
 
Anyway, I don't have a huge amount of free time to throw at this project, but if anyone comes
up with an interesting idea, I might be willing to give it a shot. 
 
Gary
 
 
 
 
Computer Programming is the Art of the Possible
Gary W. Lucas, Senior Software Engineer
Sonalysts, Inc.
215 Parkway North
Waterford, CT 06385
(860) 326-3682
41-22-12.35 N / 72-10-07.54 W  (USNG/MGRS:  18T YL 36787 83711)
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message