Recent changes to patches

#55 Low memory progressive JPEG decode

2016-07-12T12:03:31.146000Z

Thanks for reporting this - please create an issue over on github and I will take a look

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

#55 Low memory progressive JPEG decode

2016-07-12T08:17:29.525000Z

The "Low memory progressive JPEG decode" solution help me a lot !
But it's some problem with this file(60x44.jpg)...
Appear "Corrupt JPEG data: bad Huffman code" debug message, it's fail to decode.
But I mark the config, LOWMEM_PROGRESSIVE_DECODE, it's sucess!

#57 Use intrinsic functions for bit counting to reduce footprint

2016-01-14T06:36:43.327000Z

Another user contributed a NEON implementation of Huffman encoding, which has been checked into git master: https://github.com/libjpeg-turbo/libjpeg-turbo. I was wondering if you (Olle) could do some quick & dirty benchmarks with this new code to make sure it hasn't regressed on the devices you tested above.

#55 Low memory progressive JPEG decode

2015-08-05T12:41:10.863000Z

you should be able to fork the repository and maintain your own
copy of it with the low-memory progressive decode patch included
I created a fork here:
https://github.com/komakai/libjpeg-turbo
I hope someday to address the ABI compatibility issue but probably it will not be soon so for now this patch will live in its own fork.
Appreciate all the comments and suggestions - thanks.

#74 java: more exception improvements

2015-07-27T22:12:58.297000Z

Description has changed:

Diff:

--- old
+++ new
@@ -1,4 +1,3 @@
-
 Continuing #72, attached a patch with more Java API cleanup around exceptions. This is a relatively conservative step, still using checked exception (TJException) where appropriate. This could be made more specific, depending on what error conditions might make sense (e.g. ImageFormatException).

 Note, that I have not updated the corresponding native code.

status: open --> closed-integrated

#74 java: more exception improvements

2015-07-27T22:12:40.301000Z

git master branch now contains my latest & greatest version of this:

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

Please let me know if anything else is broken (you can reply here or create a new issue or pull request on GitHub if you prefer.)

#55 Low memory progressive JPEG decode

2015-07-27T22:10:00Z

status: open-seeking-sponsorship --> closed-wont-integrate

#55 Low memory progressive JPEG decode

2015-07-27T22:09:45.841000Z

FYI-- our code is now on GitHub at https://github.com/libjpeg-turbo/libjpeg-turbo, so you should be able to fork the repository and maintain your own copy of it with the low-memory progressive decode patch included. I would also suggest looking at the backward ABI compatibility framework I wrote for mozjpeg, which you might be able to use to implement this feature in a manner that doesn't break backward ABI compatibility (although I'm not sure how you'd handle cinfo->scancontextctl.)

Closing this tracker item, at least for now, since there is not sufficient demand for this feature in the community to justify the work required to integrate it properly (and I'm not sure if it could ever be integrated in a way that would preserve ABI compatibility.) I will reconsider integrating it if the feature can be developed in a more project-friendly manner, i.e.:

It must not break ABI compatibility.
It must have appropriate regression tests added to Makefile.am, so I can run 'make test' and immediately tell whether something is broken in the feature.
I would need to secure some sponsorship money to help pay for my labor to integrate and maintain the feature (even the best-designed patches generally require a lot of work to test and integrate.)

#70 Implementation of jpeg_skip_scanlines(JDIMENSION rows) API to optimize subset decodes

2015-07-21T20:39:51.656000Z

Nice! I'll get that integrated as soon as the repositories are back online.

#70 Implementation of jpeg_skip_scanlines(JDIMENSION rows) API to optimize subset decodes

2015-07-21T19:53:36.924000Z

If you're interested, I'm attaching another patch to fix a valgrind error.

Valgrind complains on color conversion to 565, when skip() calls read() to read into the dummy buffer. Valgrind is upset because the dummy read() uses table lookup on garbage data.

This can be fixed by adding a noop_convert() routine that we use on dummy reads. This has additional positive consequences of eliminating the need for a dummy row buffer and eliminating a step on dummy reads.