libjpeg-turbo-announce — libjpeg-turbo Announcements (moved to Google Groups-- see http://www.libjpeg-turbo.org/About/MailingLists)

[Libjpeg-turbo-announce] libjpeg-turbo mailing lists have moved to Google Groups

[DRC <dco...@us...>]

SourceForge removed the ability for project admins to view/manage the
members of mailing lists, which was the final straw.  Thanks to all who
gave their feedback, but given that my other OSS projects are using
Google Groups and I was unable to find anything better, I decided to use
Google Groups for this project as well.  You can join the new groups
either using a Google account (which gives you full access to the group
from the web interface) or a non-Google e-mail address (which gives you
access to post from e-mail only.)  Links for joining all of the groups
can be found here:

http://www.libjpeg-turbo.org/About/MailingLists

(Note that you have to be logged in with a Google account in order to
join with that account.)

To unsubscribe from the old lists, visit one or more of the following URLs:
https://sourceforge.net/projects/libjpeg-turbo/lists/libjpeg-turbo-announce/unsubscribe
https://sourceforge.net/projects/libjpeg-turbo/lists/libjpeg-turbo-users/unsubscribe
https://sourceforge.net/projects/libjpeg-turbo/lists/libjpeg-turbo-devel/unsubscribe

The direct addresses for e-mailing the new groups are:
lib...@go...
lib...@go...

Other notes:
-- If you join with a non-Google e-mail address, Google makes you go
through a really annoying Turing test.  I apologize in advance for that.
-- The old mailing lists will be retained on SourceForge for archival
purposes.  Direct links to these archives are available at
http://www.libjpeg-turbo.org/About/MailingLists.
-- The new mailing lists have already been added to mail-archive.com.
-- The new lists are public (anyone can join or view the messages), but
the subscriber lists are visible only to me.
-- As with the existing lists, only members can post (and only I can
post to the announcement list.)
-- The new lists are configured such that your Google profile will not
be revealed if you post.  Only your chosen display name will be shown.

Please e-mail me directly (http://www.libjpeg-turbo.org/About/Contact)
or post a GitHub tracker issue
(https://github.com/libjpeg-turbo/libjpeg-turbo/issues/new) should you
have any questions, concerns, or problems subscribing to the new lists.

The old lists will be closed to new messages shortly, so please transfer
your subscriptions immediately.

DRC

[Libjpeg-turbo-announce] Moving libjpeg-turbo mailing lists-- FEEDBACK REQUESTED

[DRC <dco...@us...>]

SourceForge removed the ability for project admins to view/manage the
members of mailing lists, which was the final straw (I had to jump
through hoops just to send this e-mail from my SourceForge e-mail
address, which for some reason was no longer subscribed or registered as
a list admin.)  I've already moved my other project mailing lists
(VirtualGL and TurboVNC) to Google Groups, but given that this project
has a much broader reach, I wanted to solicit feedback from the
community.  In particular, I realize that Google is banned in some
countries that are heavy users of libjpeg-turbo, so I welcome all
suggestions for how to migrate this aspect of our project to a platform
other than SourceForge.  Please comment here or on the following GitHub
issue:

https://github.com/libjpeg-turbo/libjpeg-turbo/issues/165

If I don't hear any feedback in a timely manner, I will proceed with
migrating to Google Groups.

DRC

[Libjpeg-turbo-announce] libjpeg-turbo 1.5.2 has been released

[DRC <dco...@us...>]

Official binaries are here:

https://sourceforge.net/projects/libjpeg-turbo/files/1.5.2

Change log is here:

https://github.com/libjpeg-turbo/libjpeg-turbo/releases/tag/1.5.2

[Libjpeg-turbo-announce] CMake build system

[DRC <dco...@us...>]

For those who haven't been following the discussion at

https://github.com/libjpeg-turbo/libjpeg-turbo/issues/56

the dev branch now contains a 100% CMake-based build system.  The
decision to eliminate autotools in libjpeg-turbo 1.6 was not one I took
lightly, but CMake's built-in support for assembly and Java code, as
well as other features that are generally more friendly to the needs of
our build and packaging system, solved a lot of problems for us and
eliminated a lot of hacks.  In addition, this eliminates the need to
maintain two separate build, packaging, and testing systems going
forward, which will reduce costs for new feature implementations.  I
spent something like 60 unpaid hours implementing this, but it will
probably save me much more time than that in the long run.

This will not land in libjpeg-turbo 1.6 beta for at least several
months, which should hopefully give downstream integrators enough time
to test it and make the necessary modifications to their distribution
builds.  Please take a moment to test the new build system on your
favorite platform and let me know what breaks.  The most common
cross-compilation builds (including iOS, Android, and MinGW) are
documented in BUILDING.md.

If your project or organization will benefit from this work, then please
consider making a donation using the "Donate" button at
http://www.libjpeg-turbo.org/.  I have spent hundreds of unpaid hours in
the past couple of months implementing this new build system and the
continuous integration system.  Since I don't draw a salary for my work
on open source code, donations and funded development opportunities are
the only way I can get paid for my work, and those sources of funding
are the only thing keeping libjpeg-turbo afloat as a project.

DRC

[Libjpeg-turbo-announce] Web site outage

[DRC <dco...@us...>]

The hosting provider for the VirtualGL, TurboVNC, and libjpeg-turbo web
sites is currently down for unknown reasons (but probably related to the
large DDoS attack that is taking place in the U.S. today.)  Everything
on those sites was backed up last night.  All other project services are
functioning properly.

DRC

[Libjpeg-turbo-announce] libjpeg-turbo 1.5.1 has been released

[DRC <dco...@us...>]

Official binaries are here:

https://sourceforge.net/projects/libjpeg-turbo/files/1.5.1

Change log is here:

https://github.com/libjpeg-turbo/libjpeg-turbo/releases/tag/1.5.1

[Libjpeg-turbo-announce] libjpeg-turbo 1.5.0 has been released

[DRC <dco...@us...>]

Official binaries are here:

https://sourceforge.net/projects/libjpeg-turbo/files/1.5.0

Change log is here:

https://github.com/libjpeg-turbo/libjpeg-turbo/releases/tag/1.5.0

[Libjpeg-turbo-announce] libjpeg-turbo is SourceForge's Project of the Month-- thanks to all who voted!

[DRC <dco...@us...>]

You can read the interview here:
https://sourceforge.net/blog/may-2016-community-choice-project-of-the-month-libjpeg-turbo/

DRC

[Libjpeg-turbo-announce] Vote for libjpeg-turbo for the May, 2016 SourceForge Project of the Month

[DRC <dco...@us...>]

Hi, all.  If you have a SourceForge account, then please take a moment
to add a comment to this thread that says "VOTE: libjpeg-turbo".

https://sourceforge.net/p/potm/discussion/vote/thread/ba2aebd4/

This will add a vote for libjpeg-turbo for SourceForge Project of the
Month (NOTE: you can only vote once.)  The winning project will get an
exclusive interview and be featured on the SourceForge home page, which
could potentially attract new sponsors for our project.

As you know, the harsh reality of open source software is that, despite
the software being provided for free, almost all prominent, high-quality
open source development is done by paid developers (you get what you pay
for, essentially.)  In most cases, the developers are employees of a
corporation or other organization that is paying them to develop the
open source code in the context of that organization's broader agenda.
libjpeg-turbo is one of the few prominent open source projects that
works purely on a patronage model, which means that we can maintain the
product in a vendor-agnostic manner, free of any one organization's
agenda.  However, that also means that exposure for our project is
critical to its long-term success.

Thank you for your continued support,
DRC

[Libjpeg-turbo-announce] libjpeg-turbo 1.5 beta1 (1.4.90) has been released

[DRC <dco...@us...>]

Official binaries are here:

https://sourceforge.net/projects/libjpeg-turbo/files/1.4.90%20%281.5%20beta1%29/


Change log is here:

https://github.com/libjpeg-turbo/libjpeg-turbo/releases/tag/1.4.90


Highlights:

-- AltiVec SIMD support (~2-4x speedup)
-- x86[-64] SIMD acceleration for Huffman encoding (~10-15% speedup)
-- Completed ARMv8 SIMD coverage for compression functions (~2x speedup)
-- ARMv7 SIMD acceleration for Huffman encoding (~30% speedup for iOS,
~6-7% speedup for Android)
-- ARMv8 SIMD acceleration for Huffman encoding (~40% speedup for iOS,
~7-8% speedup for Android)
-- Optimized ARMv8 decompression functions on in-order cores (~2x
speedup on ThunderX, ~15% speedup on Cortex-A53)
-- Partial image decoding support (libjpeg API only, at the moment)
-- Various security fixes

[Libjpeg-turbo-announce] libjpeg-turbo 1.4.2 has been released

[DRC <dco...@us...>]

Official binaries are here:
https://sourceforge.net/projects/libjpeg-turbo/files/1.4.2

Change log is here:
https://github.com/libjpeg-turbo/libjpeg-turbo/releases/tag/1.4.2

[Libjpeg-turbo-announce] Signed binaries

[DRC <dco...@us...>]

All of the libjpeg-turbo binaries back to 1.3.0 have been digitally signed.

See

http://www.libjpeg-turbo.org/Downloads/DigitalSignatures

for instructions on how to verify the signatures.

[Libjpeg-turbo-announce] Code migration to GitHub is complete

[DRC <dco...@us...>]

I'm not sure whether any of my previous messages regarding the 
SourceForge outage got through, so forgive me if any of this is old news.

Let me start by saying that I think the rumors of SourceForge's demise 
have been greatly exaggerated.  They have certainly engaged in some 
questionable advertising practices in the past (as have some other 
high-profile web sites we all know and love), but they have largely 
owned up to their mistakes and have taken steps to prevent them in the 
future.  I also feel that they handled this outage in the best way they 
could.  I've been using SourceForge since 2004-- you know, back when 
they were pretty much in exactly the same position as GitHub is now. 
I've been around this block enough times to be wary of jumping onto the 
latest & greatest platform just because it's the latest & greatest.

That being said, while I have had no major issues with SourceForge 
(before now), this outage made me finally admit that the advantages of a 
DVCS (such as git) far outweigh the pain of learning a new system.  To 
that end, I took advantage of the downtime to get familiar enough with 
Git that I can be productive with it.  When our subversion repository 
came back online yesterday, I immediately started migrating our code to 
GitHub.  I could just as easily have migrated it to SourceForge's Git or 
Hg servers, but I am a believer in using the best tool for the job. 
Part of maintaining a healthy open source community is making it easy 
for developers to contribute, and GitHub's popularity and rich 
collaboration tools make it a clear winner in that department.

The code migration is now complete, and you can find our main repository at:
https://github.com/libjpeg-turbo/libjpeg-turbo

Supporting repositories (build scripts, etc.) can be found at
https://github.com/libjpeg-turbo

Please update any sandboxes you may have.  The subversion repository is 
frozen and will eventually be decommissioned.

The following provides a comprehensive list of project services and 
where to find them, going forward:

-- Code hosting:  GitHub only 
(https://github.com/libjpeg-turbo/libjpeg-turbo)

-- Issue/feature tracking:  Either GitHub 
(https://github.com/libjpeg-turbo/libjpeg-turbo/issues) or SourceForge 
(https://sourceforge.net/p/libjpeg-turbo/_list/tickets)
    There are advantages and disadvantages to both (for instance, you 
can't attach files with GitHub), so for the time being at least, use 
whichever one you prefer.  I have moved a few high-priority feature 
requests to GitHub, but all other items are still on SourceForge.  If, 
at some point in the future, the SourceForge tracker stops being used or 
the GitHub tracker improves its feature set, I will consider freezing 
the SF tracker.

-- Patches:  Either GitHub 
(https://github.com/libjpeg-turbo/libjpeg-turbo/pulls) or SourceForge 
(https://sourceforge.net/p/libjpeg-turbo/patches/)
    If, at some point in the future, the SourceForge tracker stops being 
used, I will consider freezing it.

-- Official Releases:  SourceForge 
(https://sourceforge.net/projects/libjpeg-turbo/files/)
    My automated pre-release and release scripts are heavily tied to the 
SourceForge file release system, I like certain features of that system 
(such as the statistics it provides), and there are a lot of links to 
those files out there, so at least for now, I will continue using 
SourceForge to distribute official releases.  I will, however, sign all 
RPMs and DEBs on that site with my GPG key and all Windows installers 
with my code signing certificate, in order to ease any concerns about 
binary tampering.  Look for a follow-up message announcing the 
completion of that project (SourceForge has not yet restored the file 
upload and SSH features, so access to the file release system is 
currently read-only.)
    GitHub includes metadata and automatically-generated tarballs for 
all of the release tags 
(https://github.com/libjpeg-turbo/libjpeg-turbo/releases), but these 
tarballs have not
been processed with autoconf, so they should not be considered "official."

-- Web site:  hosted on an external web server 
(http://www.libjpeg-turbo.org)
    All of the links mentioned in this message can be found there.

-- Mailing lists:  SourceForge 
(https://sourceforge.net/p/libjpeg-turbo/mailman/)

-- Discussion forums:  SourceForge 
(https://sourceforge.net/p/libjpeg-turbo/discussion/)


As always, please send me any questions or concerns you may have.

DRC

[Libjpeg-turbo-announce] libjpeg-turbo 1.4.1 has been released

[DRC <dco...@us...>]

Significant changes since 1.4.0
===============================

[1] tjbench now properly handles CMYK/YCCK JPEG files.  Passing an 
argument of -cmyk (instead of, for instance, -rgb) will cause tjbench to 
internally convert the source bitmap to CMYK prior to compression, to 
generate YCCK JPEG files, and to internally convert the decompressed 
CMYK pixels back to RGB after decompression (the latter is done 
automatically if a CMYK or YCCK JPEG is passed to tjbench as a source 
image.)  The CMYK<->RGB conversion operation is not benchmarked.  NOTE: 
The quick & dirty CMYK<->RGB conversions that tjbench uses are suitable 
for testing only.  Proper conversion between CMYK and RGB requires a 
color management system.

[2] 'make test' now performs additional bitwise regression tests using 
tjbench, mainly for the purpose of testing compression 
from/decompression to a subregion of a larger image buffer.

[3] 'make test' no longer tests the regression of the floating point 
DCT/IDCT by default, since the results of those tests can vary if the 
algorithms in question are not implemented using SIMD instructions on a 
particular platform.  See the comments in Makefile.am for information on 
how to re-enable the tests and to specify an expected result for them 
based on the particulars of your platform.

[4] The NULL color conversion routines have been significantly 
optimized, which speeds up the compression of RGB and CMYK JPEGs by 
5-20% when using 64-bit code and 0-3% when using 32-bit code, and the 
decompression of those images by 10-30% when using 64-bit code and 3-12% 
when using 32-bit code.

[5] Fixed an "illegal instruction" error that occurred when djpeg from a 
SIMD-enabled libjpeg-turbo MIPS build was executed with the -nosmooth 
option on a MIPS machine that lacked DSPr2 support.  The MIPS SIMD 
routines for h2v1 and h2v2 merged upsampling were not properly checking 
for the existence of DSPr2.

[6] Performance has been improved significantly on 64-bit non-Linux and 
non-Windows platforms (generally 10-20% faster compression and 5-10% 
faster decompression.)  Due to an oversight, the 64-bit version of the 
accelerated Huffman codec was not being compiled in when libjpeg-turbo 
was built on platforms other than Windows or Linux.  Oops.

[7] Fixed an extremely rare bug in the Huffman encoder that caused 
64-bit builds of libjpeg-turbo to incorrectly encode a few specific test 
images when quality=98, an optimized Huffman table, and the slow integer 
forward DCT were used.

[8] The Windows (CMake) build system now supports building only static 
or only shared libraries.  This is accomplished by adding either 
-DENABLE_STATIC=0 or -DENABLE_SHARED=0 to the CMake command line.

[9] TurboJPEG API functions will now return an error code if a warning 
is triggered in the underlying libjpeg API.  For instance, if a JPEG 
file is corrupt, the TurboJPEG decompression functions will attempt to 
decompress as much of the image as possible, but those functions will 
now return -1 to indicate that the decompression was not entirely 
successful.

[10] Fixed a bug in the MIPS DSPr2 4:2:2 fancy upsampling routine that 
caused a buffer overflow (and subsequent segfault) when decompressing a 
4:2:2 JPEG image in which the right-most MCU was 5 or 6 pixels wide.

[Libjpeg-turbo-announce] libjpeg-turbo 1.4.0 has been released

[DRC <dco...@us...>]

https://sourceforge.net/projects/libjpeg-turbo/files/1.4.0/

Significant changes since 1.4 beta1
===================================

[1] Fixed a build issue on OS X PowerPC platforms (md5cmp failed to 
build because OS X does not provide the le32toh() and htole32() functions.)

[2] The non-SIMD RGB565 color conversion code did not work correctly on 
big endian machines.  This has been fixed.

[3] Fixed an issue in tjPlaneSizeYUV() whereby it would erroneously 
return 1 instead of -1 if componentID was > 0 and subsamp was TJSAMP_GRAY.

[3] Fixed an issue in tjBufSizeYUV2() wherby it would erroneously return 
0 instead of -1 if width was < 1.

[5] The Huffman encoder now uses clz and bsr instructions for bit 
counting on ARM64 platforms (see 1.4 beta1 [5].)

[6] The close() method in the TJCompressor and TJDecompressor Java 
classes is now idempotent.  Previously, that method would call the 
native tjDestroy() function even if the TurboJPEG instance had already 
been destroyed.  This caused an exception to be thrown during 
finalization, if the close() method had already been called.  The 
exception was caught, but it was still an expensive operation.

[7] The TurboJPEG API previously generated an error ("Could not 
determine subsampling type for JPEG image") when attempting to 
decompress grayscale JPEG images that were compressed with a sampling 
factor other than 1 (for instance, with 'cjpeg -grayscale -sample 2x2'). 
  Subsampling technically has no meaning with grayscale JPEGs, and thus 
the horizontal and vertical sampling factors for such images are ignored 
by the decompressor.  However, the TurboJPEG API was being too rigid and 
was expecting the sampling factors to be equal to 1 before it treated 
the image as a grayscale JPEG.

[8] cjpeg, djpeg, and jpegtran now accept an argument of -version, which 
will print the library version and exit.

[9] Referring to 1.4 beta1 [15], another extremely rare circumstance was 
discovered under which the Huffman encoder's local buffer can be overrun 
when a buffered destination manager is being used and an 
extremely-high-frequency block (basically junk image data) is being 
encoded.  Even though the Huffman local buffer was increased from 128 
bytes to 136 bytes to address the previous issue, the new issue caused 
even the larger buffer to be overrun.  Further analysis reveals that, in 
the absolute worst case (such as setting alternating AC coefficients to 
32767 and -32768 in the JPEG scanning order), the Huffman encoder can 
produce encoded blocks that approach double the size of the unencoded 
blocks.  Thus, the Huffman local buffer was increased to 256 bytes, 
which should prevent any such issue from re-occurring in the future.

[10] The new tjPlaneSizeYUV(), tjPlaneWidth(), and tjPlaneHeight() 
functions were not actually usable on any platform except OS X and 
Windows, because those functions were not included in the libturbojpeg 
mapfile.  This has been fixed.

[11] Restored the JPP(), JMETHOD(), and FAR macros in the libjpeg-turbo 
header files.  The JPP() and JMETHOD() macros were originally 
implemented in libjpeg as a way of supporting non-ANSI compilers that 
lacked support for prototype parameters.  libjpeg-turbo has never 
supported such compilers, but some software packages still use the 
macros to define their own prototypes.  Similarly, libjpeg-turbo has 
never supported MS-DOS and other platforms that have far symbols, but 
some software packages still use the FAR macro.  A pretty
good argument can be made that this is a bad practice on the part of the 
software in question, but since this affects more than one package, it's 
just easier to fix it here.

[12] Fixed issues that were preventing the ARM 64-bit SIMD code from 
compiling for iOS, and included an ARMv8 architecture in all of the 
binaries installed by the "official" libjpeg-turbo SDK for OS X.

[Libjpeg-turbo-announce] libjpeg-turbo 1.3.90 (1.4 beta1) has been released

[DRC <dco...@us...>]

https://sourceforge.net/projects/libjpeg-turbo/files/1.3.90%20%281.4%20beta1%29/

Significant changes since 1.3.1
===============================

[1] New features in the TurboJPEG API:
-- YUV planar images can now be generated with an arbitrary line padding 
(previously only 4-byte padding, which was compatible with X Video, was 
supported.)
-- The decompress-to-YUV function has been extended to support image 
scaling.
-- JPEG images can now be compressed from YUV planar source images.
-- YUV planar images can now be decoded into RGB or grayscale images.
-- 4:1:1 subsampling is now supported.  This is mainly included for 
compatibility, since 4:1:1 is not fully accelerated in libjpeg-turbo and 
has no significant advantages relative to 4:2:0.
-- CMYK images are now supported.  This feature allows CMYK source 
images to be compressed to YCCK JPEGs and YCCK or CMYK JPEGs to be 
decompressed to CMYK destination images.  Conversion between CMYK/YCCK 
and RGB or YUV images is not supported.  Such conversion requires a 
color management system and is thus out of scope for a codec library.
-- The handling of YUV images in the Java API has been significantly 
refactored and should now be much more intuitive.
-- The Java API now supports encoding a YUV image from an arbitrary 
position in a large image buffer.
-- All of the YUV functions now have a corresponding function that 
operates on separate image planes instead of a unified image buffer. 
This allows for compressing/decoding from or decompressing/encoding to a 
subregion of a larger YUV image.  It also allows for handling YUV 
formats that swap the order of the U and V planes.

[2] Added SIMD acceleration for DSPr2-capable MIPS platforms.  This 
speeds up the compression of full-color JPEGs by 70-80% on such 
platforms and decompression by 25-35%.

[3] If an application attempts to decompress a Huffman-coded JPEG image 
whose header does not contain Huffman tables, libjpeg-turbo will now 
insert the default Huffman tables.  In order to save space, many motion 
JPEG video frames are encoded without the default Huffman tables, so 
these frames can now be successfully decompressed by libjpeg-turbo 
without additional work on the part of the application.  An application 
can still override the Huffman tables, for instance to re-use tables 
from a previous frame of the same video.

[4] The Mac packaging system now uses pkgbuild and productbuild rather 
than PackageMaker (which is obsolete and no longer supported.)  This 
means that OS X 10.6 "Snow Leopard" or later must be used when packaging 
libjpeg-turbo, although the packages produced can be installed on OS X 
10.5 "Leopard" or later.  OS X 10.4 "Tiger" is no longer supported.

[5] The Huffman encoder now uses clz and bsr instructions for bit 
counting on ARM platforms rather than a lookup table.  This reduces the 
memory footprint by 64k, which may be important for some mobile 
applications.  Out of four Android devices that were tested, two 
demonstrated a small overall performance loss (~3-4% on average) with 
ARMv6 code and a small gain (also ~3-4%) with ARMv7 code when enabling 
this new feature, but the other two devices demonstrated a significant 
overall performance gain with both ARMv6 and ARMv7 code (~10-20%) when 
enabling the feature.  Actual mileage may vary.

[6] Worked around an issue with Visual C++ 2010 and later that caused 
incorrect pixels to be generated when decompressing a JPEG image to a 
256-color bitmap, if compiler optimization was enabled when 
libjpeg-turbo was built.  This caused the regression tests to fail when 
doing a release build under Visual C++ 2010 and later.

[7] Improved the accuracy and performance of the non-SIMD implementation 
of the floating point inverse DCT (using code borrowed from libjpeg v8a 
and later.)  The accuracy of this implementation now matches the 
accuracy of the SSE/SSE2 implementation.  Note, however, that the 
floating point DCT/IDCT algorithms are mainly a legacy feature.  They 
generally do not produce significantly better accuracy than the slow 
integer DCT/IDCT algorithms, and they are quite a bit slower.

[8] Added a new output colorspace (JCS_RGB565) to the libjpeg API that 
allows for decompressing JPEG images into RGB565 (16-bit) pixels.  If 
dithering is not used, then this code path is SIMD-accelerated on ARM 
platforms.

[9] Numerous obsolete features, such as support for non-ANSI compilers 
and support for the MS-DOS memory model, were removed from the libjpeg 
code, greatly improving its readability and making it easier to maintain 
and extend.

[10] Fixed a segfault that occurred when calling output_message() with 
msg_code set to JMSG_COPYRIGHT.

[11] Fixed an issue whereby wrjpgcom was allowing comments longer than 
65k characters to be passed on the command line, which was causing it to 
generate incorrect JPEG files.

[12] Fixed a bug in the build system that was causing the Windows 
version of wrjpgcom to be built using the rdjpgcom source code.

[13] Restored 12-bit-per-component JPEG support.  A 12-bit version of 
libjpeg-turbo can now be built by passing an argument of --with-12bit to 
configure (Unix) or -DWITH_12BIT=1 to cmake (Windows.)  12-bit JPEG 
support is included only for convenience.  Enabling this feature 
disables all of the performance features in libjpeg-turbo, as well as 
arithmetic coding and the TurboJPEG API.  The resulting library still 
contains the other libjpeg-turbo features (such as the colorspace 
extensions), but in general, it performs no faster than libjpeg v6b.

[14] Added ARM 64-bit SIMD acceleration for the YCC-to-RGB color 
conversion and IDCT algorithms (both are used during JPEG 
decompression.)  For unknown reasons (probably related to clang), this 
code cannot currently be compiled for iOS.

[15] Fixed an extremely rare bug that could cause the Huffman encoder's 
local buffer to overrun when a very high-frequency MCU is compressed 
using quality 100 and no subsampling, and when the JPEG output buffer is 
being dynamically resized by the destination manager.  This issue was so 
rare that, even with a test program specifically designed to make the 
bug occur (by injecting random high-frequency YUV data into the 
compressor), it was reproducible only once in about every 25 million 
iterations.

[16] Fixed an oversight in the TurboJPEG C wrapper:  if any of the JPEG 
compression functions was called repeatedly with the same 
automatically-allocated destination buffer, then TurboJPEG would 
erroneously assume that the jpegSize parameter was equal to the size of 
the buffer, when in fact that parameter was probably equal to the size 
of the most recently compressed JPEG image.  If the size of the previous 
JPEG image was not as large as the current JPEG image, then TurboJPEG 
would unnecessarily reallocate the destination buffer.

[Libjpeg-turbo-announce] libjpeg-turbo 1.3.1 has been released

[DRC <dco...@us...>]

https://sourceforge.net/projects/libjpeg-turbo/files/1.3.1/


Cygwin users, please refer to 
http://www.libjpeg-turbo.org/Documentation/Cygwin for installation 
instructions.  We are now maintaining our own Cygwin repository for 
official libjpeg-turbo packages.


Significant changes since 1.3.0
===============================

[1] On Un*x systems, 'make install' now installs the libjpeg-turbo 
libraries into /opt/libjpeg-turbo/lib32 by default on any 32-bit system, 
not just x86, and into /opt/libjpeg-turbo/lib64 by default on any 64-bit 
system, not just x86-64.  You can override this by overriding either the 
'prefix' or 'libdir' configure variables.

[2] The Windows installer now places a copy of the TurboJPEG DLLs in the 
same directory as the rest of the libjpeg-turbo binaries.  This was 
mainly done to support TurboVNC 1.3, which bundles the DLLs in its 
Windows installation.  When using a 32-bit version of CMake on 64-bit 
Windows, it is impossible to access the c:\WINDOWS\system32 directory, 
which made it impossible for the TurboVNC build scripts to bundle the 
64-bit TurboJPEG DLL.

[3] Fixed a bug whereby attempting to encode a progressive JPEG with 
arithmetic entropy coding (by passing arguments of -progressive 
-arithmetic to cjpeg or jpegtran, for instance) would result in an 
error, "Requested feature was omitted at compile time".

[4] Fixed a couple of issues whereby malformed JPEG images would cause 
libjpeg-turbo to use uninitialized memory during decompression.

[5] Fixed an error ("Buffer passed to JPEG library is too small") that 
occurred when calling the TurboJPEG YUV encoding function with a very 
small (< 5x5) source image, and added a unit test to check for this error.

[6] The Java classes should now build properly under Visual Studio 2010 
and later.

[7] Fixed an issue that prevented SRPMs generated using the in-tree 
packaging tools from being rebuilt on certain newer Linux distributions.

[8] Numerous minor fixes to eliminate compilation and build/packaging 
system warnings, fix cosmetic issues, improve documentation clarity, and 
other general source cleanup.


New pre-release build
=====================

A new pre-release build with the roll-up of 1.3.1 fixes as well as the 
latest new features in trunk (mainly involving new features in the 
TurboJPEG API, but also MIPS DSPr2 acceleration and support for MJPEG 
frames) has been uploaded here:

http://www.libjpeg-turbo.org/DeveloperInfo/PreReleases

[Libjpeg-turbo-announce] Position statement regarding mozjpeg

[DRC <dco...@us...>]

For those who have asked about the mozjpeg project and why that code 
wasn't integrated "upstream" (libjpeg-turbo is "upstream" in this case), 
I prepared a position statement with further details:

http://www.libjpeg-turbo.org/About/Mozjpeg

Executive summary:

-- The jpgcrush code breaks ABI compatibility, so it would either have 
to be reworked using new get/set methods (a lot of trouble), or it would 
have to be #ifdef'ed, which means that Mozilla would have to maintain 
their own build anyhow.  Because of the ABI compatibility issue, the 
jpgcrush code, as currently written, could not be enabled by default in 
the official builds of libjpeg-turbo, nor could it be enabled in the 
builds that are deployed by various O/S distributors.

-- My performance results indicate that most of the 10% improvement in 
compression ratio that Mozilla is claiming comes from simply using 
progressive encoding.  The addition of jpgcrush relative to "plain" 
progressive encoding is only about a 2% difference, on average (and no 
more than a 4% difference was observed in the best case.)

-- jpgcrush slows down progressive encoding by 3-4x, and relative to 
baseline, it is 25-30x slower.  Thus, enabling it by default, as Mozilla 
wants to do, is a non-starter for us.  We'd have to change the name of 
the project to "libjpeg-turtle."

-- No one is paying for my labor to work on the jpgcrush feature, and it 
is difficult to justify any pro bono labor on it, since it does not 
benefit any of my other projects.

[Libjpeg-turbo-announce] iOS developers PLEASE READ: Major performance issue with 1.3.0 libjpeg-turbo SDK

[DRC <dco...@us...>]

Due to a build issue, the 1.3.0 version of the libjpeg-turbo SDK for OS 
X and iOS did not include SIMD code for the ARM v7 and ARM v7s 
architectures (why no one pointed this out, I have no idea.)  This is 
because the build system silently falls back to a non-SIMD build if the 
GAS preprocessor is not present in the PATH, and whenever I re-installed 
the O/S on my build machine back in May, I apparently neglected to 
re-install that program.

I've uploaded a new DMG that addresses this problem:
http://sourceforge.net/projects/libjpeg-turbo/files/1.3.0/libjpeg-turbo-1.3.0.dmg

I will also be modifying the build scripts so I can ensure that this 
failure won't occur again in the future.

Major apologies to iOS developers.  If you have built your app using 
libjpeg-turbo 1.3.0, please re-build it using the new SDK.  It should be 
somewhat faster now.  :|

DRC

Re: [Libjpeg-turbo-announce] libjpeg-turbo 1.3.0 has been released

[DRC <dco...@us...>]

A link might be helpful:

https://sourceforge.net/projects/libjpeg-turbo/files/1.3.0/


On 5/25/13 11:21 AM, DRC wrote:
> Significant changes since 1.3 beta1:
>
> [1] 'make test' now works properly on FreeBSD, and it no longer requires
> the md5sum executable to be present on other Un*x platforms.
>
> [2] Overhauled the packaging system:
> -- To avoid conflict with vendor-supplied libjpeg-turbo packages, the
> official RPMs and DEBs for libjpeg-turbo have been renamed to
> "libjpeg-turbo-official".
> -- The TurboJPEG libraries are now located under /opt/libjpeg-turbo in
> the official Linux and Mac packages, to avoid conflict with
> vendor-supplied packages and also to streamline the packaging system.
> -- Release packages are now created with the directory structure defined
> by the configure variables "prefix", "bindir", "libdir", etc. (Un*x) or
> by the CMAKE_INSTALL_PREFIX variable (Windows.)  The exception is that
> the docs are always located under the system default documentation
> directory on Un*x and Mac systems, and on Windows, the TurboJPEG DLL is
> always located in the Windows system directory.
> -- To avoid confusion, official libjpeg-turbo packages on Linux/Unix
> platforms (except for Mac) will always install the 32-bit libraries in
> /opt/libjpeg-turbo/lib32 and the 64-bit libraries in
> /opt/libjpeg-turbo/lib64.
> -- Fixed an issue whereby, in some cases, the libjpeg-turbo executables
> on Un*x systems were not properly linking with the shared libraries
> installed by the same package.
> -- Fixed an issue whereby building the "installer" target on Windows
> when WITH_JAVA=1 would fail if the TurboJPEG JAR had not been previously
> built.
> -- Building the "install" target on Windows now installs files into the
> same places that the installer does.
>
> [3] Fixed a Huffman encoder bug that prevented I/O suspension from
> working properly.

[Libjpeg-turbo-announce] libjpeg-turbo 1.3.0 has been released

[DRC <dco...@us...>]

Significant changes since 1.3 beta1:

[1] 'make test' now works properly on FreeBSD, and it no longer requires 
the md5sum executable to be present on other Un*x platforms.

[2] Overhauled the packaging system:
-- To avoid conflict with vendor-supplied libjpeg-turbo packages, the 
official RPMs and DEBs for libjpeg-turbo have been renamed to 
"libjpeg-turbo-official".
-- The TurboJPEG libraries are now located under /opt/libjpeg-turbo in 
the official Linux and Mac packages, to avoid conflict with 
vendor-supplied packages and also to streamline the packaging system.
-- Release packages are now created with the directory structure defined 
by the configure variables "prefix", "bindir", "libdir", etc. (Un*x) or 
by the CMAKE_INSTALL_PREFIX variable (Windows.)  The exception is that 
the docs are always located under the system default documentation 
directory on Un*x and Mac systems, and on Windows, the TurboJPEG DLL is 
always located in the Windows system directory.
-- To avoid confusion, official libjpeg-turbo packages on Linux/Unix 
platforms (except for Mac) will always install the 32-bit libraries in 
/opt/libjpeg-turbo/lib32 and the 64-bit libraries in 
/opt/libjpeg-turbo/lib64.
-- Fixed an issue whereby, in some cases, the libjpeg-turbo executables 
on Un*x systems were not properly linking with the shared libraries 
installed by the same package.
-- Fixed an issue whereby building the "installer" target on Windows 
when WITH_JAVA=1 would fail if the TurboJPEG JAR had not been previously 
built.
-- Building the "install" target on Windows now installs files into the 
same places that the installer does.

[3] Fixed a Huffman encoder bug that prevented I/O suspension from 
working properly.

[Libjpeg-turbo-announce] Sponsors/donations are greatly needed

[DRC <dco...@us...>]

I apologize for interrupting your regularly-scheduled programming with 
another annoying pledge break ...

I am honored to be the maintainer for libjpeg-turbo and to provide the 
enterprise-quality, open-source libjpeg-turbo SDK for free to the 
community.  However, I also don't make a salary for my work on this 
project, nor has there been any company or organization sponsoring my 
work on it for the last year.  Thus, at the moment, every hour I spend 
on libjpeg-turbo is an hour less that I have available for paying work. 
  In January, I spent a great many pro bono hours trying to sort out 
community issues related to the overall direction of this project-- 
including writing a very thorough research paper and numerous position 
statements relating to the controversy around jpeg-9.  This was, I felt, 
important work and a worthwhile investment in the long-term health of 
the project, but because of it, I was only able to bill less than 1/10 
of what I needed during January to pay for my rent and groceries.  If I 
have many more months like that, I won't be able to continue doing much 
work on libjpeg-turbo at all, or I'll have to consider other (perhaps 
unpopular) means of monetizing my labor on it.

I'm not complaining.  I love my job, and I chose to do things this way 
in part because I wanted to give something back to the community.  I'm 
just saying that this project operates a little differently than other 
prominent OSS projects, because I'm an independent developer rather than 
a salaried employee.  I maintain libjpeg-turbo with a very high focus 
and a keen eye toward producing something that is much more than just an 
open source project.  It's an enterprise-quality product, and not only 
that, it's an enterprise-quality product whose development processes are 
100% open and reproducible.  The scripts, code, and techniques used to 
produce these SDKs are "free as in freedom" as well as "free as in 
beer."  I love the fact that we are able to provide a free product that 
rivals commercial high-speed JPEG SDKs in terms of quality, ease of 
installation/use, and performance, and you'd be hard-pressed to find 
many open source projects that can make similar claims.  However, doing 
things this way takes a lot of time and calls upon my decades of 
industry experience.  If I won the lottery, I'd be very pleased to 
donate that time and experience to the community, but at the moment, I'm 
constantly scrambling to find ways of paying my bills so I can continue 
being able to provide libjpeg-turbo as a free service.

Even the smallest donation toward our cause helps out.  If your 
organization is benefiting financially from using libjpeg-turbo (for 
instance, using it in a commercial product), then please consider how 
much money you would be spending each year to renew your organization's 
licenses for a commercial high-speed JPEG SDK.  If every commercial 
organization that was using libjpeg-turbo donated even a small fraction 
of that amount to our project, we'd be set.  100% of all donation money 
is used to fund my continued labor in maintaining The libjpeg-turbo 
Project, and if there is any left over, it goes toward "hot projects" 
(see below) that currently have no sponsorship.

Donations can be made through SourceForge at the following link:

https://sourceforge.net/p/libjpeg-turbo/donate

We also have several "hot projects" that are in need of financial 
sponsorship.  If your organization could benefit from one of these, 
please consider fronting the money to pay for its development.  A list 
of these can be found here:

http://www.libjpeg-turbo.org/About/ProfessionalServices

Darrell

[Libjpeg-turbo-announce] Does your software use libjpeg-turbo? Let us know

[DRC <dco...@us...>]

I'm looking for additional software to add to the list of applications, 
operating environments, and projects that use libjpeg-turbo:

http://www.libjpeg-turbo.org/About/Software

If you know of any that aren't included on that list, please reply.

DRC

[Libjpeg-turbo-announce] libjpeg-turbo 1.2.90 (1.3 beta1) has been released

[DRC <dco...@us...>]

https://sourceforge.net/projects/libjpeg-turbo/files/1.2.90%20%281.3beta1%29/


Significant changes since 1.2.1:

[1] Added support for additional scaling factors (3/8, 5/8, 3/4, 7/8, 
9/8, 5/4, 11/8, 3/2, 13/8, 7/4, 15/8, and 2) when decompressing.  Note 
that the IDCT will not be SIMD-accelerated when using any of these new 
scaling factors.

[2] The TurboJPEG dynamic library is now versioned.  It was not strictly 
necessary to do so, because TurboJPEG uses versioned symbols, and if a 
function changes in an ABI-incompatible way, that function is renamed 
and a legacy function is provided to maintain backward compatibility. 
However, certain Linux distro maintainers will blindly reject any 
library that is not versioned, so this was an attempt to make them happy.

[3] Extended the TurboJPEG Java API so that it can be used to compress a 
JPEG image from and decompress a JPEG image to an arbitrary position in 
a large image buffer.

[4] The tjDecompressToYUV() function now supports the TJFLAG_FASTDCT flag.

[5] The 32-bit supplementary package for amd64 Debian systems now 
provides symlinks in /usr/lib/i386-linux-gnu for the TurboJPEG libraries 
in /usr/lib32.  This allows those libraries to be used on 
MultiArch-compatible systems (such as Ubuntu 11 and later) without 
setting the linker path.

[6] The TurboJPEG Java wrapper should now find the JNI library on Mac 
systems without having to pass -Djava.library.path=/usr/lib to java.

[7] TJBench has been ported to Java to provide a convenient way of 
validating the performance of the TurboJPEG Java API.  It can be run 
with 'java -cp turbojpeg.jar TJBench'.

[8] cjpeg can now be used to generate JPEG files with the RGB colorspace 
(feature ported from jpeg-8d.)

[9] The width and height in the -crop argument passed to jpegtran can 
now be suffixed with "f" to indicate that, when the upper left corner of 
the cropping region is automatically moved to the nearest iMCU boundary, 
the bottom right corner should be moved by the same amount.  In other 
words, this feature causes jpegtran to strictly honor the specified 
width/height rather than the specified bottom right corner (feature 
ported from jpeg-8d.)

[10] JPEG files using the RGB colorspace can now be decompressed into 
grayscale images (feature ported from jpeg-8d.)

[11] Fixed a regression caused by 1.2.1[7] whereby the build would fail 
with multiple "Mismatch in operand sizes" errors when attempting to 
build the x86 SIMD code with NASM 0.98.

[12] The in-memory source/destination managers (jpeg_mem_src() and 
jpeg_mem_dest()) are now included by default when building libjpeg-turbo 
with libjpeg v6b or v7 emulation, so that programs can take advantage of 
these functions without requiring the use of the backward-incompatible 
libjpeg v8 ABI.  The "age number" of the libjpeg-turbo library on Un*x 
systems has been incremented by 1 to reflect this.  You can disable this 
feature with a configure/CMake switch in order to retain strict API/ABI 
compatibility with the libjpeg v6b or v7 API/ABI (or with previous 
versions of libjpeg-turbo.)  See README-turbo.txt for more details.

[13] Added ARM v7s architecture to libjpeg.a and libturbojpeg.a in the 
official libjpeg-turbo binary package for OS X, so that those libraries 
can be used to build applications that leverage the faster CPUs in the 
iPhone 5 and iPad 4.

[Libjpeg-turbo-announce] libjpeg-turbo 1.2.1 has been released

[DRC <dco...@us...>]

https://sourceforge.net/projects/libjpeg-turbo/files/1.2.1/

Significant changes since 1.2.0
===============================

[1] Creating or decoding a JPEG file that uses the RGB colorspace should
now properly work when the input or output colorspace is one of the
libjpeg-turbo colorspace extensions.

[2] When libjpeg-turbo was built without SIMD support and merged
(non-fancy) upsampling was used along with an alpha-enabled colorspace
during decompression, the unused byte of the decompressed pixels was not
being set to 0xFF.  This has been fixed.  TJUnitTest has also been
extended to test for the correct behavior of the colorspace extensions
when merged upsampling is used.

[3] Fixed a bug whereby the libjpeg-turbo SSE2 SIMD code would not
preserve the upper 64 bits of xmm6 and xmm7 on Win64 platforms, which
violated the Win64 calling conventions.

[4] Fixed a regression caused by 1.2.0[6] whereby decompressing corrupt
JPEG images (specifically, images in which the component count was
erroneously set to a large value) would cause libjpeg-turbo to segfault.

[5] Worked around a severe performance issue with "Bobcat" (AMD Embedded
APU) processors.  The MASKMOVDQU instruction, which was used by the
libjpeg-turbo SSE2 SIMD code, is apparently implemented in microcode on
AMD processors, and it is painfully slow on Bobcat processors in
particular.  Eliminating the use of this instruction improved
performance by an order of magnitude on Bobcat processors and by a small
amount (typically 5%) on AMD desktop processors.

[6] Added SIMD acceleration for performing 4:2:2 upsampling on
NEON-capable ARM platforms.  This speeds up the decompression of 4:2:2
JPEGs by 20-25% on such platforms.

[7] Fixed a regression caused by 1.2.0[2] whereby, on Linux/x86
platforms running the 32-bit SSE2 SIMD code in libjpeg-turbo,
decompressing a 4:2:0 or 4:2:2 JPEG image into a 32-bit (RGBX, BGRX,
etc.) buffer without using fancy upsampling would produce several
incorrect columns of pixels at the right-hand side of the output image
if each row in the output image was not evenly divisible by 16 bytes.

[8] Fixed an issue whereby attempting to build the SIMD extensions with
Xcode 4.3 on OS X platforms would cause NASM to return numerous errors
of the form "'%define' expects a macro identifier".

[9] Added flags to the TurboJPEG API that allow the caller to force the
use of either the fast or the accurate DCT/IDCT algorithms in the
underlying codec.