mozjpeg

Files

DRC 6530203fdd Build: More GNUInstallDirs improvements

These improvements enable build systems to use GNUInstallDirs to define
custom directory variables.

- The set_dir() macro was renamed to GNUInstallDirs_set_install_dir(),
  in keeping with the module's established macro naming convention.

- Rather than detecting whether the prefix has changed, the new
  GNUInstallDirs_set_install_dir() macro instead examines whether the
  default for the variable in question has changed.  This allows for
  more flexibility, since build systems may decide to change the
  defaults based on factors other than the prefix.  It also enables the
  macro to work properly outside of the module.

- The module now performs directory variable substitution within the
  body of GNUInstallDirs_get_absolute_install_dir().

- The JAVADIR variable is no longer included in GNUInstallDirs.  That
  directory is not part of the GNU spec, and it turns out that various
  operating systems use different conventions for the location of Java
  classes.  Instead, the variable is now implemented in our build
  system as a demonstration of the aforementioned GNUInstallDirs
  enhancements.

2016-12-09 12:09:08 -06:00

doc

Further exception cleanup

2015-07-27 03:40:58 -05:00

org/libjpegturbo/turbojpeg

Build: Set install dirs in a more GNU-friendly way

2016-12-07 16:55:38 -06:00

CMakeLists.txt

Build: More GNUInstallDirs improvements

2016-12-09 12:09:08 -06: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

Refactored YUVImage Java class so that it supports both unified YUV image buffers as well as separate YUV image planes; modified the JNI functions accordingly and added new helper functions to the TurboJPEG C API (tjPlaneWidth(), tjPlaneHeight(), tjPlaneSizeYUV()) to facilitate those modifications; changed potentially confusing "component width" and "component height" terms to "plane width" and "plane height" and modified variable names in turbojpeg.c to reflect this; numerous other documentation tweaks

2014-08-17 12:23:49 +00:00

org_libjpegturbo_turbojpeg_TJCompressor.h

2014-08-17 12:23:49 +00:00

org_libjpegturbo_turbojpeg_TJDecompressor.h

2014-08-17 12:23:49 +00:00

org_libjpegturbo_turbojpeg_TJTransformer.h

Java code cleanup + Java docs

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

README

Minor doc tweaks + ChangeLog update

2013-04-24 06:40:25 +00:00

TJBench.java

TJBench: Fix regression/-nowrite always enabled

2016-11-20 16:22:23 -06:00

TJExample.java

Further exception cleanup

2015-07-27 03:40:58 -05:00

TJUnitTest.java

Java: Avoid OOM error when running 'make test'

2016-02-09 01:35:39 -06: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
----------------------

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.