ryan/mozjpeg
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
3,974 Commits 2 Branches 68 Tags
ffea183e55eab8c3efe2bc5caed3b2f41015d3e6
Commit Graph

349 Commits

Author SHA1 Message Date
DRC
d7a642b571 Minor doc tweaks + ChangeLog update 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@951 632fc199-4ca6-4c93-a231-07263d6284db
 2013-04-24 06:40:25 +00:00
DRC
61130e332a In order to avoid a functional regression with previous releases, the JAR file needs to be able to load either the 64-bit or 32-bit JNI library on Un*x systems. 2013-04-24 06:21:24 +00:00
DRC
c436a02bb1 In order to avoid a functional regression with previous releases, the JAR file needs to be able to load either the 64-bit or 32-bit JNI library on Un*x systems. 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@950 632fc199-4ca6-4c93-a231-07263d6284db
 2013-04-24 06:21:24 +00:00
DRC
00400a0a58 In order to avoid a functional regression with previous releases, the JAR file needs to be able to load either the 64-bit or 32-bit JNI library on Un*x systems. 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@950 632fc199-4ca6-4c93-a231-07263d6284db
 2013-04-24 06:21:24 +00:00
DRC
3d625746d4 Move the TurboJPEG DLLs back into the system directory on Windows platforms. For Windows, it doesn't really simplify the build system to install these libraries in c:\libjpeg-turbo*, and it introduces potential problems with loading the JNI library. Specifically, if a user linked their Java app against the 64-bit libjpeg-turbo SDK and then used a 32-bit JVM at run time, they would not be able to load the 32-bit turbojpeg.dll without manipulating java.library.path or the PATH environment (and vice versa for building against the 32-bit libjpeg-turbo SDK and using a 64-bit JVM at run time.) 2013-04-24 05:26:42 +00:00
DRC
4c0c6ffee0 Move the TurboJPEG DLLs back into the system directory on Windows platforms. For Windows, it doesn't really simplify the build system to install these libraries in c:\libjpeg-turbo*, and it introduces potential problems with loading the JNI library. Specifically, if a user linked their Java app against the 64-bit libjpeg-turbo SDK and then used a 32-bit JVM at run time, they would not be able to load the 32-bit turbojpeg.dll without manipulating java.library.path or the PATH environment (and vice versa for building against the 32-bit libjpeg-turbo SDK and using a 64-bit JVM at run time.) 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@949 632fc199-4ca6-4c93-a231-07263d6284db
 2013-04-24 05:26:42 +00:00
DRC
441308cffa Move the TurboJPEG DLLs back into the system directory on Windows platforms. For Windows, it doesn't really simplify the build system to install these libraries in c:\libjpeg-turbo*, and it introduces potential problems with loading the JNI library. Specifically, if a user linked their Java app against the 64-bit libjpeg-turbo SDK and then used a 32-bit JVM at run time, they would not be able to load the 32-bit turbojpeg.dll without manipulating java.library.path or the PATH environment (and vice versa for building against the 32-bit libjpeg-turbo SDK and using a 64-bit JVM at run time.) 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@949 632fc199-4ca6-4c93-a231-07263d6284db
 2013-04-24 05:26:42 +00:00
DRC
b8614f5d9f Older versions of automake don't support multiple _JAVA primaries, but we don't actually have to specify a "dist" primary, since the Java sources are already included under EXTRA_DIST. 2013-04-24 03:36:30 +00:00
DRC
9e646118bc Older versions of automake don't support multiple _JAVA primaries, but we don't actually have to specify a "dist" primary, since the Java sources are already included under EXTRA_DIST. 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@948 632fc199-4ca6-4c93-a231-07263d6284db
 2013-04-24 03:36:30 +00:00
DRC
4b357abb6d Older versions of automake don't support multiple _JAVA primaries, but we don't actually have to specify a "dist" primary, since the Java sources are already included under EXTRA_DIST. 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@948 632fc199-4ca6-4c93-a231-07263d6284db
 2013-04-24 03:36:30 +00:00
DRC
931a4929bb Fix 'make dist' 2013-04-24 03:15:23 +00:00
DRC
2bf41d5534 Fix 'make dist' 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@947 632fc199-4ca6-4c93-a231-07263d6284db
 2013-04-24 03:15:23 +00:00
DRC
94f7ac929a Fix 'make dist' 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@947 632fc199-4ca6-4c93-a231-07263d6284db
 2013-04-24 03:15:23 +00:00
DRC
2de2cf9e54 Further enhancements/fixes to the packaging system: 
-- The Mac and Cygwin 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} on Cygwin and /Library/Documentation/{package_name} on Mac.
-- Fixed a duplicate filename warning when generating RPMs with the default prefix of /opt/libjpeg-turbo.
-- Moved the TurboJPEG libraries out of the system directory on Windows and Mac.  It is no longer necessary to put them there, since we are not trying to be backward compatible with TurboJPEG/IPP anymore.
-- Fixed an issue whereby building the "installer" target on Windows would not build the Java JAR file, thus causing an error if the JAR had not been previously built.
-- Building the "install" target on Windows will now install libjpeg-turbo into c:\libjpeg-turbo[-gcc][64] (the same directories used by the installers.)  This can be overridden by setting CMAKE_INSTALL_PREFIX.
-- The Java classes on all platforms will now look for the JNI library in the directory under which the build/packaging system installs it.
 2013-04-23 22:29:00 +00:00
DRC
fb0ef0019b Further enhancements/fixes to the packaging system: 
-- The Mac and Cygwin 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} on Cygwin and /Library/Documentation/{package_name} on Mac.
-- Fixed a duplicate filename warning when generating RPMs with the default prefix of /opt/libjpeg-turbo.
-- Moved the TurboJPEG libraries out of the system directory on Windows and Mac.  It is no longer necessary to put them there, since we are not trying to be backward compatible with TurboJPEG/IPP anymore.
-- Fixed an issue whereby building the "installer" target on Windows would not build the Java JAR file, thus causing an error if the JAR had not been previously built.
-- Building the "install" target on Windows will now install libjpeg-turbo into c:\libjpeg-turbo[-gcc][64] (the same directories used by the installers.)  This can be overridden by setting CMAKE_INSTALL_PREFIX.
-- The Java classes on all platforms will now look for the JNI library in the directory under which the build/packaging system installs it.


git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@946 632fc199-4ca6-4c93-a231-07263d6284db
 2013-04-23 22:29:00 +00:00
DRC
7175e51792 Further enhancements/fixes to the packaging system: 
-- The Mac and Cygwin 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} on Cygwin and /Library/Documentation/{package_name} on Mac.
-- Fixed a duplicate filename warning when generating RPMs with the default prefix of /opt/libjpeg-turbo.
-- Moved the TurboJPEG libraries out of the system directory on Windows and Mac.  It is no longer necessary to put them there, since we are not trying to be backward compatible with TurboJPEG/IPP anymore.
-- Fixed an issue whereby building the "installer" target on Windows would not build the Java JAR file, thus causing an error if the JAR had not been previously built.
-- Building the "install" target on Windows will now install libjpeg-turbo into c:\libjpeg-turbo[-gcc][64] (the same directories used by the installers.)  This can be overridden by setting CMAKE_INSTALL_PREFIX.
-- The Java classes on all platforms will now look for the JNI library in the directory under which the build/packaging system installs it.


git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@946 632fc199-4ca6-4c93-a231-07263d6284db
 2013-04-23 22:29:00 +00:00
DRC
f42e2be51a 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}.
 2013-04-19 04:25:14 +00:00
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
DRC
764e1e23aa 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
DRC
9f8a003137 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
DRC
34be67477f 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 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@919 632fc199-4ca6-4c93-a231-07263d6284db
 2013-01-21 23:42:12 +00:00
DRC
5039d734d5 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 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@919 632fc199-4ca6-4c93-a231-07263d6284db
 2013-01-21 23:42:12 +00:00
DRC
fc9fec465f 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
DRC
515fece330 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. 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@918 632fc199-4ca6-4c93-a231-07263d6284db
 2013-01-19 06:43:27 +00:00
DRC
98ca1c35d7 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. 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@918 632fc199-4ca6-4c93-a231-07263d6284db
 2013-01-19 06:43:27 +00:00
DRC
70d3c1aeec 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
DRC
e0c15701d4 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.) 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@862 632fc199-4ca6-4c93-a231-07263d6284db
 2012-09-24 02:27:55 +00:00
DRC
fac3bea8da 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.) 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@862 632fc199-4ca6-4c93-a231-07263d6284db
 2012-09-24 02:27:55 +00:00
DRC
a6c9eaf155 If libturbojpeg.jnilib is not found on Mac systems, specifically look for it under /usr/lib, since /usr/lib isn't part of the default java.library.path on that platform. 2012-08-24 02:44:39 +00:00
DRC
3f0ffbc4b7 If libturbojpeg.jnilib is not found on Mac systems, specifically look for it under /usr/lib, since /usr/lib isn't part of the default java.library.path on that platform. 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@861 632fc199-4ca6-4c93-a231-07263d6284db
 2012-08-24 02:44:39 +00:00
DRC
61e1341f11 If libturbojpeg.jnilib is not found on Mac systems, specifically look for it under /usr/lib, since /usr/lib isn't part of the default java.library.path on that platform. 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@861 632fc199-4ca6-4c93-a231-07263d6284db
 2012-08-24 02:44:39 +00:00
DRC
019d51d4f1 Add flags to the TurboJPEG API that allow the caller to force the use of either the fast or the accurate DCT/IDCT algorithms in the underlying codec. 2012-06-29 23:46:38 +00:00
DRC
3cde27c244 Add flags to the TurboJPEG API that allow the caller to force the use of either the fast or the accurate DCT/IDCT algorithms in the underlying codec. 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@851 632fc199-4ca6-4c93-a231-07263d6284db
 2012-06-29 23:46:38 +00:00
DRC
73d74c132b Add flags to the TurboJPEG API that allow the caller to force the use of either the fast or the accurate DCT/IDCT algorithms in the underlying codec. 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@851 632fc199-4ca6-4c93-a231-07263d6284db
 2012-06-29 23:46:38 +00:00
DRC
448d12d298 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
DRC
bd4c4babbd 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.) 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@832 632fc199-4ca6-4c93-a231-07263d6284db
 2012-06-06 08:41:06 +00:00
DRC
f659f43f93 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.) 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@832 632fc199-4ca6-4c93-a231-07263d6284db
 2012-06-06 08:41:06 +00:00
DRC
6de1345133 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:30:46 +00:00
DRC
cac105133e Fix the behavior of the alpha-enabled colorspace constants whenever libjpeg-turbo is built without SIMD support and merged upsampling is used. 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@811 632fc199-4ca6-4c93-a231-07263d6284db
 2012-03-16 14:37:36 +00:00
DRC
c1e4151607 Added new alpha channel colorspace constants/pixel formats, so applications can specify that they need the unused byte in a 4-component RGB output buffer set to 0xFF when decompressing. 2011-12-19 02:21:03 +00:00
DRC
67ce3b2352 Added new alpha channel colorspace constants/pixel formats, so applications can specify that they need the unused byte in a 4-component RGB output buffer set to 0xFF when decompressing. 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@732 632fc199-4ca6-4c93-a231-07263d6284db
 2011-12-19 02:21:03 +00:00
DRC
51b8cd674a "which"="that" 2011-12-15 13:12:59 +00:00
DRC
80803ae5fe "which"="that" 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@730 632fc199-4ca6-4c93-a231-07263d6284db
 2011-12-15 13:12:59 +00:00
DRC
5d1cec9a79 Add TJCustomFilter to Windows build 2011-09-20 05:35:31 +00:00
DRC
6b968b28ae Add TJCustomFilter to Windows build 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@709 632fc199-4ca6-4c93-a231-07263d6284db
 2011-09-20 05:35:31 +00:00
DRC
f343d7332a Implement custom filter callback in Java 2011-09-20 05:02:19 +00:00
DRC
f546711076 Implement custom filter callback in Java 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@707 632fc199-4ca6-4c93-a231-07263d6284db
 2011-09-20 05:02:19 +00:00
DRC
1109f68db6 Fix 'make docs' with out-of-tree builds 2011-09-19 18:58:21 +00:00
DRC
835b76fb65 Fix 'make docs' with out-of-tree builds 
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@706 632fc199-4ca6-4c93-a231-07263d6284db
 2011-09-19 18:58:21 +00:00
DRC
50b3728013 Fix 'make headers' with out-of-tree builds 2011-09-19 18:47:00 +00:00