f2ec34de52
* libjpeg-turbo: (39 commits) Oops. Delete the duplicate copy of [lib]turbojpeg.dll in the binary directory when uninstalling the package. AltiVec SIMD implementation of sample conversion and integer quantization Document the fact that the AltiVec implementation uses the same modified algorithms as the SSE2 implementation Use intrinsics for loading/storing data in the DCT/IDCT functions. This has no effect on the performance of the aligned loads/stores, but it makes it more obvious what that code is doing. Using intrinsics for the unaligned stores in the inverse DCT functions increases overall decompression performance by 1-2%. AltiVec SIMD implementation of RGB-to-Grayscale color conversion Remove unneeded code; Make sure jccolor-altivec.o will be rebuilt if jccolext-altivec.c changes. AltiVec SIMD implementation of RGB-to-YCC color conversion Make test a phony target so things don't go haywire if there is a file named test.c in the current directory. Maintain the traditional order of the regression tests while allowing the TurboJPEG and libjpeg portions to be executed separately Make comments more consistent Add a "quicktest" pseudo-target, for those times when you just don't want to sit through 11 iterations of TJUnitTest. Cosmetic tweaks to the PowerPC SIMD stubs Split AltiVec algorithms into separate files for ease of maintenance; Rename constants using lowercase so they are not confused with macros Optimizations to the AltiVec DCT algorithms (pre-compute constants and combine multiply/add operations) AltiVec SIMD implementation of slow integer inverse DCT Use macros to allocate constants statically, rather than reading them from a table using vec_splat*(). This improves code readability and probably improves performance a bit as well. Swap the order of the IFAST and ISLOW FDCT functions so that it matches the order of the prototypes in jsimd.h and the stubs in jsimd_powerpc.c. Include ARMv8 binaries when generating a combined OS X/iOS package using 'make iosdmg' In the output of the configure script, indicate whether gas-preprocessor.pl is being used along with the assembler. Modify the ARM64 assembly file so that it uses only syntax that the clang assembler in XCode 5.x can understand. These changes should all be cosmetic in nature-- they do not change the meaning or readability of the code nor the ability to build it for Linux. Actually, the code is now more in compliance with the ARM64 programming manual. In addition to these changes, there were a couple of instructions that clang simply doesn't support, so gas-preprocessor.pl was modified so that it now converts those into equivalent instructions that clang can handle. ... Conflicts: BUILDING.txt ChangeLog.txt cjpeg.c jpegtran.c
TurboJPEG Java Wrapper
======================
The TurboJPEG shared library can optionally be built with a Java Native
Interface wrapper, which allows the 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 Java API to compress and
decompress JPEG images in memory.
Performance Pitfalls
--------------------
The TurboJPEG Java API 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 TurboJPEG Java API always gives you the option of pre-allocating your own
source and destination buffers, which allows you to re-use those 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.
Installation Directory
----------------------
The TurboJPEG Java Wrapper will look for the TurboJPEG JNI library
(libturbojpeg.so, libturbojpeg.jnilib, or turbojpeg.dll) in the system library
paths or in any paths specified in LD_LIBRARY_PATH (Un*x), DYLD_LIBRARY_PATH
(Mac), or PATH (Windows.) Failing this, on Un*x and Mac systems, the wrapper
will look for the JNI library under the library directory configured when
libjpeg-turbo was built. If that library directory is
/opt/libjpeg-turbo/lib32, then /opt/libjpeg-turbo/lib64 is also searched, and
vice versa.
If you installed the JNI library into another directory, then you will need
to pass an argument of -Djava.library.path={path_to_JNI_library} to java, or
manipulate LD_LIBRARY_PATH, DYLD_LIBRARY_PATH, or PATH to include the directory
containing the JNI library.