mozjpeg

Files

DRC 073c49ed39 Overhaul Linux/Unix packaging system, primarily to avoid conflicts with vendor-supplied libjpeg-turbo packages (such as in Fedora and RHEL 6.) This also streamlines the packaging system somewhat, since it is no longer necessary to move the TurboJPEG libraries into the system library directory. Relocating those libraries was originally done to provide backward compatibility with TurboJPEG/IPP, but that package is long obsolete, and the software that formerly used it has been linking statically with libjpeg-turbo for quite some time.

If the default prefix (/opt/libjpeg-turbo) is used, then we now always install 32-bit libraries in /opt/libjpeg-turbo/lib32 and 64-bit libraries in /opt/libjpeg-turbo/lib64 instead of trying to conform to the Debian or Red Hat conventions.  The RPM and DEB packages will now be created with the directory structure defined by the configure variables "prefix", "bindir", "libdir", etc., with the exception that the docs are always installed under /usr/share/doc/{package_name}-{version}.


git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@944 632fc199-4ca6-4c93-a231-07263d6284db

2013-04-19 04:25:14 +00:00

doc

Add a Java version of TJBench and extend the TurboJPEG Java API to support it (this involved adding a polymorphic method in TJCompressor that accepts x and y offsets into a larger buffer, similar to the previous modification that had been done to TJDecompressor.)

2012-09-24 02:27:55 +00:00

org/libjpegturbo/turbojpeg

2012-09-24 02:27:55 +00:00

CMakeLists.txt

2012-09-24 02:27:55 +00:00

Makefile.am

Overhaul Linux/Unix packaging system, primarily to avoid conflicts with vendor-supplied libjpeg-turbo packages (such as in Fedora and RHEL 6.) This also streamlines the packaging system somewhat, since it is no longer necessary to move the TurboJPEG libraries into the system library directory. Relocating those libraries was originally done to provide backward compatibility with TurboJPEG/IPP, but that package is long obsolete, and the software that formerly used it has been linking statically with libjpeg-turbo for quite some time.

2013-04-19 04:25:14 +00:00

MANIFEST.MF

Build and package TurboJPEG/OSS Java wrapper into JAR file

2011-04-01 00:20:33 +00:00

org_libjpegturbo_turbojpeg_TJ.h

2012-09-24 02:27:55 +00:00

org_libjpegturbo_turbojpeg_TJCompressor.h

2012-09-24 02:27:55 +00:00

org_libjpegturbo_turbojpeg_TJDecompressor.h

Add x, y parameters to TJDecompressor so that it can be used to decompress to an arbitrary position in the destination image (TurboVNC needs this.)

2012-06-06 08:41:06 +00:00

org_libjpegturbo_turbojpeg_TJTransformer.h

Java code cleanup + Java docs

2011-03-15 20:52:02 +00:00

README

Eliminated the awkward and confusing "TurboJPEG/OSS" designation, since there are no other active implementations of the TurboJPEG API anymore; don't refer to the libjpeg API library as "libjpeg-turbo" anymore, since that can be confusing; ARM v7s build instructions

2013-01-21 23:42:12 +00:00

TJBench.java

2012-09-24 02:27:55 +00:00

TJExample.java

ImageIO.read() returns null if the input image type is not supported (which occurs when trying to read a PPM file), so output a friendly error instead of letting the next line throw a null pointer exception.

2013-01-19 06:43:27 +00:00

TJUnitTest.java

Fix the behavior of the alpha-enabled colorspace constants whenever libjpeg-turbo is built without SIMD support and merged upsampling is used.

2012-03-16 14:37:36 +00:00

README

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
----------------------

If the TurboJPEG JNI library (libturbojpeg.so, libturbojpeg.jnilib, or
turbojpeg.dll) is not installed under a system library directory or under a
directory specified in LD_LIBRARY_PATH (Unix) or PATH (Windows), then you will
need to pass an argument of -Djava.library.path={path_to_JNI_library} to java.