A very long-standing beef with Java has been its implmenetation of image handling routines. In a word - loading an image of any decent size in Java just plain sucks. One outstanding complaint has been the lack of file formats supported. The other, usually only from the high-end community has been that they are very slow and take up way more memory than they should. The aim of this library is to fix this situation.
The original library was developed as part of my work with an earlier employer. As it was non-essential to the application I convinced them to release the code as Open Source software. Therefore the copyright is owned jointly by myself and ADI Ltd (now part of the great Thomson conglomerate). I've put a lot of effort into developing new parts of the system since the original release so slowly replacing the ADI copyrighted code.
The code can be used as standalone loaders, but they are intended to be used
as part of the URL content handler system. When you request a
java.net.URL object to getContent() this will return
an java.awt.BufferedImage object to you.
One minor drawback of the current implementation is that it does not support the
ImageProducer interface and is therefore not capable of working
within the standard java.awt.Toolkit framework. Work is underway
to fix this.
In the 1.0 version of the code, the native DLL was compiled as a single static file - complete with all of the image libraries. In this new version, it will use whatever DLLs are already installed on your system. For unix users, that means using libjpeg et al from /lib or /usr/lib. For Windows users, you don't have this sort of system, so there are a collection of DLLs and the needed header files available here. You do not need these if you are compiling on any unix platform. If you would like to download the latest versions of these libraries then have a look at the MinGW project on SourceForge. That's where we got the above libraries from. To use these and compile the codebase, extract the zip file into the src/native directory. It should place them in the correct directories (src/native/dll and src/native/include).
Previous development versions required a custom compiled version of libTIFF, but that has been eliminated now. In addition, a lot of work has gone into the make system so that you should now be able to compile it with minimal effort for both cygwin and any form of unix with the GNU utilities installed. The latest beta is now available for testing. Download below!
Many thanks to Rob Nielsen for doing this work!
Last Stable Version: 1.0
CVSROOT: :pserver:anonymous@case.vlc.com.au:/home/cvs/code/cvsroot
No password is needed.
CVS Module Name: imageloader
CVS Stable Tag: 1-0-FINAL
Prebuilt software
These files include a prebuilt JAR file and the Win32 DLL. For unix users, you
will currently need to build the native code portion yourself.
| Platform | File type | Download type |
|---|---|---|
| Version 1.0.1 | ||
| Win32 | Zip | FTP HTTP (185917 bytes) |
| TAR Gzip | HTTP (186362 bytes) | |
| Version 1.1 beta 1 | ||
| Javadoc | Zip | HTTP (76955 bytes) |
| Win32 | Zip | HTTP (265859 bytes - includes all DLLS) |
| Linux | TAR Gzip | HTTP (31568 bytes) |
| Zip | HTTP (31058 bytes) | |
ContentHandler
interface. The most detailed documentation is available in the javadoc for
java.net.ContentHandler. The simplest way to make use of these
is to set the system property java.net.content.handler.pkgs to
the name of the package that contains this code. If you are using the 1.0
library, that is "vlc.content" if you are using the 1.0.1 version. If you
are using the CVS code or 1.1beta or later, then it would
be "vlc.net.content". Note that you need to set this before you try
to load the image, not after it. If you do not set this, you will get an
instance of Sun's ImageProducer internal implementation.