| DRC | f8e0055 | 2011-02-04 11:06:36 +0000 | [diff] [blame] | 1 | TurboJPEG/OSS JNI Wrapper |
| 2 | ========================= |
| 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 |
| 6 | from Java applications. The Java front end for this is defined in |
| DRC | 2413cb8 | 2011-02-08 02:11:37 +0000 | [diff] [blame^] | 7 | TurboJPEG.java, which should be located in the same directory as this README |
| 8 | file. TurboJPEG.java is licensed under a BSD-style license, so it can be |
| DRC | f8e0055 | 2011-02-04 11:06:36 +0000 | [diff] [blame] | 9 | incorporated directly into both open source and proprietary projects without |
| 10 | restriction. |
| 11 | |
| DRC | 2413cb8 | 2011-02-08 02:11:37 +0000 | [diff] [blame^] | 12 | TJExample.java, which should also be located in the same directory as this |
| DRC | f8e0055 | 2011-02-04 11:06:36 +0000 | [diff] [blame] | 13 | README file, demonstrates how to use the TurboJPEG/OSS Java front end to |
| 14 | compress and decompress JPEG images in memory. |
| 15 | |
| 16 | javac *.java |
| 17 | |
| 18 | builds .class files for both the front end and example code. |
| 19 | |
| 20 | |
| 21 | Note for OS X users |
| 22 | ------------------- |
| 23 | |
| 24 | /usr/lib, the directory under which libturbojpeg.dylib is installed on Mac |
| 25 | systems, is not part of the normal Java library path. Thus, when running a |
| 26 | Java application that uses TurboJPEG/OSS on Mac systems, you will need to pass |
| 27 | an argument of -Djava.library.path=/usr/lib to java. |
| DRC | ed6526f | 2011-02-05 05:41:18 +0000 | [diff] [blame] | 28 | |
| 29 | |
| 30 | Note for Solaris users |
| 31 | ---------------------- |
| 32 | |
| 33 | /opt/libjpeg-turbo/lib, the directory under which libturbojpeg.so is installed |
| 34 | on Solaris systems, is not part of the normal Java library path. Thus, when |
| 35 | running a Java application that uses TurboJPEG/OSS on Solaris systems, you will |
| 36 | need to pass an argument of -Djava.library.path=/opt/libjpeg-turbo/lib to java. |
| 37 | If using a 64-bit data model, then instead pass an argument of |
| 38 | -Djava.library.path=/opt/libjpeg-turbo/lib/amd64 to use the 64-bit version of |
| 39 | libturbojpeg.so. |
| DRC | f2214c2 | 2011-02-05 05:51:46 +0000 | [diff] [blame] | 40 | |
| 41 | |
| 42 | Note for MinGW users |
| 43 | -------------------- |
| 44 | |
| 45 | When libjpeg-turbo is built with MinGW, the TurboJPEG/OSS dynamic library is |
| 46 | named libturbojpeg.dll instead of turbojpeg.dll. This is in keeping with the |
| 47 | convention of MinGW, and it also avoids a filename conflict when the GCC and |
| 48 | Visual C++ versions of the libjpeg-turbo SDK are installed on the same system. |
| 49 | However, the TurboJPEG/OSS JNI wrapper will not work on Windows unless the DLL |
| 50 | is named turbojpeg.dll. You can work around this by renaming the DLL or by |
| DRC | 2413cb8 | 2011-02-08 02:11:37 +0000 | [diff] [blame^] | 51 | simply changing the LoadLibrary() calls in TurboJPEG.java so that they load |
| DRC | f2214c2 | 2011-02-05 05:51:46 +0000 | [diff] [blame] | 52 | "libturbojpeg" instead of "turbojpeg". |