ChangeLog.md: bump revision to prepare for beta

jcphuff.c: Fix compiler warning with Visual C++

GCC doesn't seem to care if we pass no arguments to the ENCODE_COEFS*
macros, but MSVC does.  Insert a no-op to make it happy.

Bump revision to 1.5.90 to prepare for beta

Label this release 2.0 instead of 1.6

This also pulls the formatting changes from
19c791cdac6df84418c66eb9d67cfa9703bc2461 into the TurboJPEG C API docs.

ChangeLog.md: clarification regarding AVX2

C/SSE2 optimization of encode_mcu_AC_first()

This commit adds C and SSE2 optimizations for the encode_mcu_AC_first()
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@293263c using
`time ./jpegtran -outfile /dev/null -progressive -optimise -copy none print_poster_0025.jpg`

C
clang x86_64: +19%
gcc-5 x86_64: +80%
gcc-7 x86_64: +57%
clang i386: +5%
gcc-5 i386: +59%
gcc-7 i386: +51%

SSE2
clang x86_64: +79%
gcc-5 x86_64: +158%
gcc-7 x86_64: +122%
clang i386: +71%
gcc-5 i386: +134%
gcc-7 i386: +135%

Discussion in libjpeg-turbo/libjpeg-turbo#46

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

simd/i386/jchuff-sse2.asm: Minor formatting tweak

Format preprocessor macros more consistently

Within the libjpeg API code, it seems to be more the convention than not
to separate the macro name and value by two or more spaces, which
improves general readability.  Making this consistent across all of
libjpeg-turbo is less about my individual preferences and more about
making it easy to automatically detect variations from our chosen
formatting convention.  I intend to release the script I'm using to
validate this stuff, once it matures and stabilizes a bit.

Additional code formatting tweaks

Missed by previous analysis

Merge branch 'master' into dev

Make all get/putenv() calls compile-time optional

* Modify the SIMD dispatchers so they guard their usage of getenv() with
  the existing NO_GETENV preprocessor definition.
* Introduce a new NO_PUTENV preprocessor definition to guard the
  usage of putenv() in the TurboJPEG API library.

This at least puts Windows Store compatibility within the realm of
possibility, although further steps are required.

Win installer: allow install directories w/ spaces

Fix build with older MinGW releases

Some MinGW implementations need stdint.h in order to define SIZE_MAX.

Regression caused by a09ba29a55b9a43d346421210d94370065eeaf53 and
not fully fixed by a0047bdea4d11dfeefb9ea797865b1a2ea0a665e.

Closes #220

turbojpeg.c: Fix Windows build

Broken by previous commit.  Although turbojpeg.c no longer needs
tjutil.h on Un*x, it still needs to include that file on Windows in
order to use snprintf() and strcasecmp() (which, on Windows, are macros
that wrap _snprintf_s() and stricmp().)

Merge branch 'master' into dev

Improve code formatting consistency

With rare exceptions ...
- Always separate line continuation characters by one space from
  preceding code.
- Always use two-space indentation.  Never use tabs.
- Always use K&R-style conditional blocks.
- Always surround operators with spaces, except in raw assembly code.
- Always put a space after, but not before, a comma.
- Never put a space between type casts and variables/function calls.
- Never put a space between the function name and the argument list in
  function declarations and prototypes.
- Always surround braces ('{' and '}') with spaces.
- Always surround statements (if, for, else, catch, while, do, switch)
  with spaces.
- Always attach pointer symbols ('*' and '**') to the variable or
  function name.
- Always precede pointer symbols ('*' and '**') by a space in type
  casts.
- Use the MIN() macro from jpegint.h within the libjpeg and TurboJPEG
  API libraries (using min() from tjutil.h is still necessary for
  TJBench.)
- Where it makes sense (particularly in the TurboJPEG code), put a blank
  line after variable declaration blocks.
- Always separate statements in one-liners by two spaces.

The purpose of this was to ease maintenance on my part and also to make
it easier for contributors to figure out how to format patch
submissions.  This was admittedly confusing (even to me sometimes) when
we had 3 or 4 different style conventions in the same source tree.  The
new convention is more consistent with the formatting of other OSS code
bases.

This commit corrects deviations from the chosen formatting style in the
libjpeg API code and reformats the TurboJPEG API code such that it
conforms to the same standard.

NOTES:
- Although it is no longer necessary for the function name in function
  declarations to begin in Column 1 (this was historically necessary
  because of the ansi2knr utility, which allowed libjpeg to be built
  with non-ANSI compilers), we retain that formatting for the libjpeg
  code because it improves readability when using libjpeg's function
  attribute macros (GLOBAL(), etc.)
- This reformatting project was accomplished with the help of AStyle and
  Uncrustify, although neither was completely up to the task, and thus
  a great deal of manual tweaking was required.  Note to developers of
  code formatting utilities:  the libjpeg-turbo code base is an
  excellent test bed, because AFAICT, it breaks every single one of the
  utilities that are currently available.
- The legacy (MMX, SSE, 3DNow!) assembly code for i386 has been
  formatted to match the SSE2 code (refer to
  ff5685d5344273df321eb63a005eaae19d2496e3.)  I hadn't intended to
  bother with this, but the Loongson MMI implementation demonstrated
  that there is still academic value to the MMX implementation, as an
  algorithmic model for other 64-bit vector implementations.  Thus, it
  is desirable to improve its readability in the same manner as that of
  the SSE2 implementation.

usage.txt: Remove Alt-Space non-ASCII character

Fix build when RGB_{RED,GREEN,BLUE}!={0,1,2}

Broken by aa7459050d7a50e1d8a99488902d41fbc118a50f

Travis: OS X official builds now use YASM

Because 367a838626576b4ff2a47cbd5a494199b800dc48

Loongson MMI SIMD extensions

Based on:
https://github.com/zhuchen1911/libjpeg-turbo/commit/42aff4497bdaca3258279cafc74511e3c25454b8

Closes #158

SIMD: Formatting tweaks + remove unnecessary code

+ "JSIMD_ARM_NEON" = "JSIMD_NEON"
+ "JSIMD_MIPS_DSPR2" = "JSIMD_DSPR2"
+ "*_mips_dspr2" = "*_dspr2"

It's obvious that "NEON" refers to Arm and "DSPr2" refers to MIPS, and
this naming convention is consistent with the other SIMD extensions.

Fix iOS/ARM[-64] build w/ newer versions of CMake

Newer versions of CMake (known to be the case with 3.7.x and 3.10.x)
fail to add a space between CMAKE_C_FLAGS and CMAKE_ASM_FLAGS, which
causes the build to fail when using the official build procedure.

Closes #216

Make SIMD syms private for x86[-64]/Mach-O builds

... if building with YASM.  NASM doesn't currently support the necessary
directives.

Closes #212

Merge branch 'master' into dev

Closes #214

Fix Win64 ABI conformance when using xmm8-xmm11

Referring to https://docs.microsoft.com/en-US/cpp/build/stack-usage:

"All memory beyond the current address of RSP is considered volatile:
The OS, or a debugger, may overwrite this memory during a user debug
session, or an interrupt handler.  Thus, RSP must always be set before
attempting to read or write values to a stack frame."

Basically, if-- under extremely rare circumstances-- a context swap were
to occur between saving the values of xmm8-xmm11 and setting the new
value of rsp, the O/S might not preserve that area of the stack.  In
general, libjpeg-turbo should not be using xmm8-xmm11 before or after
the call to jsimd_huff_encode_one_block_sse2(), so this is probably a
non-issue, but it's still a good idea to fix it.

Based on
https://github.com/mayeut/libjpeg-turbo/commit/ff7d2030dd26c7b8c37ff540c594490198843f15

Fix BUILDING.md buglet ("--mfloat-abi=softfp")

(Introduced with the build system overhaul)

Closes #215

Fix Win64 ABI conformance issue in AVX2 ISLOW IDCT

xmm8-xmm11 must be saved and restored, since the function uses
ymm8-ymm11.

Closes #211

Fix build with YASM

vinserti128 requires all operands to be specified

Make SIMD symbols private for MIPS ELF builds

Closes #210

Make SIMD symbols private for iOS ARM/ARM64 builds

Make SIMD symbols private for x86[-64] ELF builds

32-bit AVX2 implementation of slow int inverse DCT

32-bit AVX2 buglet: IS_ALIGNED_SSE=IS_ALIGNED_AVX

64-bit AVX2 implementation of slow int inverse DCT

32-bit AVX2 implementation of int sample conv.

32-bit AVX2 implementation of slow int forward DCT

64-bit AVX2 implementation of int sample conv.

64-bit AVX2 implementation of slow int forward DCT

AVX2: Introduce YMMBLOCK macro for readability

Prog Huff enc: bit count/branchless abs val opts

Ported from baseline Huffman encoder.  This improves overall compression
performance by ~3-9% in my testing.

Merge branch 'master' into dev

README.md: Fix permissions

Merge branch 'master' into dev

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.

Merge branch 'master' into dev

Travis/OS X: Use 'brew bundle' + Brewfile

This ensures that the build script will not fail if the Homebrew
dependencies are already installed.

Merge branch 'master' into dev

jdarith.c: Fix two signed integer overflows

I guess I have to fix these, or Google Autofuzz is going to keep bugging
me about them.

Fixes #171
Fixes #197
Fixes #198

Bump version to 1.5.4 to prepare for new commits

BUILDING.md: Adjust Android recipes for NDK r16+

NDK r16b moved some things around, so modify the Android build recipes
to take that into account while preserving compatibility with previous
NDK releases.

NOTE: the GCC 4.9 NDK toolchain is deprecated, so we will need to
develop new Android build recipes for libjpeg-turbo 1.6 that use the
Clang toolchain.

Closes #196

Fix whitespace errors

Merge branch 'master' into dev

+ acknowledge 1.5.3 release

jpeg_crop_scanlines: Handle gray images w/ samp!=1

Since the sampling factor has no meaning for single-component images,
the decompressor ignores it, and jpeg_crop_scanlines() should as well.

Fixes #195

Fix lib state when skipping to end of 1-scan image

If jpeg_skip_scanlines() is used to skip to the end of a single-scan
image, then we need to change the library state such that subsequent
calls to jpeg_consume_input() will return JPEG_REACHED_EOI rather than
JPEG_SUSPENDED.  (NOTE: not necessary for multi-scan images, since the
scans are processed prior to any call to jpeg_skip_scanlines().)

Unless I miss my guess, using jpeg_skip_scanlines() in this manner
will prevent any markers at the end of the JPEG image from being
read, but I don't think there is any way around that without actually
reading the data, which would defeat the purpose of
jpeg_skip_scanlines().

Fixes #194

Merge branch 'master' into dev

Travis: Work around xcode7.3 image bug

Refer to travis-ci/travis-ci#8552.  This was supposed to be fixed on
November 15, then on November 28.  Travis blew through both deadlines,
so I have no confidence that the issue will be fixed as promised in a
timely manner.  Adding 'brew update' to .travis.yml slows the OS X
build, but there is no choice at the moment.

tjLoadImage(): Fix OOB array access w/TJPF_UNKNOWN

Because the previous commit added a test for TJPF_UNKNOWN to tjunittest,
the ASAN CI build detected this issue.

tjLoadImage(): return TJPF_GRAY for grayscale BMPs

... if *pixelFormat=TJPF_UNKNOWN is passed to the function.

tjLoadImage(): Don't convert RGB to grayscale

Loading RGB image files into a grayscale buffer isn't a particularly
useful feature, given that libjpeg-turbo can perform this conversion
much more optimally (with SIMD acceleration on some platforms) during
the compression process.  Also, the RGB2GRAY() macro was not producing
deterministic cross-platform results because of variations in the
round-off behavior of various floating point implementations, so
`tjunittest -bmp` was failing in i386 builds.

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.

TurboJPEG: Add alpha offset array/method

Also, set the red/green/blue offsets for TJPF_GRAY to -1 rather than 0.
It was undefined behavior for an application to use those arrays/methods
with TJPF_GRAY anyhow, and this makes it easier for applications to
programmatically detect whether a given pixel format has red, green, and
blue components.

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.

tjbenchtest: Test new TurboJPEG progressive flag

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.

Merge branch 'master' into dev

TJExample: Fix array index OOB w/ 4:1:1 JPEG input

Code formatting tweaks

Uniquify tjbenchtest log file names based on args

+ clean up log files when 'make testclean' is invoked
+ fix 'tjbenchtest -yuv -alloc'
+ fix tjexampletest so that it creates images under /tmp
+ clean up tjexampletest

TJExample.java: Don't ignore mistyped args

Doc tweak: TJFLAG_ACCURATEDCT is the first flag

tjbench.exe: Fix decompression access violation

The program crashed when a JPEG image was passed on the command line,
because we were mixing our metaphors vis-a-vis malloc()/free() and
tjAlloc()/tjFree() (malloc()/free() uses the tjbench.exe heap,
whereas tjAlloc()/tjFree() uses the turbojpeg.dll heap.)

ChangeLog.md: buglet

Build: Fix `make dist`

Broken by previous commit

Further partial image decompression fixes

- Referring to 073b0e88a192adebbb479ee2456beb089d8b5de7 and #185, the
  reason why BMP and RLE didn't (and won't) work with partial image
  decompression is that the output engines for both formats maintain a
  whole-image buffer, which is used to reverse the order of scanlines.
  However, it was straightforward to add -crop support for GIF and
  Targa, which is useful for testing partial image decompression along
  with color quantization.
- Such testing reproduced a bug reported by Mozilla (refer to PR #182)
  whereby jpeg_skip_scanlines() would segfault if color quantization was
  enabled.  To fix this issue, read_and_discard_scanlines() now sets up
  a dummy quantize function in the same manner that it sets up a dummy
  color conversion function.

Closes #182

TJBench/TJUnitTest: Don't ignore mistyped args

TurboJPEG C: Code formatting tweaks

djpeg -crop: Exit gracefully with non-PPM formats

... and document that only PPM/PGM output images are supported with the
-crop option for the moment.

I investigated the possibility of supporting -crop with -bmp, but even
after resetting the buffer dimensions, I still kept getting virtual
array access errors.  It seems that doing this the "right way" would
require creating a re-initialization function for each image format's
destination manager.  I'm disinclined to do that right now, given that
this feature was Google's baby (developed as a prerequisite for
including libjpeg-turbo in Android), and the -crop option in djpeg is
intended only as an example of how to use the partial image
decompression API.  Real-world applications would need to handle this
in their own destination managers.

It would probably be possible to make this work with Targa by employing
a similar hack to the one we used with PPM, but Targa isn't popular
enough to bother.

Fixes #185

TurboJPEG C: Compiler warnings

Introduced in b9ab64d8dbee2db829e59357d335c151680f44f0.

SRPM build: Define _libdir based on build arch

Setting _libdir to CMAKE_INSTALL_FULL_LIBDIR only works when doing an
in-tree RPM build.  SRPMs are architecture-agnostic, so the spec needs
to compute_libdir at the time the SRPM is rebuilt, not at the time it
is generated.

This is a regression introduced when implementing the new CMake-based
cross-platform build system.

Merge branch 'master' into dev

Prevent "unmappable character" error in Java build

This was causing the build to fail when rebuilding libjpeg-turbo from
a source RPM.

Fix PowerPC 32-bit RPM build

Fix 32-bit RPM build w/ newer RHEL/Fedora releases

The version of RPM on RHEL 5 and older platforms defines _libdir
as %{_exec_prefix}/%{_lib}, so defining _lib in the spec file redefined
_libdir.  However, newer versions of RPM (probably >= 4.6, since that
was the version that introduced the ISA macros) define _libdir as either
%{_prefix}/lib or %{_prefix}/lib64.  Thus, we need to explicitly
override _libdir in our spec file.

Packaging: Use parallel make when rebuilding SRPM

Travis: Limit parallel make jobs to # of CPU cores

This tends to be faster than 'make -j', since it is making more wise
use of the available resources.

wrjpgcom: Fix comment typo

Comment was copied/pasted from skip_variable() without making the
necessary modifications.

Merge branch 'master' into dev

TJUnitTest: Usage formatting tweaks

Java: Fix TJUnitTest on big endian platforms

It is necessary for the C code to be aware of the machine's endianness,
which is why the TurboJPEG Java wrapper sets a different pixel format
for integer BufferedImages depending on ByteOrder.nativeOrder().
However, it isn't necessary to handle endianness in pure Java code such
as TJUnitTest (d'oh!)  This was a product of porting the C version of
TJUnitTest too literally, and of insufficient testing (historically,
the big endian systems I had available for testing didn't have Java.)

Build: Change ppc64le DEB arch to ppc64el

This is the convention among Debian-based distros.

Merge branch 'master' into dev

Build: Fix AltiVec detection on OS X Leopard

The ability to directly access elements of an AltiVec vector is
apparently a more recent thing.

Build: Use -maltivec when testing AltiVec support

Doesn't seem to be necessary with recent Linux/GCC configurations, but
it is definitely necessary with OS X.

Merge branch 'master' into dev

Fix build on PowerPC SPE systems

SPE systems don't support AltiVec instructions.

Fixes #172

Java: Fix NullPointerException in YUVImage

planes == null is a valid argument to setBuf() if alloc == true, so we
need to make sure that planes is non-null before validating its length.
We also need to allocate one dimension of the planes array if it's null.

Fixes #168

Bump version to 1.5.3 to prepare for new commits

x86: Fix "short jump is out of range" w/ NASM<2.04

TJBench: Recover from non-fatal errors if possible

Previously, -stoponwarning only had an effect on the underlying
TurboJPEG C functions, but TJBench still aborted if a non-fatal error
occurred.  This commit modifies the C version of TJBench such that it
always recovers from a non-fatal error unless -stoponwarning is
specified.  Furthermore, the benchmark stores the details of the last
non-fatal error and does not print any subsequent non-fatal error
messages unless they differ from the last one.

Due to limitations in the Java API (specifically, the fact that it
cannot communicate errors, fatal or otherwise, to the calling program
without throwing a TJException), it was only possible to make
decompression operations fully recoverable within TJBench.  With other
operations, -stoponwarning still has an effect on the underlying C
library but has no effect at the Java level.

The Java API documentation has been amended to reflect that only certain
methods are truly recoverable, regardless of the state of
TJ.FLAG_STOPONWARNING.