Introducing the ‘mozjpeg’ Project

Re:Introducing the ‘mozjpeg’ Project by tenfingers on Wednesday March 05, 2014 @02:54PM (#7349404)

I noticed that optimizing JPEG images using jpegoptim (http://www.kokkonen.net/tjko/projects.html) reduces the size by a similar factor, but at the expense of decoding speed.

In fact, on a JPEG-heavy site that I was testing with FF 26, there was such a degradation in terms of responsiveness that transitions would stutter whenever a new image was decoded in the background (while preloading).

It made the effort to save 2-4% in size wasted with a worse user experience.

[ Parent | on HN ]

Re:Introducing the ‘mozjpeg’ Project by gcp on Wednesday March 05, 2014 @03:35PM (#7349691)

Did you file a bug for this? This doesn't sound normal at all.

[ Parent | on HN ]

Re:Introducing the ‘mozjpeg’ Project by tenfingers on Thursday March 06, 2014 @06:06AM (#7353025)

Honestly, no. libjpeg would show similar slowdown (interestingly, PNG decoding is slower than JPEG for the same size), and it make sense anyway.

The problem is that even if the bug would be fixed in recent FF versions, libjpeg is basically used in all other browsers as well.

[ Parent | on HN ]

Re:Introducing the ‘mozjpeg’ Project by pornel on Thursday March 06, 2014 @06:23AM (#7353071)

I'm using jpegoptim extensively and haven't noticed such behavior.

All jpegoptim does is rewrite JPEG with optimized Huffman tables, so it shouldn't have any impact on decoding performance. In the process it also changes progressive to baseline, which is even slightly faster to decode.

If you can reproduce the problem with libjpeg-turbo (which is the library that browsers use) you should definitely file a bug.

[ Parent | on HN ]