| TurboJPEG/OSS Java Wrapper |
| ========================== |
| |
| TurboJPEG/OSS can optionally be built with a Java Native Interface wrapper, |
| which allows the TurboJPEG/OSS dynamic library to be loaded and used directly |
| from Java applications. The Java front end for this is defined in several |
| classes located under org/libjpegturbo/turbojpeg. The source code for these |
| Java classes is licensed under a BSD-style license, so the files can be |
| incorporated directly into both open source and proprietary projects without |
| restriction. A Java archive (JAR) file containing these classes is also |
| shipped with the "official" distribution packages of libjpeg-turbo. |
| |
| TJExample.java, which should also be located in the same directory as this |
| README file, demonstrates how to use the TurboJPEG/OSS Java front end to |
| compress and decompress JPEG images in memory. |
| |
| |
| Performance Pitfalls |
| -------------------- |
| |
| The TurboJPEG Java front end defines several convenience methods that can |
| allocate image buffers or instantiate classes to hold the result of compress, |
| decompress, or transform operations. However, if you use these methods, then |
| be mindful of the amount of new data you are creating on the heap. It may be |
| necessary to manually invoke the garbage collector to prevent heap exhaustion |
| or to prevent performance degradation. Background garbage collection can kill |
| performance, particularly in a multi-threaded environment (Java pauses all |
| threads when the GC runs.) |
| |
| The Java front end always gives you the option of pre-allocating your own |
| source and destination buffers, which allows you to re-use these buffers for |
| compressing/decompressing multiple images. If the image sequence you are |
| compressing or decompressing consists of images of the same size, then |
| pre-allocating the buffers is recommended. |
| |
| |
| Note for OS X users |
| ------------------- |
| |
| /usr/lib, the directory under which libturbojpeg.dylib is installed on Mac |
| systems, is not part of the normal Java library path. Thus, when running a |
| Java application that uses TurboJPEG/OSS on Mac systems, you will need to pass |
| an argument of -Djava.library.path=/usr/lib to java. |
| |
| |
| Note for Solaris users |
| ---------------------- |
| |
| /opt/libjpeg-turbo/lib, the directory under which libturbojpeg.so is installed |
| on Solaris systems, is not part of the normal Java library path. Thus, when |
| running a Java application that uses TurboJPEG/OSS on Solaris systems, you will |
| need to pass an argument of -Djava.library.path=/opt/libjpeg-turbo/lib to java. |
| If using a 64-bit data model, then instead pass an argument of |
| -Djava.library.path=/opt/libjpeg-turbo/lib/amd64 to use the 64-bit version of |
| libturbojpeg.so. |
