Merge with new libjpeg-turbo repository #205
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
See mozilla#147 Couldn't merge provided patch, so rewrote it. Also applies change to quantize_trellis_arith()
… platforms. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1529 632fc199-4ca6-4c93-a231-07263d6284db
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1531 632fc199-4ca6-4c93-a231-07263d6284db
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1531 632fc199-4ca6-4c93-a231-07263d6284db
…igured with automake 1.11 or later. NOTE: the build still spits out "error: ignoring unknown tag NASM" for each object, but unfortunately, if we remove "--tag NASM" from the command line, the build breaks under older versions of automake (it aborts with "unable to infer tagged configuration.") git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1534 632fc199-4ca6-4c93-a231-07263d6284db
…igured with automake 1.11 or later. NOTE: the build still spits out "error: ignoring unknown tag NASM" for each object, but unfortunately, if we remove "--tag NASM" from the command line, the build breaks under older versions of automake (it aborts with "unable to infer tagged configuration.") git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1534 632fc199-4ca6-4c93-a231-07263d6284db
…r, then use the docdir variable defined by autoconf 2.60 and later, if available. This will, for instance, install the documentation under /usr/share/doc/libjpeg-turbo by default if prefix=/usr, unless docdir is overridden. When using earlier versions of autoconf, docdir is set to ${datadir}/doc, as it always has been.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1535 632fc199-4ca6-4c93-a231-07263d6284db
…r, then use the docdir variable defined by autoconf 2.60 and later, if available. This will, for instance, install the documentation under /usr/share/doc/libjpeg-turbo by default if prefix=/usr, unless docdir is overridden. When using earlier versions of autoconf, docdir is set to ${datadir}/doc, as it always has been.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1535 632fc199-4ca6-4c93-a231-07263d6284db
…ETENV so that developers can add -DNO_GETENV to the C flags when building for platforms that don't have getenv(). Currently this is known to be necessary when building for Windows Phone. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1537 632fc199-4ca6-4c93-a231-07263d6284db
…ETENV so that developers can add -DNO_GETENV to the C flags when building for platforms that don't have getenv(). Currently this is known to be necessary when building for Windows Phone. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1537 632fc199-4ca6-4c93-a231-07263d6284db
This is instead of assuming 8-bit input and producing borked images.
rdpng: convert 16-bit input to 8-bit
Declare inbuffer `const`
…ry to be linked against msvcr*.dll instead of libcmt*.lib. This is reported to be necessary when building libjpeg-turbo for use with C#. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1539 632fc199-4ca6-4c93-a231-07263d6284db
…ry to be linked against msvcr*.dll instead of libcmt*.lib. This is reported to be necessary when building libjpeg-turbo for use with C#. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1539 632fc199-4ca6-4c93-a231-07263d6284db
Make sure BMP height and width don't exceed positive signed 32-bit range even when 64-bit variables are being used.
Add command line option -quant-baseline to cjpeg to force quantization table entries to be in 1-255 range for JPEG baseline compatibility. See related discussion in mozilla#145
mozilla#166 describes an issue where I/O suspension is not properly handled in scan optimization. Supporting I/O suspension may be difficult to achieve here, thus return an error to make it explicit that I/O suspension is unsupported.
Define JERR_UNSUPPORTED_SUSPEND in correct header file
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
…apparently the Huffman codec hasn't ever been fully accelerated on 64-bit OS X. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1541 632fc199-4ca6-4c93-a231-07263d6284db
…apparently the Huffman codec hasn't ever been fully accelerated on 64-bit OS X. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1541 632fc199-4ca6-4c93-a231-07263d6284db
Make sure @yuv_buffer is freed before return. Signed-off-by: Arjun Sreedharan <arjun024@gmail.com>
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1543 632fc199-4ca6-4c93-a231-07263d6284db
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1543 632fc199-4ca6-4c93-a231-07263d6284db
Make sure @yuv_buffer is freed before return.
jpegyuv: fix memory leak when @image_buffer allocation fails
jpegyuv: fix memory leak when path is invalid
…ncoding some very specific (and proprietary) aerial images using quality=98, an optimized Huffman table, and the ISLOW DCT. These images were causing the Huffman bit buffer to overflow, because the code for encoding the DC coefficient was using the equivalent of the 32-bit version of EMIT_BITS(). Thus, when 64-bit code was used, the DC coefficient code was not properly checking how many bits were in the buffer before attempting to add more bits to it. This issue appears to have existed in all versions of libjpeg-turbo. git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1547 632fc199-4ca6-4c93-a231-07263d6284db
Indent "... OR ..." to make it clear that the choice is between Visual C++ and MinGW, not Visual C++ and MinGW + NASM. Move NASM to the top of the list to make that even more clear. Make it clear that nasm.exe should be in the PATH. Addresses concerns raised in mozilla#70
<sigh> GitHub doesn't render indented text the same as my local MarkDown viewer (MacDown), so it's necessary to indent "... OR ..." by 3 spaces so both will display it on the same indentation level as "Visual C++ 2005 or later" and "MinGW".
Even though tjDecompressToYUV2() is mostly just a wrapper for tjDecompressToYUVPlanes(), tjDecompressToYUV2() still calls jpeg_read_header(), so it needs to properly set up the libjpeg error handler prior to making this call. Otherwise, under very esoteric (and arguably incorrect) use cases, a program can call tjDecompressToYUV2() without first checking the JPEG header using tjDecompressHeader3(), and if the header is corrupt, tjDecompressToYUV2() will abort without triggering an error. Fixes mozilla#72
Actually, what happened was that the longjmp() call within my_error_exit() acted on the previous value of myerr->setjmp_buffer, which was probably set in a previous TurboJPEG function, such as tjInitDecompress(). Thus, when a libjpeg error was triggered within the body of tjDecompressToYUV2(), the PC jumped to the error handler of the previous TurboJPEG function, and this usually caused stack corruption in the calling program (because the signature and return type of the previous TurboJPEG function probably wasn't the same.)
Even though tjDecompressToYUV2() is mostly just a wrapper for tjDecompressToYUVPlanes(), tjDecompressToYUV2() still calls jpeg_read_header(), so it needs to properly set up the libjpeg error handler prior to making this call. Otherwise, under very esoteric (and arguably incorrect) use cases, a program could call tjDecompressToYUV2() without first checking the JPEG header using tjDecompressHeader3(), and if the header was corrupt, then the libjpeg API would invoke my_error_exit(). my_error_exit() would in turn call longjmp() on the previous value of myerr->setjmp_buffer, which was probably set in a previous TurboJPEG function, such as tjInitDecompress(). Thus, when a libjpeg error was triggered within the body of tjDecompressToYUV2(), the PC would jump to the error handler of the previous TurboJPEG function, and this usually caused stack corruption in the calling program (because the signature and return type of the previous TurboJPEG function probably wasn't the same as that of tjDecompressToYUV2().)
At one time, it was possible to use CMake to build under Cygwin, but that hasn't worked since 1.4.1 (due to the Huffman codec changes that now require SIZEOF_SIZE_T to be defined for non-WIN32 platforms) and may have even been broken before that. Originally, we used the "date" command under MSYS in order to obtain the default build number, but that was rendered unnecessary by 5e3bb3e (v1.3 beta.) 9fe22da (1.4 beta) further modified CMakeLists.txt so that the "date" command was only used on Cygwin, but for unexplained reasons, that commit also applied the (now vestigial) code to all non-WIN32 platforms. This prevented CMakeLists.txt from displaying an error if someone attempted to use the CMake build system on Un*x platforms, and that may have been behind the flurry of pull requests and issues-- including mozilla#21, mozilla#29, mozilla#37, mozilla#58, mozilla#73-- complaining that the CMake build system didn't work on Un*x platforms (although it was not until mozilla#73 that this bug came to light.) This commit removes all vestiges of Un*x support from the CMake build system and makes it clear that CMake cannot be used to build libjpeg-turbo on non-WIN32 platforms. It is our position that CMake will not be supported on non-WIN32 platforms until/unless the autotools build system is removed, and this will not happen without broad support from the community (including major O/S vendors.) If you are in favor of migrating the entire build system to CMake, then please make your voice heard by commenting on mozilla#56.
…turbo * commit 'eca0637c8150d3d1c08a60c64d7ee16eaea4b198': Remove trailing spaces Another oops. tjBufSizeYUV2() should return -1 if width < 1. Oops. tjPlaneSizeYUV() should return -1 if componentID > 0 and subsamp==TJSAMP_GRAY. When building libjpeg-turbo on Un*x systems, INT32 is usually typedef'ed to long, not int, so we need to specify an int pointer when doing a 4-byte write to the RGB565 output buffer. On little endian systems, this doesn't matter, but when you write a 32-bit int to a 64-bit long pointer address on a big endian system, you are writing to the upper 4 bytes, not the lower 4 bytes. NOTE: this will probably break on big endian systems that use 16-bit ints (are there any of those still around?) Fix Windows build Fix issues with RGB565 color conversion on big endian machines. The RGB565 routines are now abstracted in a separate file, with separate little-endian and big-endian versions defined at compile time through the use of macros (this is similar to how the colorspace extension routines work.) This allows big-endian machines to take advantage of the same performance optimizations as little-endian machines, and it retains the performance on little-endian machines, since the conditional branch for endianness is at a very coarse-grained level. Fix build on OS X PowerPC platforms Oops. Forgot to alter the version header in the change log to indicate the release of 1.4 beta. Create 1.4.x branch
* origin/master: (108 commits) Bump version number to 3.1. jpegyuv: fix memory leak when path is invalid jpegyuv: fix memory leak when @image_buffer allocation fails yuvjpeg: fix memory leak when @image_buffer allocation fails jpegtran: Do not leak the input and output buffers Fix previous commit Scan optimization: return error when unable to copy data buffer cjpeg option for baseline quant tables Fix mozilla#153 rdpng: convert 16-bit input to 8-bit Larger number of DC trellis candidates Fix overflow issue mozilla#157 Const on getters Const on simple getters and copy source Expanded .gitignore Add pkg-config requirement Re-order links. Declare inbuffer const Oops. Delete the duplicate copy of [lib]turbojpeg.dll in the binary directory when uninstalling the package. Get rid of changelog file that we don't update. ...
Tag 1.4.1 release
* tag '1.4.1': (427 commits)
Now that the TurboJPEG API is reporting libjpeg warnings as errors, an "Invalid SOS parameters for sequential JPEG" warning surfaced in tjDecodeYUV*(). This was caused by the Se member of jpeg_decompress_struct being set to 0 (it is normally set to a non-zero value when the start-of-scan markers are read, but there are no SOS markers in this case, because we're not actually decompressing a JPEG file.)
Fix a segfault that occured in the MIPS DSPr2 fancy upsampling routine when downsampled_width==3. Because the DSPr2 code unrolls the loop for the middle columns (refer to jdsample.c), it has the effect of performing two column iterations, and that only works properly if the number of columns (minus the first and last) is >= 2. For the specific case of downsampled_width==3, this patch skips to the second iteration of the unrolled column loop.
If a warning (such as "Premature end of JPEG file") is triggered in the underlying libjpeg API, make sure that the TurboJPEG API function returns -1. Unlike errors, however, libjpeg warnings do not make the TurboJPEG functions abort.
Back out r1555 and r1548. Using setenv() didn't fix the iOS simulator issue. It just replaced an undefined _putenv$UNIX2003 symbol with an undefined _setenv$UNIX2003 symbol. The correct solution seems to be to use -D_NONSTD_SOURCE when generating our official builds.
Fix the Windows build. I remember now why I used putenv() originally-- because Windows doesn't have setenv(). We could use _putenv_s(), but older versions of MinGW don't have that either. Fortunately, since all of the environment values we're setting in turbojpeg.c are static, we can just map setenv() to putenv() using a macro. NOTE: we still have to use _putenv_s() in turbojpeg-jni.c, but at least people who may need to build with an older version of MinGW can still do so by disabling the Java build.
Allow building only static or only shared libraries on Windows
__WORDSIZE doesn't seem to be available on platforms other than Mac or Linux, and best practices are for user-level code not to rely on it anyhow, since it's meant to be an internal macro. Fortunately, autoconf already has a way of determining the word size at configure time, so it can be passed into the compiler. This should work on any platform and has been tested on all of the Un*x platforms we support (Linux, Mac, FreeBSD, Solaris.)
Unless you define _ANSI_SOURCE, then putenv() on Mac is renamed to putenv$UNIX2003(), and this causes problems when trying to link an i386 iOS application (for the simulator) against the TurboJPEG static library. It's easiest to just use setenv() instead.
Fix a bug in the 64-bit Huffman encoder that Google discovered when encoding some very specific (and proprietary) aerial images using quality=98, an optimized Huffman table, and the ISLOW DCT. These images were causing the Huffman bit buffer to overflow, because the code for encoding the DC coefficient was using the equivalent of the 32-bit version of EMIT_BITS(). Thus, when 64-bit code was used, the DC coefficient code was not properly checking how many bits were in the buffer before attempting to add more bits to it. This issue appears to have existed in all versions of libjpeg-turbo.
Restore backward compatibility with MSVC < 2010 (broken by r1541)
Oops. OS X doesn't define __WORDSIZE unless you include stdint.h, so apparently the Huffman codec hasn't ever been fully accelerated on 64-bit OS X.
Allow the executables and libraries outside of the sharedlib/ directory to be linked against msvcr*.dll instead of libcmt*.lib. This is reported to be necessary when building libjpeg-turbo for use with C#.
Surround the usage of getenv() in the TurboJPEG API with #ifndef NO_GETENV so that developers can add -DNO_GETENV to the C flags when building for platforms that don't have getenv(). Currently this is known to be necessary when building for Windows Phone.
If libjpeg-turbo is configured with a non-default prefix, such as /usr, then use the docdir variable defined by autoconf 2.60 and later, if available. This will, for instance, install the documentation under /usr/share/doc/libjpeg-turbo by default if prefix=/usr, unless docdir is overridden. When using earlier versions of autoconf, docdir is set to ${datadir}/doc, as it always has been.
Enable silent build rules for the NASM objects, if the source is configured with automake 1.11 or later. NOTE: the build still spits out "error: ignoring unknown tag NASM" for each object, but unfortunately, if we remove "--tag NASM" from the command line, the build breaks under older versions of automake (it aborts with "unable to infer tagged configuration.")
Set the RPM and deb architecture properly on non-x86 platforms.
Come on, Cohaagen, you got what you want. Give these people air!
Oops. Need to set the alpha channel when using TYPE_4BYTE_ABGR*. This has no bearing on the actual tests, but it prevents the PNG pre-encode reference images for those tests from being blank.
Oops. The MIPS SIMD implementations of h2v1 and h2v2 upsampling were not checking for DSPr2 support, so running 'djpeg -nosmooth' on a non-DSPr2-enabled platform caused an "illegal instruction" error.
Introduce fast paths to speed up NULL color conversion somewhat, particularly when using 64-bit code; on the decompression side, the "slow path" also now use an approach similar to that of the compression side (with the component loop outside of the column loop rather than inside.) This is faster when using 32-bit code.
...
* libjpeg-turbo/1.4.x: (94 commits) CMakeLists.txt: Clarify that Un*x isn't supported Catch libjpeg errors in tjDecompressToYUV2() cjpeg: Fix buf overrun caused by bad bin PPM input Add version/build info to global string table Ensure that default Huffman tables are initialized Fix memory leak when running tjunittest -yuv Prevent overread when decoding malformed JPEG Guard against wrap-around in alloc functions Fix Visual C++ compiler warnings rdppm.c: formatting tweaks jmemmgr.c: formatting tweaks TurboJPEG: Avoid dangling pointers Update Android build instr. for ARMv8, PIE, etc. Makefile.am: formatting tweak Update build instructions for new autoconf, GitHub 1.4.3 Regression: Allow co-install of 32-bit/64-bit RPMs Build: Use FILEPATH type for NASM CMake variable Comment formatting tweaks Fix 'make dist' ...
* libjpeg-turbo/master: (140 commits) Increase severity of tjDecompressToYUV2() bug desc Catch libjpeg errors in tjDecompressToYUV2() BUILDING.md: Fix "... OR ..." indentation again BUILDING.md: Fix confusing Windows build reqs ChangeLog.md: Improve readability of plain text change.log: Refer users to ChangeLog.md Markdown version of ChangeLog.txt Rename ChangeLog.txt README.md: Link to BUILDING.md BUILDING.md and README.md: Cosmetic tweaks ChangeLog: "1.5 beta1" --> "1.4.90 (1.5 beta1)" Java: Fix parallel make with autotools Win/x64: Fix improper callee save of xmm8-xmm11 Bump TurboJPEG C API revision to 1.5 ChangeLog: Mention jpeg_crop_scanline() function 1.5 beta1 Fix v7/v8-compatible build libjpeg API: Partial scanline decompression Build: Make the NASM autoconf variable persistent Use consistent/modern code formatting for dbl ptrs ...
|
I've discussed this with @bdaehlie. The plan is to make a release once libjpeg-turbo 1.5 is out. This brings commits up to libjpeg-turbo 1.4.2. It will make it easier to merge in libjpeg-turbo 1.5 once that is out, because the difference between branches will be smaller. Incremental approach to merging may also help diagnose potential problems, because we'll have several merge commits along the way to bisect, so it'll be easier to investigate regressions than with just one massive merge. |
|
Hi, is there an estimate when this is going to be released? |
|
When libjpeg-turbo 1.5 is released. |
|
@thisconnect I saw that you originally said "when this is going to be released in", and I came to this thread to see that you actually corrected it. For some reason, that made me pretty happy. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Brings mozjpeg up to date with libjpeg-turbo up to commit 346837c
Fixes #202
The large number of commits is due to bringing git history of the official libjpeg-turbo repo (the increase in repository size is not as big, because git stores all files' data only once). This will make merging of future changes from libjpeg-turbo easier, and obsoletes previous complicated git-svn workflow.
All unit tests pass, and all mozjpeg-optimized files are the same. A workaround is needed for the buffer size test to run in reasonable time #201, but this is not a new problem.