- a6ef282 Some of the IJG headers say "Modified by", so clarify that our "Modifications" are not referring to these. by DRC · 11 years ago
- cadabd4 Actually, the second bug was hidden by the first, so the initial ChangeLog entry was correct from the user's point of view. by DRC · 11 years ago
- e8be2c6 Fix an issue that resulted in an error ("Invalid SOS parameters for sequential JPEG. Didn't expect more than one scan.") when decoding progressive+arithmetic JPEGs generated by libjpeg-turbo. by DRC · 11 years ago
- c44750e Fix an issue that resulted in an error ("Invalid SOS parameters for sequential JPEG. Didn't expect more than one scan.") when decoding progressive+arithmetic JPEGs generated by libjpeg-turbo. by DRC · 11 years ago
- 5aa6c9a Remove unnecessary whitespace by DRC · 11 years ago
- 94b6c02 Name the package *cygwin64.tar.bz2 when building on Cygwin64. by DRC · 11 years ago
- f369f17 Due to the way in which the configure script silently falls back to a non-SIMD build if SIMD can't be enabled, we accidentally released iOS ARM v7 and v7s binaries in 1.3.0 that did not contain NEON SIMD code, because gas-preprocessor.pl wasn't in the PATH. In order to prevent this from happening again, specifying --with-simd now has the effect of forcing a SIMD build, and if this argument is specified, any issues encountered while enabling SIMD are treated as fatal. by DRC · 11 years ago
- 5d2514b We can't enable optimized entropy coding unless we're using Huffman coding. This fixes a bug whereby attempting to create a progressive JPEG with arithmetic coding would fail. by DRC · 11 years ago
- 2c63c00 Clarify that the bug affects cjpeg as well as jpegtran. by DRC · 11 years ago
- ba923a8 Fix I/O suspension. This little nugget of code was introduced in r30 as part of an early attempt to make buffered I/O work with the optimized Huffman codec. Ultimately, r32 reverted a lot of that mess and introduced much of the logic we now use, rendering this code unnecessary, but it was never reverted because it only causes problems when I/O suspension is used, and apparently no one has tried to do that with libjpeg-turbo until now. by DRC · 11 years ago
- 1370f10 We can't enable optimized entropy coding unless we're using Huffman coding. This fixes a bug whereby attempting to create a progressive JPEG with arithmetic coding would fail. by DRC · 11 years ago
- 24f11a7 The connect.apple.com alias has apparently been down for about a month by DRC · 11 years ago
- 6eb29dd Oops. We need to delete the new copy of turbojpeg.dll in the binary directory. Also add quotes to InstDir to allow installing under "c:\Program Files\", and remove unnecessary quotes in the Delete directives. by DRC · 11 years ago
- 4d87793 In the Windows installer packages, place a duplicate copy of turbojpeg.dll in c:\libjpeg-turbo[-gcc][64]\bin. This is mainly to give installers an easy way to find the DLL for the purposes of bundling it. Specifically, this was necessary for TurboVNC, becuase 32-bit CMake running on 64-bit Windows cannot ever access the "real" c:\windows\system32 directory. by DRC · 11 years ago
- 7ef2616 1.3.1 by DRC · 11 years ago
- ae92418 Add note regarding the fact that 4:4:0 lacks full SIMD support; Add an option for benchmarking 4:4:0 subsampling in TJBench; Wordsmithing; Disable timestamp in generated HTML files to make diffing and merging easier by DRC · 11 years ago
- ca866c4 Disable timestamp in generated HTML files to make diffing and merging easier. by DRC · 11 years ago
- 7657726 Wordsmithing by DRC · 11 years ago
- 07796da Add note regarding the fact that 4:4:0 lacks full SIMD support; Add an option for benchmarking 4:4:0 subsampling in tjbench. by DRC · 11 years ago
- bcda683 Upgrade to Doxygen 1.8.3.1; Add note regarding the fact that 4:4:0 lacks full SIMD support. by DRC · 11 years ago
- 71ccb39 Upgrade to Doxygen 1.8.3.1 by DRC · 11 years ago
- 1520ee2 Remove stray closing bracket that prevented the use of this header in a C++ application by DRC · 11 years ago
- dadebe9 Document previous commit in the change log by DRC · 11 years ago
- c32e0c2 By default, install the libraries into /opt/libjpeg-turbo/lib32 on any 32-bit system, not just x86, and into /opt/libjpeg-turbo/lib64 on any 64-bit system, not just x86-64. In particular, this addresses an issue with building TurboVNC and VirtualGL on ARM systems. by DRC · 11 years ago
- b927103 Fix lintian warning about missing maintainer address when installing on recent Debian-based systems by DRC · 11 years ago
- d3eb40b Use ELF64 object format on 64-bit kFreeBSD systems. by DRC · 11 years ago
- 6e0bbbf 1.3.0 by DRC · 11 years ago
- 49df783 Clean up the output of tjunittest and TJUnitTest by DRC · 11 years ago
- 04e0a02 Make sure the RPM provides "libjpeg-turbo" as well, for backward compatibility (the TurboVNC RPM build, in particular, checks for this.) by DRC · 11 years ago
- bb9e147 Fix backward compatibility between the Java classes and the 1.2.x JNI library (as long as the 1.3 Java features are not used.) by DRC · 11 years ago
- 1d29c5f Correct misuse of the word "pitch" + more code formatting tweaks by DRC · 11 years ago
- 67bee86 Code formatting tweaks by DRC · 11 years ago
- 65d4a46 Java doc tweaks by DRC · 11 years ago
- c6eedeb Oops by DRC · 11 years ago
- 0c83e5a Not that it matters, because JNI uses dlopen()/dlsym() to load symbols, but for bookkeeping purposes, move the JNI symbols introduced in libjpeg-turbo 1.3 into a new section. by DRC · 11 years ago
- d8522a7 Wordsmithing by DRC · 11 years ago
- 01fdcc3 Further doc tweaks by DRC · 11 years ago
- 9ce1a21 Subtle point, but since libjpeg-turbo 1.3 now supports scaling factors > 1, the width and height specified in tjDecompress2() are not necessarily smaller than the JPEG width/height. by DRC · 11 years ago
- 0bb37a5 Create 1.3.x branch by DRC · 11 years ago
- 4c17a45 Fix I/O suspension. This little nugget of code was introduced in r30 as part of an early attempt to make buffered I/O work with the optimized Huffman codec. Ultimately, r32 reverted a lot of that mess and introduced much of the logic we now use, rendering this code unnecessary, but it was never reverted because it only causes problems when I/O suspension is used, and apparently no one has tried to do that with libjpeg-turbo until now. by DRC · 11 years ago
- 4578953 For consistency, allow the name of the Mac and Cygwin packages to be overridden as well. by DRC · 11 years ago
- d7a642b Minor doc tweaks + ChangeLog update by DRC · 11 years ago
- 00400a0 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. by DRC · 11 years ago
- 441308c 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.) by DRC · 11 years ago
- 4b357ab 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. by DRC · 11 years ago
- 94f7ac9 Fix 'make dist' by DRC · 11 years ago
- 7175e51 Further enhancements/fixes to the packaging system: by DRC · 11 years ago
- 764e1e2 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. by DRC · 11 years ago
- 0ddff3b Formatting tweaks by DRC · 11 years ago
- 7eced19 Remove unneeded headers (cdef.h isn't available on all platforms) and change u_int32_t to unsigned int, since u_int32_t isn't available on all platforms. This fixes build issues on Solaris. by DRC · 11 years ago
- 08769b3 Grammar police by DRC · 11 years ago
- f32640e Document issues encountered when building on OS X 10.7 and later. by DRC · 11 years ago
- 6cd1ec4 It's more correct to say "The Independent JPEG Group's software", since libjpeg-turbo emulates both the command-line and application programming interfaces. by DRC · 11 years ago
- 7ed0aeb Add note about how to obtain PackageMaker if using recent Xcode releases. by DRC · 11 years ago
- 5e96c9b Bump version for post-beta pre-releases by DRC · 11 years ago
- 5a84a0e by DRC · 11 years ago
- fde862b Trying to build ARM v7/v7s iOS binaries from the "official" libjpeg-turbo tarball (generated on RHEL4/autoconf 2.59/automake 1.9.2/libtool 1.5.6) using either Xcode 3.2.x or 4.5.x produces an error: "libtool: compile: unable to infer tagged configuration". Further study is warranted, but the most expedient way around it at the moment is to re-run autoconf on the OS X machine that is being used to generate the iOS binaries. by DRC · 11 years ago
- 292fb84 Fix 'make dist' by DRC · 11 years ago
- 0bf58f2 Include a C version of md5cmp rather than depending on an external md5sum binary, since md5sum is not available on all platforms (specifically, it doesn't exist on FreeBSD, and it has to be installed via MacPorts on OS X.) by DRC · 11 years ago
- a35de7c Fix line break by DRC · 12 years ago
- a2a2cd6 Include ARM v7s (iPhone 5, iPad 4) support in the universal libjpeg/libturbojpeg libraries distributed with our official binary package for OS X. by DRC · 12 years ago
- 189ee81 Oops. Separate .def file is not needed when compiling with jpeg-8 API/ABI emulation. by DRC · 12 years ago
- 0f7ff71 Wordsmith the project description by DRC · 12 years ago
- bdfcb74 Actually, turbojpeg.c works with libjpeg as well by DRC · 12 years ago
- 5039d73 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 by DRC · 12 years ago
- 98ca1c3 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. by DRC · 12 years ago
- 2e22eb6 New year, new copyright message by DRC · 12 years ago
- 6da61db Fix several issues with SRPM generation: (1) ensure that all relevant configure arguments get passed down to the configure command line in the generated spec file, (2) adjust the file manifest in the spec to accommodate the differing "age" version whenever the in-memory source/dest managers are used, and (3) fix an issue with the value of SO_MAJOR_VERSION passed down to the configure command line in the generated spec file (SO_MAJOR_VERSION has to remain pure, so we use a different variable to pass down the combined "current+age" value to libtool in Makefile.am.) by DRC · 12 years ago
- dc4645d Since Windows doesn't use lazy loading, clarify that a Windows application that uses jpeg_mem_dest() or jpeg_mem_src() must use the DLL containing those functions at run time. Other wordsmithing by DRC · 12 years ago
- 736fb06 Compiler warnings on Windows by DRC · 12 years ago
- ab70623 Implement in-memory source/destination managers even when not emulating the libjpeg v8 API/ABI by DRC · 12 years ago
- b87136c Include justification for not supporting SmartScale, DCT scaling, and the libjpeg v9 ABI by DRC · 12 years ago
- eff4f95 Subtle point, but the libjpeg v7+ API is not backward incompatible. That is, programs that were built against jpeg-6b can still build against jpeg-7+ with no issues. It's only the ABI that is backward incompatible, so the primary justification for implementing the emulation feature was to provide run-time (ABI) compatibility. by DRC · 12 years ago
- e2394fc Subtle point, but the libjpeg v7+ API is not backward incompatible. That is, programs that were built against jpeg-6b can still build against jpeg-7+ with no issues. It's only the ABI that is backward incompatible, so the primary justification for implementing the emulation feature was to provide run-time (ABI) compatibility. by DRC · 12 years ago
- cb2036f Say "do not include" rather than "omit", to be consistent with the CMake build system and the output of the configure script. by DRC · 12 years ago
- 7c39e3a Include full readme for nightshot_iso_100 by DRC · 12 years ago
- 1f4cc44 The GNU version of md5sum is picky about the spacing by DRC · 12 years ago
- b87a0b4 Fix the x86 build with NASM 0.98. Since NASM 0.98 is the default version on OS X, we want to at least allow people to build 32-bit code with it, even though it can't properly build 64-bit code. by DRC · 12 years ago
- 00c2cf3 Fix the x86 build with NASM 0.98. Since NASM 0.98 is the default version on OS X, we want to at least allow people to build 32-bit code with it, even though it can't properly build 64-bit code. by DRC · 12 years ago
- 0f43551 Fix 'make dist' by DRC · 12 years ago
- c5052c7 Acknowledge the source of nightshot_iso_100.bmp by DRC · 12 years ago
- 211d1e7 Consolidate the MD5 sums into one location and add a --without-turbojpeg switch to the Un*x build to allow building libjpeg-turbo without the TurboJPEG/OSS wrapper library. These modifications were supposed to lay the ground work for adding compile-time-selectable 12-bit JPEG support, but unfortunately there are deeper issues that prevent the implementation of that feature right now (namely, some of the modifications made to the C code to support the SIMD code are apparently not 12-bit-friendly.) by DRC · 12 years ago
- 5815699 In all fairness, breaking backward ABI compatibility was necessary in jpeg-7 and jpeg-8 due to the fact that the caller allocates the struct. by DRC · 12 years ago
- f29ffd3 Modify 'make test' so that it uses MD5 sums instead of reference images. This eliminates the need to check most of the test images into the repository, which keeps the source tarball to a reasonable size. by DRC · 12 years ago
- 2f12d7a Also remove mention of install.txt and filelist.txt in the build system and README. by DRC · 12 years ago
- 6f96153 install.txt contains no information relevant to libjpeg-turbo, and filelist.txt does not give any information that can't be gleaned by looking at the headers in the various source files. by DRC · 12 years ago
- e54d31a by DRC · 12 years ago
- 6b638a6 by DRC · 12 years ago
- d211eff by DRC · 12 years ago
- dad4d2e by DRC · 12 years ago
- d5e964c Wordsmithing; Remove mention of TurboJPEG/IPP-- it is no longer a relevant comparison, since the version of IPP on which TurboJPEG/IPP was based is now quite old, and TurboJPEG/IPP is no longer distributed or supported by The VirtualGL Project; Include information about mathematical incompatibilities with jpeg-8 by DRC · 12 years ago
- c168d96 Prevent compiler warning on Windows if jmorecfg.h is included after the Windows headers, which also define FAR. by DRC · 12 years ago
- 6a32d04 Prevent compiler warning on Windows if jmorecfg.h is included after the Windows headers, which also define FAR. by DRC · 12 years ago
- 2870131 Spacing tweak by DRC · 12 years ago
- d7ca17b We support arithmetic coding, which is a feature of libjpeg v7/v8 by DRC · 12 years ago
- ac51438 Indicate our support for some of the jpeg-8d features, as well as arithmetic coding by DRC · 12 years ago
- 966d8b7 Undocument ansi2knr.c, since we don't include it by DRC · 12 years ago
- c137f0f Merge some of the README changes from jpeg-8d and change the copyright and version strings to reflect that we use some of that code. by DRC · 12 years ago
- 5829cb2 The Independent JPEG Group's JPEG software v8d by Guido Vollbeding · 13 years ago
- c39ec14 The Independent JPEG Group's JPEG software v8c by Guido Vollbeding · 14 years ago