-
Show log
Commit
-
Hash : 693f4a56
Author :
Date : 2014-02-11T10:16:42
Fix an issue that prevented tjEncodeYUV2() and TJCompressor.encodeYUV() from working properly if the source image was very tiny. Basically, jpeg_start_compress() was attempting to write the JPEG headers, which was overrunning the YUV buffer. This patch removes the call to jpeg_start_compress() in tjEncodeYUV2() and replaces it with calls to the individual routines that are necessary to initialize the color converter and downsampler. TJUnitTest has also been modified to test for this condition (the buffer size regression test now works in YUV mode.) git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@1121 632fc199-4ca6-4c93-a231-07263d6284db
-
README
-
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.