| DRC | 279bd34 | 2011-04-02 05:17:12 +0000 | [diff] [blame] | 1 | TurboJPEG/OSS Java Wrapper |
| 2 | ========================== |
| DRC | f8e0055 | 2011-02-04 11:06:36 +0000 | [diff] [blame] | 3 | |
| 4 | TurboJPEG/OSS can optionally be built with a Java Native Interface wrapper, |
| 5 | which allows the TurboJPEG/OSS dynamic library to be loaded and used directly |
| DRC | c5a4199 | 2011-02-08 06:54:36 +0000 | [diff] [blame] | 6 | from Java applications. The Java front end for this is defined in several |
| 7 | classes located under org/libjpegturbo/turbojpeg. The source code for these |
| 8 | Java classes is licensed under a BSD-style license, so the files can be |
| DRC | f8e0055 | 2011-02-04 11:06:36 +0000 | [diff] [blame] | 9 | incorporated directly into both open source and proprietary projects without |
| DRC | 279bd34 | 2011-04-02 05:17:12 +0000 | [diff] [blame] | 10 | restriction. A Java archive (JAR) file containing these classes is also |
| 11 | shipped with the "official" distribution packages of libjpeg-turbo. |
| DRC | f8e0055 | 2011-02-04 11:06:36 +0000 | [diff] [blame] | 12 | |
| DRC | 2413cb8 | 2011-02-08 02:11:37 +0000 | [diff] [blame] | 13 | TJExample.java, which should also be located in the same directory as this |
| DRC | f8e0055 | 2011-02-04 11:06:36 +0000 | [diff] [blame] | 14 | README file, demonstrates how to use the TurboJPEG/OSS Java front end to |
| 15 | compress and decompress JPEG images in memory. |
| 16 | |
| DRC | f8e0055 | 2011-02-04 11:06:36 +0000 | [diff] [blame] | 17 | |
| DRC | 7c99822 | 2011-03-10 07:25:41 +0000 | [diff] [blame] | 18 | Performance Pitfalls |
| 19 | -------------------- |
| 20 | |
| DRC | 80803ae | 2011-12-15 13:12:59 +0000 | [diff] [blame] | 21 | The TurboJPEG Java front end defines several convenience methods that can |
| DRC | 7c99822 | 2011-03-10 07:25:41 +0000 | [diff] [blame] | 22 | allocate image buffers or instantiate classes to hold the result of compress, |
| 23 | decompress, or transform operations. However, if you use these methods, then |
| 24 | be mindful of the amount of new data you are creating on the heap. It may be |
| 25 | necessary to manually invoke the garbage collector to prevent heap exhaustion |
| 26 | or to prevent performance degradation. Background garbage collection can kill |
| 27 | performance, particularly in a multi-threaded environment (Java pauses all |
| 28 | threads when the GC runs.) |
| 29 | |
| 30 | The Java front end always gives you the option of pre-allocating your own |
| 31 | source and destination buffers, which allows you to re-use these buffers for |
| 32 | compressing/decompressing multiple images. If the image sequence you are |
| 33 | compressing or decompressing consists of images of the same size, then |
| 34 | pre-allocating the buffers is recommended. |
| 35 | |
| 36 | |
| DRC | f8e0055 | 2011-02-04 11:06:36 +0000 | [diff] [blame] | 37 | Note for OS X users |
| 38 | ------------------- |
| 39 | |
| 40 | /usr/lib, the directory under which libturbojpeg.dylib is installed on Mac |
| 41 | systems, is not part of the normal Java library path. Thus, when running a |
| 42 | Java application that uses TurboJPEG/OSS on Mac systems, you will need to pass |
| 43 | an argument of -Djava.library.path=/usr/lib to java. |
| DRC | ed6526f | 2011-02-05 05:41:18 +0000 | [diff] [blame] | 44 | |
| 45 | |
| 46 | Note for Solaris users |
| 47 | ---------------------- |
| 48 | |
| 49 | /opt/libjpeg-turbo/lib, the directory under which libturbojpeg.so is installed |
| 50 | on Solaris systems, is not part of the normal Java library path. Thus, when |
| 51 | running a Java application that uses TurboJPEG/OSS on Solaris systems, you will |
| 52 | need to pass an argument of -Djava.library.path=/opt/libjpeg-turbo/lib to java. |
| 53 | If using a 64-bit data model, then instead pass an argument of |
| 54 | -Djava.library.path=/opt/libjpeg-turbo/lib/amd64 to use the 64-bit version of |
| 55 | libturbojpeg.so. |