|
163f0b19
|
2019-10-22T19:39:38
|
|
Bump version to 2.0.4 to prepare for new commits
|
|
b4110b65
|
2019-09-04T18:58:12
|
|
Merge branch 'master' into dev
|
|
ded5a504
|
2019-08-15T13:24:25
|
|
tjDecodeYUV*: Fix err if TJ inst used for prog dec
If the TurboJPEG instance passed to tjDecodeYUV[Planes]() was previously
used to decompress a progressive JPEG image, then we need to disable the
progressive decompression parameters in the underlying libjpeg instance
before calling jinit_master_decompress().
This commit also modifies the build system so that the "tjtest" target
will test for this issue, and it corrects a previous oversight in the
build system whereby tjbenchtest did not test progressive
compression/decompression unless WITH_JAVA was true.
|
|
8ef53b10
|
2019-08-14T22:08:59
|
|
Merge branch 'master' into dev
|
|
a81a8c13
|
2019-08-14T13:17:11
|
|
SSE2 SIMD: Fix prog Huffman enc. error if Sl%16==0
(regression introduced by 5b177b3cab5cfb661256c1e74df160158ec6c34e)
The SSE2 implementation of progressive Huffman encoding performed
extraneous iterations when the scan length was a multiple of 16.
Based on:
https://github.com/rouault/libjpeg-turbo/commit/bb7f1ef98305da915e581b59bd0ec2ef7bdb8468
Fixes #335
Closes #367
|
|
7fbfe29c
|
2019-07-18T15:18:27
|
|
Merge branch 'master' into dev
|
|
f37b7c1f
|
2019-07-02T11:28:26
|
|
Build: Fix build/install with Xcode IDE
Closes #355
|
|
58a3975e
|
2019-04-10T14:35:45
|
|
Bump version to 2.0.3 to prepare for new commits
|
|
a9075a17
|
2019-02-12T13:42:57
|
|
Merge branch 'master' into dev
|
|
75be88cf
|
2019-02-11T13:10:09
|
|
Build: Optionally install PDB files for MSVC DLLs
Based on
https://github.com/Youw/libjpeg-turbo/commit/333a36ae984a52e547ddeb23848873d3cc798047
Closes #329
Closes #324
|
|
674343ab
|
2019-01-31T15:30:25
|
|
Merge branch 'master' into dev
|
|
2d0b675a
|
2019-01-25T16:46:02
|
|
Build: Fix install of static build w/ VStudio IDE
Unfortunately, this hack is necessary because:
- install(TARGETS, ...) doesn't support the RENAME option.
- We can't modify OUTPUT_NAME for the "-static" targets without breaking
the regression tests.
- ${CMAKE_CFG_INTDIR} doesn't seem to work properly in an install()
command.
Refer to #307
|
|
01e30323
|
2019-01-23T14:58:24
|
|
Eliminate support for compilers w/o unsigned char
libjpeg-turbo has never really supported such compilers, since (AFAIK)
they are non-existent on any modern computing platform and thus
impossible for us to test. (Also, the TurboJPEG API would break without
unsigned chars.)
Furthermore, the unified CMake-based build system introduced in 2.0
always defines HAVE_UNSIGNED_CHAR, so retaining other code paths is
pointless. Eliminating support for compilers without unsigned char
eliminates the need for the GETJSAMPLE() macro, which improves the
readability of many parts of the code as well as improving the
performance of writing Targa and Windows BMP files.
Fixes #317
|
|
42d62bf1
|
2019-01-23T11:20:11
|
|
Merge branch 'master' into dev
|
|
ce90ab5d
|
2019-01-21T22:56:56
|
|
Build: Fix regression test failure w/ ctest -j
The djpeg rgb-islow-icc-cmp test must run after the djpeg rgb-islow
test, since the latter generates testout_rgb_islow.icc.
|
|
12f3d0be
|
2019-01-01T21:52:21
|
|
Merge branch 'master' into dev
|
|
c868e41b
|
2019-01-01T14:26:48
|
|
Build: Fix regr. that nuked RPATH in Mac/iOS build
Caused by 950580eb0c020598a4c6c8aa46c86e31062e1ddc. Since the code that
sets CMAKE_INSTALL_RPATH now depends on ENABLE_SHARED, that code needed
to be moved to after the point at which ENABLE_SHARED is defined.
|
|
0696b0a4
|
2019-01-01T13:55:01
|
|
Bump version to 2.0.2 to prepare for new commits
|
|
43ce78e0
|
2018-11-15T11:54:20
|
|
Build: Fix issue with HAVE_MAPFILE test on Solaris
We have to link the test code into a shared library, or else the mapfile
prevents necessary libc symbols from being exposed.
|
|
2cc4f93c
|
2018-11-12T14:40:19
|
|
Merge branch 'master' into dev
|
|
950580eb
|
2018-11-12T11:22:07
|
|
Build: Fix install error with fully static build
Closes #273
|
|
504a295c
|
2018-10-11T15:13:34
|
|
Include .pc files in LJT SDKs for Visual C++
These are apparently useful in certain esoteric build environments.
Closes #296
|
|
133e4af0
|
2018-09-04T16:56:22
|
|
Add x32 ABI support on Linux
The x32 ABI is similar to the x86-64 ABI but uses 32-bit pointers.
(Refer to https://sites.google.com/site/x32abi)
Based on:
https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/8da8fc5213d87336d6c7200aaeeca925603e12cf
https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/1e33dfea8042230e266b453f53d69a6e37b7f0de
https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/24ffea78da0f18d0d467d16e02dfb903e6c0181e
https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/dedcf76753c8913ef5c3c6e4ea329d29494b6065
https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/d04228a7b58b9aed5bcbec383630ec1a14a3c9ca
https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/b4ad38316ae1899c8a00b6568bb0325d82edcd7a
Closes #274
|
|
995eb29d
|
2018-09-04T16:57:52
|
|
Bump version to 2.1 alpha1
(to prepare for new features)
|
|
a861cc2f
|
2018-08-31T12:54:09
|
|
Bump version to 2.0.1 to prepare for new commits
|
|
ad6c3161
|
2018-07-25T11:03:20
|
|
Bump revision to 2.0.0
|
|
8d95be3a
|
2018-07-24T21:16:00
|
|
Build: Don't use @rpath with OS X 10.4 builds
@rpath is only supported with 10.5 and later deployment targets.
libjpeg-turbo hasn't supported 10.4 "Tiger" since prior to 1.4, but I
still sometimes use the 10.4 SDK to test PowerPC code in a Snow Leopard
VM.
|
|
0fa7850a
|
2018-07-20T11:30:04
|
|
Build: Preserve CMake exe suffix from cmd line
Normally the value of CMAKE_EXECUTABLE_SUFFIX is clobbered by project().
This allows for specifying an executable suffix of .html with Emscripten
builds, which causes Emscripten to build standalone HTML versions of the
libjpeg-turbo test programs.
|
|
0c8eb5b4
|
2018-07-19T17:01:42
|
|
Honor CMake exe suffix when inst. static builds
This specifically allows an Emscripten (WASM) static build (for which
CMAKE_EXECUTABLE_SUFFIX=.js) to be properly installed.
|
|
34e9d7e3
|
2018-04-26T17:33:52
|
|
Bump revision to 1.5.91 for post-beta fixes
|
|
13e4803e
|
2018-03-31T16:19:01
|
|
Fix build errors when C flags include -Werror
Instructing the compiler to treat warnings as errors caused some of the
compiler tests to fail, because the test code was not 100% clean.
Note that we now use check_symbol_exists() to check for memset() and
memcpy(), since the test code for check_function_exists() produces a
compiler warning due to not including <string.h>.
|
|
a74655af
|
2018-03-31T15:34:23
|
|
CMakeLists.txt: Move intrin.h header check
It is more readable for this to be next to the __builtin_ctzl() check,
since both are used by the accelerated progressive Huffman code.
|
|
c80ddef7
|
2018-03-23T23:17:08
|
|
Build: Fix rpath in iOS shared libraries
When attempting to configure an iOS/ARM build with Xcode 7.2 and CMake
2.8.12, I got the following errors:
CMake Error at CMakeLists.txt:560 (add_library):
Attempting to use MACOSX_RPATH without CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG
being set. This could be because you are using a Mac OS X version less
than 10.5 or because CMake's platform configuration is corrupt.
(x 3)
CMake Error at sharedlib/CMakeLists.txt:38 (add_library):
Attempting to use MACOSX_RPATH without CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG
being set. This could be because you are using a Mac OS X version less
than 10.5 or because CMake's platform configuration is corrupt.
(x 3)
Upgrading to CMake 3.x (tried 3.0 and 3.1) got rid of the errors, but
the resulting shared libs still did not use @rpath as expected. Note
also that CMake 3.x (at least the two versions I tested) does not
automatically set the MACOSX_RPATH property as claimed. I could find
nothing in the release notes for later CMake releases to indicate that
either problem has been fixed. What I did find was this little nugget
of code in the Darwin platform module:
https://github.com/Kitware/CMake/blob/f6b93fbf3ae00a9157af2f6497bed074d585cea9/Modules/Platform/Darwin.cmake#L33-L36
This sets CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG="-Wl,-rpath," only if you
are running OS X 10.5 or later. It makes no such check for iOS, perhaps
because shared libraries aren't much of a thing with iOS apps. In any
event, this commit simply sets CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG if it
isn't set already, and that fixes all of the aforementioned problems.
|
|
e15a6b4e
|
2018-03-23T11:14:50
|
|
Include .pc and man files in MinGW install[er]s
These files are potentially useful to MinGW users, since MSYS2 MinGW
environments have a man command by default and provide an easy way to
install pkg-config.
Closes #223
|
|
1095b822
|
2018-03-22T16:08:25
|
|
Bump revision to 1.5.90 to prepare for beta
|
|
16bd9845
|
2018-03-02T22:33:19
|
|
C/SSE2 optimization of encode_mcu_AC_refine()
This commit adds C and SSE2 optimizations for the encode_mcu_AC_refine()
function used in progressive Huffman encoding.
The image used for testing can be retrieved from this page:
https://blog.cloudflare.com/doubling-the-speed-of-jpegtran
All timings done on `Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz`
clang version is `Apple LLVM version 9.0.0 (clang-900.0.39.2)`
gcc-5 version is `gcc-5 (Homebrew GCC 5.5.0) 5.5.0`
gcc-7 version is `gcc-7 (Homebrew GCC 7.2.0) 7.2.0`
Here are the results in comparison to libjpeg-turbo@3c54642 using
`time ./jpegtran -outfile /dev/null -progressive -optimise -copy none print_poster_0025.jpg`
C
clang x86_64: +7%
gcc-5 x86_64: +30%
gcc-7 x86_64: +33%
clang i386: +0%
gcc-5 i386: +24%
gcc-7 i386: +23%
SSE2
clang x86_64: +42%
gcc-5 x86_64: +53%
gcc-7 x86_64: +64%
clang i386: +35%
gcc-5 i386: +46%
gcc-7 i386: +49%
Discussion in libjpeg-turbo/libjpeg-turbo#46
|
|
4e240795
|
2018-02-13T16:34:21
|
|
Merge branch 'master' into dev
|
|
d4859558
|
2018-02-13T16:14:03
|
|
Fix dithering bug in merged 4:2:0/RGB565 algorithm
d0 should always be used for the first row, and d1 should always be used
for the second row.
Addresses concerns raised in #95, #81.
|
|
0fba3c19
|
2017-12-15T20:05:58
|
|
Bump version to 1.5.4 to prepare for new commits
|
|
8c40ac8a
|
2017-11-16T18:46:01
|
|
Add TurboJPEG C example and clean up Java example
Also rename example.c --> example.txt and add a disclaimer to that file
so people will stop trying to compile it.
|
|
aa745905
|
2017-11-16T18:09:07
|
|
TurboJPEG C API: Add BMP/PPM load/save functions
The main justification for this is to provide new libjpeg-turbo users
with a quick & easy way of developing a complete JPEG
compression/decompression program without requiring them to build
libjpeg-turbo from source (which was necessary in order to use the
project-private bmp API) or to use external libraries. These new
functions build upon significant enhancements to rdbmp.c, wrbmp.c,
rdppm.c, and wrppm.c which allow those engines to convert directly
between the native pixel format of the file and a pixel format
("colorspace" in libjpeg parlance) specified by the calling program.
rdbmp.c and wrbmp.c have also been modified such that the calling
program can choose to read or write image rows in the native (bottom-up)
order of the file format, thus eliminating the need to use an inversion
array. tjLoadImage() and tjSaveImage() leverage these new underlying
features in order to significantly improve upon the performance of the
old bmp API.
Because these new functions cannot work without the libjpeg-turbo
colorspace extensions, the libjpeg-compatible code in turbojpeg.c has
been removed. That code was only there to serve as an example of how
to use the TurboJPEG API on top of libjpeg, but more specific, buildable
examples now exist in the https://github.com/libjpeg-turbo/ijg
repository.
|
|
087ec126
|
2017-11-15T20:50:53
|
|
tjbenchtest: Test new TurboJPEG progressive flag
|
|
cd8a1258
|
2017-11-15T09:19:27
|
|
Build: Fix 'tjtest' target on Windows
tjbenchtest and its Java derivatives are useful for rooting out hidden
problems with the more esoteric TJBench and TurboJPEG features. For
instance, on Windows, running tjbenchtest uncovered
5fce2e942136cb70e5a30ff15a2d58b07947aa84.
This commit also causes tjbenchtest and tjbenchtest.java to append -yuv
and -alloc to their log file names, depending on the arguments passed,
and it causes the build system to clean up those log files when the
'testclean' target is built.
|
|
14783612
|
2017-08-14T11:18:35
|
|
Bump version to 1.5.3 to prepare for new commits
|
|
dedce66e
|
2017-06-28T15:30:41
|
|
Merge branch 'master' into dev
|
|
b9ab64d8
|
2017-05-11T21:02:29
|
|
TurboJPEG: Thread-safe error message retrieval
Introduce a new C API function (tjGetErrorStr2()) that can be used to
retrieve compression/decompression/transform error messages in a
thread-safe (i.e. instance-specific) manner. Retrieving error messages
from global functions is still thread-unsafe.
Addresses a concern expressed in #151.
|
|
44b2399a
|
2017-01-19T15:18:57
|
|
libjpeg API: Support reading/writing ICC profiles
This commit does the following:
-- Merges the two glueware functions (read_icc_profile() and
write_icc_profile()) from iccjpeg.c, which is contained in downstream
projects such as LCMS, Ghostscript, Mozilla, etc. These functions were
originally intended for inclusion in libjpeg, but Tom Lane left the IJG
before that could be accomplished. Since then, programs and libraries
that needed to embed/extract ICC profiles in JPEG files had to include
their own local copy of iccjpeg.c, which is suboptimal.
-- The new functions were prefixed with jpeg_ and split into separate
files for the compressor and decompressor, per the existing libjpeg
coding standards.
-- jpeg_write_icc_profile() was made slightly more fault-tolerant.
It will now trigger a libjpeg error if it is called before
jpeg_start_compress() or if it is passed NULL arguments.
-- jpeg_read_icc_profile() was made slightly more fault-tolerant.
It will now trigger a libjpeg error if it is called before
jpeg_read_header() or if it is passed NULL arguments. It will also
now trigger libjpeg warnings if the ICC profile data is corrupt.
-- The code comments have been wordsmithed.
-- Note that the one-line setup_read_icc_profile() function was not
included. Instead, libjpeg.txt now documents the need to call
jpeg_save_markers(cinfo, JPEG_APP0 + 2, 0xFFFF) prior to calling
jpeg_read_header(), if jpeg_read_icc_profile() is to be used.
-- Adds documentation for the new functions to libjpeg.txt.
-- Adds an -icc switch to cjpeg and jpegtran that allows those programs
to embed an ICC profile in the JPEG files they generate.
-- Adds an -icc switch to djpeg that allows that program to extract an
ICC profile from a JPEG file while decompressing.
-- Adds appropriate unit tests for all of the above.
-- Bumps the SO_AGE of the libjpeg API library to indicate the presence
of new API functions.
Note that the licensing information was obtained from:
https://github.com/mm2/Little-CMS/issues/37#issuecomment-66450180
|
|
6530203f
|
2016-12-09T10:21:29
|
|
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.
|
|
c8358fcb
|
2016-12-08T14:43:59
|
|
Build: Various improvements to install/pkg system
- GNUInstallDirs: any directory variable can now reference any other
directory variable by including its name in angle brackets (<>).
- Changed the documentation of the directory variables in BUILDING.md
accordingly. This commit also includes some formatting tweaks to
that section (using boldface for directory names, as is our
convention.)
- Changed the package scripts such that they use
CMAKE_INSTALL_DATAROOTDIR rather than CMAKE_INSTALL_DATADIR.
- We no longer override the install dir. defaults on Windows unless
performing an official build. It may be useful, for instance, to
use the GNU defaults when installing into an MSYS environment.
|
|
b0fcd0cc
|
2016-12-07T19:14:20
|
|
Build: Minor tweaks to GNUInstallDirs defaults
It isn't actually necessary to specify `CMAKE_INSTALL_DEFAULT_MANDIR`
for our official build. Because `CMAKE_INSTALL_DEFAULT_DATAROOTDIR` is
blank for the official build, the default of "<DATAROOTDIR>/man" will
resolve to "man".
For the same reason, this commit changes the specification of
`CMAKE_INSTALL_DEFAULT_DOCDIR` and `CMAKE_INSTALL_DEFAULT_JAVADIR` in
the official build to be dependent on the data root directory (mainly to
make it obvious what we're doing.)
This commit also tweaks the example CMake command line in the directory
variable documentation so that it shows the correct location of the
CMake argument.
|
|
d681fa76
|
2016-12-07T10:54:54
|
|
Build: Set install dirs in a more GNU-friendly way
This builds upon the existing GNUInstallDirs module in CMake but adds
the following features to that module:
- The ability to override the defaults for each install directory
through a new set of variables (`CMAKE_INSTALL_DEFAULT_*DIR`).
Before operating system vendors began shipping libjpeg-turbo, it was
meant to be a run-time drop-in replacement for the system's
distribution of libjpeg, so it has traditionally installed itself
under /opt/libjpeg-turbo on Un*x systems by default. On Windows, it
has traditionally installed itself under %SystemDrive%\libjpeg-turbo*,
which is not uncommon behavior for open source libraries (open source
SDKs tend to install outside of the Program Files directory so as to
avoid spaces in the directory name.) At least in the case of Un*x,
the install directory behavior is based somewhat on the Solaris
standard, which requires all non-O/S packages to install their files
under /opt/{package_name}. I adopted that standard for VirtualGL and
TurboVNC while working at Sun, because it allowed those packages to be
located under the same directory on all platforms. I adopted it for
libjpeg-turbo because it ensured that our files would never conflict
with the system's version of libjpeg. Even though many Un*x
distributions ship libjpeg-turbo these days, not all of them ship the
TurboJPEG API library or the Java classes or even the latest version
of the libjpeg API library, so there are still many cases in which it
is desirable to install a separate version of libjpeg-turbo than the
one installed by the system. Furthermore, installing the files under
/opt mimics the directory structure of our official binary packages,
and it makes it very easy to uninstall libjpeg-turbo.
For these reasons, our build system needs to be able to use
non-GNU-compliant defaults for each install directory if
`CMAKE_INSTALL_PREFIX` is set to the default value.
- For each directory variable, the module now detects changes to
`CMAKE_INSTALL_PREFIX` and changes the directory variable accordingly,
if the variable has not been changed by the user.
This makes it easy to switch between our "official" directory
structure and the GNU-compliant directory structure "on the fly"
simply by changing `CMAKE_INSTALL_PREFIX`. Also, this new mechanism
eliminated the need for the crufty mechanism that previously did the
same thing just for the library directory variable.
How it should work:
- If a dir variable is unset, then the module will set an internal
property indicating that the dir variable was initialized to its
default value.
- If the dir variable ever diverges from its default value, then the
internal property is cleared, and it cannot be set again without
unsetting the dir variable.
- If the install prefix changes, and if the internal property
indicates that the dir variable is still set to its default value,
and if the dir variable's value is not being manually changed at the
same time that the install prefix is being changed, then the dir
variable's value is automatically changed to the new default value
for that variable (as determined by the new install prefix.)
- The directory variables are now always cached, regardless of whether
they were set on the command line or not. This ensures that they can
easily be examined and modified after being set, regardless of how they
were set.
This was made possible by the introduction of the aforementioned
`CMAKE_INSTALL_DEFAULT_*DIR` variables.
- Improved directory variable documentation (based on descriptions at
https://www.gnu.org/prep/standards/html_node/Directory-Variables.html)
- The module now allows "<DATAROOTDIR>" to be used as a placeholder in
relative directory variables.
It is replaced "on the fly" with the actual path of
`CMAKE_INSTALL_DATAROOTDIR`.
This should more closely mimic the behavior of the old autotools build
system while retaining our customizations to it, and it should retain
the behavior of the old CMake build system.
Closes #124
|
|
2af2fe42
|
2016-12-05T16:52:54
|
|
Build: Clean up inline keyword detection
Strict C89-conformant compilers don't support the "inline" keyword, but
most of them support "__inline__", and that keyword can be used with the
always_inline atribute as well. This commit also removes duplicate code
by using a foreach() loop to test the various keywords.
|
|
952191da
|
2016-12-03T14:21:11
|
|
Build: Fix issues when building as a Git submodule
- Replace CMAKE_SOURCE_DIR with CMAKE_CURRENT_SOURCE_DIR
- Replace CMAKE_BINARY_DIR with CMAKE_CURRENT_BINARY_DIR
- Don't use "libjpeg-turbo" in any of the package system filenames
(because CMAKE_PROJECT_NAME will not be the same if building LJT as
a submodule.)
Closes #122
|
|
d642da75
|
2016-12-03T13:38:21
|
|
Build: Fix buglet in output of `make tjtest`
|
|
27d4c5ea
|
2016-11-23T17:12:57
|
|
Build: Fix RPATH handling
CMAKE_INSTALL_RPATH has to be set before the targets are defined (oops.)
This also explicitly turns on MACOSX_RPATH for the shared libraries
(which is the default with newer versions of CMake but not with 2.8.x.)
The old autotools/libtool build system hard-coded the install name
directory of the OS X shared libraries to libdir, which meant that any
executable that linked against those libraries would also be hard-coded
to look for the libjpeg-turbo libraries in that directory. @rpath makes
the OS X version of libjpeg-turbo behave like the Linux version, in the
sense that the executables under /opt/libjpeg-turbo/bin will
automatically pick up the libraries under /opt/libjpeg-turbo/lib* by
default, but other executables won't unless they are linked with -rpath.
|
|
6abd3916
|
2016-11-15T08:47:43
|
|
Unified CMake-based build system
See #56 for discussion.
Fixes #21, Fixes #29, Fixes #37, Closes #56, Fixes #58, Closes #73
Obviates #82
See also:
https://sourceforge.net/p/libjpeg-turbo/feature-requests/5/
https://sourceforge.net/p/libjpeg-turbo/patches/5/
|
|
9fdb8f85
|
2016-11-22T09:33:19
|
|
Merge branch 'master' into dev
|
|
3da94de2
|
2016-11-20T19:10:54
|
|
Windows build: Add an "uninstall" target
|
|
6aae0077
|
2016-11-15T08:37:04
|
|
CMake build system: Fix the "testclean" target
Regression caused by f9134384b728d8943f252b27464d83c4b7b2d159
This commit also makes the "testclean" target clean up the 4:1:1 test
images. This was implemented in the autotools build system in
1f3635c4969f2319a01c9fe561958815b733227f but was left out of the CMake
build system due to an oversight.
|
|
ed21f4bd
|
2016-10-05T14:41:14
|
|
Merge branch 'master' into dev
|
|
1625253d
|
2016-10-04T13:41:48
|
|
Fix 32-bit non-SIMD FP regression tests
- Introduce a new FLOATTEST value ("387") on Un*x systems that will
compare the floating point DCT/IDCT algorithms against the expected
results from the C algorithms when built using 32-bit code and
-mfpmath=387.
- Extend the Windows regression tests so that they work properly when
building libjpeg-turbo with 32-bit code and without SIMD, using either
Visual C++ (tested with 2008, 2010, 2015) or MinGW.
|
|
4cf67f23
|
2016-09-22T14:14:05
|
|
Bump version to 1.5.2 to prepare for new commits
|
|
9e6c6a14
|
2016-07-06T16:22:27
|
|
Bump version to 1.5.1 to prepare for new commits
|
|
6cb27c31
|
2016-05-09T20:28:17
|
|
Bump version to 1.6 alpha1
(to prepare for new features)
|
|
3ff13e65
|
2016-05-31T22:53:17
|
|
1.5.0
|
|
f06cc120
|
2016-05-10T19:36:34
|
|
Build: Add integer version macro to jconfig.h
This makes it significantly easier to do conditional compilation based
on the libjpeg-turbo version.
Based on:
https://github.com/hasinoff/libjpeg-turbo/commit/e6d5b3e50b8b07488cb7b4d26ab2061685bc6875
https://github.com/hasinoff/libjpeg-turbo/commit/1394a89ba6f3cd8abb556c1b65bac4a5f09760d0
Closes #80
|
|
5c064de1
|
2016-05-09T20:00:46
|
|
Build: Don't allow jpeg-7+ emul. w/o arith coding
The jpeg-7/jpeg-8 APIs/ABIs require arithmetic coding, and the jpeg-8
API/ABI requires the memory source/destination manager, so this commit
causes the build system to ignore --with-arith-enc/--without-arith-enc
and --with-arith-dec/--without-arith-dec (and the equivalent CMake
variables-- WITH_ARITH_ENC and WITH_ARITH_DEC) when v7/v8 API/ABI
emulation is enabled. Furthermore, the CMake build system now ignores
WITH_MEM_SRCDST whenever WITH_JPEG8 is specified (the autotools build
system already did that.)
|
|
0d61e80a
|
2016-05-01T12:07:05
|
|
Merge branch '1.4.x'
|
|
ee681aa3
|
2016-05-01T11:42:15
|
|
Fix CMake fallback BUILD var on non-U.S. machines
If wmic.exe wasn't available, then CMakeLists.txt would call
"cmd /C date /T" and parse the result in order to set the BUILD
variable. However, the parser assumed that the date was in MM/DD/YYYY
format, which is not generally the case unless the user's locale is U.S.
English with the default region/language settings for that locale.
This commit modifies CMakeLists.txt such that it uses the
string(TIMESTAMP) function available in CMake 2.8.11 and later to set
the BUILD variable, thus eliminating the need to use wmic.exe or any
other platform-specific hack.
This commit also modifies the build instructions to remove any reference
to CMake 2.6 (which hasn't been supported by our build system since
libjpeg-turbo 1.3.x.)
Closes #74
|
|
346837ca
|
2016-04-25T19:08:47
|
|
Merge branch '1.4.x'
|
|
eb7962a0
|
2016-04-25T18:16:46
|
|
CMakeLists.txt: Clarify that Un*x isn't supported
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 5e3bb3e9 (v1.3 beta.) 9fe22dac (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 #21, #29, #37, #58, #73--
complaining that the CMake build system didn't work on Un*x platforms
(although it was not until #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 #56.
|
|
2354810a
|
2016-02-29T11:12:44
|
|
1.5 beta1
|
|
3ab68cf5
|
2016-02-19T18:32:10
|
|
libjpeg API: Partial scanline decompression
This, in combination with the existing jpeg_skip_scanlines() function,
provides the ability to crop the image both horizontally and vertically
while decompressing (certain restrictions apply-- see libjpeg.txt.)
This also cleans up the documentation of the line skipping feature and
removes the "strip decompression" feature from djpeg, since the new
cropping feature is a superset of it.
Refer to #34 for discussion.
Closes #34
|
|
03841e6e
|
2016-02-09T18:27:27
|
|
Win: Display effective C/LD flags in CMake output
|
|
f9134384
|
2016-02-06T14:09:20
|
|
Win: Enable testing cross-compiled builds
When cross-compiling, CMakeLists.txt now generates the CTest script
using relative paths, so that CTest can more easily be executed on a
different machine from the build machine. Furthermore, Windows builds
are now tested using md5cmp, just like on Linux, rather than a CMake
script. This prevents issues with differing CMake locations between
the build and test machines.
This also removes some trailing spaces from the md5cmp code and improves
the readability of the test code in CMakeLists.txt.
|
|
e7f14185
|
2016-01-06T19:25:28
|
|
1.4.3
|
|
7e3acc0e
|
2015-10-10T10:25:46
|
|
Rename README, LICENSE, BUILDING text files
The IJG README file has been renamed to README.ijg, in order to avoid
confusion (many people were assuming that that was our project's README
file and weren't reading README-turbo.txt) and to lay the groundwork for
markdown versions of the libjpeg-turbo README and build instructions.
|
|
30ebafda
|
2015-09-21T13:43:36
|
|
1.4.2
|
|
7a7da946
|
2015-06-27T08:10:31
|
|
Add regression tests for jpeg_skip_scanlines(); change "stripe" to "strip" in djpeg; document -strip and -skip parameters in djpeg
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1587 632fc199-4ca6-4c93-a231-07263d6284db
|
|
6a258944
|
2015-06-27T07:57:44
|
|
Make sure that Java is disabled when 12-bit is enabled (Java requires TurboJPEG, which currently only supports 8-bit samples), and tabs-->spaces
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1585 632fc199-4ca6-4c93-a231-07263d6284db
|
|
ecc58368
|
2015-06-27T07:56:29
|
|
Make sure that Java is disabled when 12-bit is enabled (Java requires TurboJPEG, which currently only supports 8-bit samples), and tabs-->spaces
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1584 632fc199-4ca6-4c93-a231-07263d6284db
|
|
89b5e06d
|
2015-06-20T16:20:53
|
|
Studies show that GCC v5.1.0 performs as well as or better than v4.2, but v4.7.x-v4.9.x do not perform as well as v4.2.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1571 632fc199-4ca6-4c93-a231-07263d6284db
|
|
665c96ed
|
2015-05-15T22:08:21
|
|
Allow building only static or only shared libraries on Windows
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1553 632fc199-4ca6-4c93-a231-07263d6284db
|
|
89a3f970
|
2015-03-19T19:27:40
|
|
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#.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1539 632fc199-4ca6-4c93-a231-07263d6284db
|
|
2b7a3916
|
2015-01-16T06:17:05
|
|
1.4.1
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1510 632fc199-4ca6-4c93-a231-07263d6284db
|
|
e59196db
|
2014-12-19T09:35:11
|
|
1.4.0
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1446 632fc199-4ca6-4c93-a231-07263d6284db
|
|
1e2f4961
|
2014-12-14T11:47:08
|
|
Fix 'make dist'
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1440 632fc199-4ca6-4c93-a231-07263d6284db
|
|
4c773cff
|
2014-12-08T23:23:41
|
|
Fix typos in test names
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.4.x@1439 632fc199-4ca6-4c93-a231-07263d6284db
|
|
f72f1f2e
|
2014-09-04T18:51:31
|
|
Bump version to 1.5 alpha1 to prepare for new features
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1404 632fc199-4ca6-4c93-a231-07263d6284db
|
|
022a9016
|
2014-08-22T14:22:00
|
|
1.4 beta1
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1379 632fc199-4ca6-4c93-a231-07263d6284db
|
|
aee4f721
|
2014-08-09T23:06:07
|
|
12-bit JPEG support
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1337 632fc199-4ca6-4c93-a231-07263d6284db
|
|
a81f5427
|
2014-06-22T20:50:14
|
|
Big oops. wrjpgcom on Windows was being built using the rdjpgcom source.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.2.x@1327 632fc199-4ca6-4c93-a231-07263d6284db
|
|
3da10338
|
2014-06-22T20:48:38
|
|
Big oops. wrjpgcom on Windows was being built using the rdjpgcom source.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1326 632fc199-4ca6-4c93-a231-07263d6284db
|
|
73821bff
|
2014-06-22T20:46:48
|
|
Big oops. wrjpgcom on Windows was being built using the rdjpgcom source.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1325 632fc199-4ca6-4c93-a231-07263d6284db
|
|
78df2e61
|
2014-05-12T09:23:57
|
|
Add support for decompressing to RGB565 (16-bit) pixels
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1295 632fc199-4ca6-4c93-a231-07263d6284db
|
|
715bb41e
|
2014-05-11T10:09:07
|
|
Port the more accurate (and slightly faster) floating point IDCT implementation from jpeg-8a and later. New research revealed that the SSE/SSE2 floating point IDCT implementation was actually more accurate than the jpeg-6b implementation, not less, which is why its mathematical results have always differed from those of the jpeg-6b implementation. This patch brings the accuracy of the C code in line with that of the SSE/SSE2 code.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1288 632fc199-4ca6-4c93-a231-07263d6284db
|
|
35db75ea
|
2014-05-06T22:44:46
|
|
Redesign the libjpeg regression tests so that they fully cover all of the SIMD-accelerated algorithms (and most of the other ones as well)
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1274 632fc199-4ca6-4c93-a231-07263d6284db
|
|
ff6961f3
|
2014-04-20T09:17:11
|
|
This patch accomplishes the following:
-- Auto-generates HAVE_LOCALE_H macro and adds it to jconfig.h (this is used by rdjpgcom.c.)
-- Reconciles the description and ordering of macros between config.h.in and jconfig.h.in, so the two files can be easily diffed.
-- Eliminates the use of the autoheader-generated config.h in the project and moves relevant internal-only macros into a new file, jconfigint.h. This is to avoid "already defined" warnings in files that were including both config.h (to get the internal autotools package information or the INLINE definition) and jconfig.h.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1258 632fc199-4ca6-4c93-a231-07263d6284db
|
|
714839d4
|
2014-04-20T09:13:37
|
|
This patch accomplishes the following:
-- Auto-generates HAVE_LOCALE_H macro and adds it to jconfig.h (this is used by rdjpgcom.c.)
-- Reconciles the description and ordering of macros between config.h.in and jconfig.h.in, so the two files can be easily diffed.
-- Eliminates the use of the autoheader-generated config.h in the project and moves relevant internal-only macros into a new file, jconfigint.h. This is to avoid "already defined" warnings in files that were including both config.h (to get the internal autotools package information or the INLINE definition) and jconfig.h.
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@1257 632fc199-4ca6-4c93-a231-07263d6284db
|
|
06fa20d4
|
2014-04-20T07:20:31
|
|
1.3.2
git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/branches/1.3.x@1252 632fc199-4ca6-4c93-a231-07263d6284db
|