mozjpeg

**Arkanosis** · 6th March 2014, 16:56

Hi everyone,

Mozilla is forking libjpeg-turbo and seeks to improve compression ratio while maintaining compatibility.

Announcement: https://blog.mozilla.org/research/20...zjpeg-project/
GitHub: https://github.com/mozilla/mozjpeg
Branch with jpgcrush: https://github.com/mozilla/mozjpeg/tree/crush

Best regards

**lorents17** · 6th March 2014, 20:16

Please compile a version for windows?

**caveman** · 6th March 2014, 21:28

IMHO It looks like a joke for now and it will probably never be better than JPEGmini+JPEGrescan, they should rather follow Google and WebP.
And contrary to what they say JPEG is not universally supported, try to open this one in Photoshop.

**Mangix** · 6th March 2014, 22:54

from a quick look all it looks like is they've changed the cjpeg defaults to output progressive jpegs.

**thorfdbg** · 6th March 2014, 23:13

Originally Posted by caveman

IMHO It looks like a joke for now and it will probably never be better than JPEGmini+JPEGrescan, they should rather follow Google and WebP.

Which is not backwards compatible. Thus, causes a lot of problems.... don't try.

Originally Posted by caveman

And contrary to what they say JPEG is not universally supported, try to open this one in Photoshop.

That's not quite correct. There are many modes of JPEG that are not widely supported. Consider the hierarchical mode, consider the lossless mode or the AC-coding mode. The above image is just another example of something that is not widely supported, and should not be done. It uses a 3x3 chroma subsampling, rather pointless.

JPEG would even allow a 7/5th subsampling for component 1 and a 5/13 subsampling for component 2 if asked for. How many codecs support this? None.

This being said, the above file does not conform to 18477-1 (JPEG XT baseline), where we exactly excluded the not widely supported wierd cases. Don't do this.

**thorfdbg** · 6th March 2014, 23:25

We'll find out what they are after. I sent them a ping.

**caveman** · 6th March 2014, 23:31

Originally Posted by thorfdbg

That's not quite correct. There are many modes of JPEG that are not widely supported. Consider the hierarchical mode, consider the lossless mode or the AC-coding mode. The above image is just another example of something that is not widely supported, and should not be done. It uses a 3x3 chroma subsampling, rather pointless.

JPEG would even allow a 7/5th subsampling for component 1 and a 5/13 subsampling for component 2 if asked for. How many codecs support this? None.

What's the point to write and publish specs when what finally makes the standard is only a small subset of those? Lousy implementation has the final word?

**AiZ** · 6th March 2014, 23:54

Win32 mozjpeg 1.0
mozjpeg10_win32.7z

Quick test
Original JPG: 10 446 493 bytes
jpeg9a > jpegtran -copy none -optimize: 9 077 585 bytes
jpeg9a > jpegtran -copy none -optimize -progressive: 8 471 135 bytes
mozjpeg 1.0 > jpegtran -copy none -optimize -fastcrush (Disable progressive scan optimization): 8 481 975 bytes
mozjpeg 1.0 > jpegtran -copy none -optimize : 8 429 833 bytes

As Mangix said, progressive is automatically set.

**Mangix** · 7th March 2014, 01:09

I keep getting "Premature end of JPEG fileJPEG datastream contains no image
" with these binaries.

I'd love to see comparisons with jpegrescan as well.

**roytam1** · 7th March 2014, 03:56

gcc-4.8.1 CFLAGS="-O3 -fomit-frame-pointer -flto -ffunction-sections -Wl,--gc-sections -fno-asynchronous-unwind-tables -Wl,--strip-all -pipe -s" UPX --lzma --best binary attached.

**Mangix** · 7th March 2014, 07:22

this thing is extremely buggy. I haven't found a JPEG where it will work.

**thorfdbg** · 7th March 2014, 09:15

Originally Posted by caveman

What's the point to write and publish specs when what finally makes the standard is only a small subset of those?

How can those that write up the specs enforce those that use the specs which parts of it they should use? It is the market that decides whether a specific standard is accepted completely, or only partially, or not at all. In fact, this is a very typical situation that only a subset of a standard is adopted by the market - not different from any other standards.

Originally Posted by caveman

Lousy implementation has the final word?

An implementation is not "lousy" because it only uses a subset of the specs. It is lousy if it implements something *different from* the specs (this is what the latest IJG stuff does - just willingly breaking specs). With one exception, there is probably no attempt to even provide a codec that supports all the coding tools of JPEG-1. There is no complete implementation of JPEG 2000 part 2 in the world, neither any implementation of JPEG-3 or JPEG LS-2. ITU.T 851 has never been adopted (another modification of JPEG). All extensions that were only partially adopted (if at all), because they are only relevant in certain fields.

**AiZ** · 7th March 2014, 10:25

@Mangix
Please try again with the -outfile switch to output your JPEG file, don't use redirection (>).

**AiZ** · 7th March 2014, 11:55

Updated with jpegrescan

Original JPG: 10 446 493 bytes
jpeg9a > jpegtran -copy none -optimize: 9 077 585 bytes
jpeg9a > jpegtran -copy none -optimize -progressive: 8 471 135 bytes
mozjpeg 1.0 > jpegtran -copy none -optimize -fastcrush (Disable progressive scan optimization): 8 481 975 bytes
mozjpeg 1.0 > jpegtran -copy none -optimize : 8 429 833 bytes
jpegrescan -s: 8 429 888 bytes

As mozjpeg reuse the jpgcrush/jpgrescan stuff, seems legit.

**Mangix** · 8th March 2014, 00:49

Hmm after testing a few samples I can conclude that this is just jpegrescan but in .exe form. On each sample, the md5sum of a jpeg that's gone through jpegrescan and one that's gone through mozjpegtran is the same.

I think I should do more testing. Right now I can think of one further optimization that can be done. Remove or comment out lines 482 and 483 in jcmarker.c . This will save 18 bytes per file. This is what I've been doing with my own compiles of jpegtran.

edit: It seems that they are using an outdated version of libjpeg-turbo. I reported a bunch of bugs regarding arithmetic mode combined with progressive mode that have been fixed. Relevant commits are here: http://sourceforge.net/p/libjpeg-tur...commit_browser

Specifically 1079, 1048, and 1031.

**roytam1** · 8th March 2014, 04:55

isn't arithmetic mode is not supported by most of decoders?
So mozilla won't care about this.

**Mangix** · 8th March 2014, 05:42

it seems to be a bug in the last build that was posted here. when i checked github, the code was recent.

**thorfdbg** · 8th March 2014, 16:07

Originally Posted by Mangix

I think I should do more testing. Right now I can think of one further optimization that can be done. Remove or comment out lines 482 and 483 in jcmarker.c . This will save 18 bytes per file. This is what I've been doing with my own compiles of jpegtran.

edit: It seems that they are using an outdated version of libjpeg-turbo. I reported a bunch of bugs regarding arithmetic mode combined with progressive mode that have been fixed.

I don't think 18 bytes is worth worrying about, but yes, if you want to optimize this, there is quite some potential. For example "soft thresholding" to improve the R/D performance, or application of visual masking aka "DCTune" to improve efficiency when optimizing for the human eye.

I don't think anyone actually uses arithmetic, thus they really don't care about. It's another one of these "dead modes" of JPEG.

**roytam1** · 12th March 2014, 16:04

just caught a bug which will cause segfault on certain files.
https://github.com/mozilla/mozjpeg/issues/23

**lorents17** · 29th March 2014, 15:13

compile, please, mozjpeg v1.0.1 for Windows

**avitar** · 29th March 2014, 15:38

Did I miss something? - there was request for a windows version- where is it please? John

**roytam1** · 30th March 2014, 09:42

v1.0.1 ICC 9.1 /Qipo /QaxT ICCPatched static jpegtran build uploaded.

**lorents17** · 30th March 2014, 11:34

Thank you very much!

Could you explain the steps to compile and what program you use for this?

**roytam1** · 30th March 2014, 11:49

Originally Posted by lorents17

Thank you very much!

Could you explain the steps to compile and what program you use for this?

I use CMake to generate visual studio project files

**avitar** · 30th March 2014, 14:48

Thanks for to author & for win version. Tried it but no success.

Maybe author of this thread could add these comments, if valid, to the issues list. Didn't find the help very useful - doesn't mention an output file & the parameters are a bit (or a lot) obscure IMO!

Also how about 1 or 2 examples of use, pls & some text
eg translates jpegs & stores results in ???? (if that is what it does). Does it work for jpgs etc etc - just needs 2 lines or so.

tried
mozjpegtran jum.jpg

Give message cannot write to jim.jpg

**nikkho** · 30th March 2014, 17:56

Originally Posted by roytam1

v1.0.1 ICC 9.1 /Qipo /QaxT ICCPatched static jpegtran build uploaded.

Thank you very much. Working totally fine

A difference I discovered against original jpegtran, is that in jpegtran it was possible to specify the target JPEG file to create, while mozjpegtran is always outputing its to stdout. Just curious.

**roytam1** · 30th March 2014, 19:05

Originally Posted by avitar

Thanks for to author & for win version. Tried it but no success.

Maybe author of this thread could add these comments, if valid, to the issues list. Didn't find the help very useful - doesn't mention an output file & the parameters are a bit (or a lot) obscure IMO!

Also how about 1 or 2 examples of use, pls & some text
eg translates jpegs & stores results in ???? (if that is what it does). Does it work for jpgs etc etc - just needs 2 lines or so.

tried
mozjpegtran jum.jpg

Give message cannot write to jim.jpg

http://encode.su/threads/1892-mozjpe...ll=1#post37018

**thorfdbg** · 5th April 2014, 00:15

Short update on the issue. I've contact. The folks from mozjpeg received the (parts of) the JPEG test image set to have something to work with, at least the part I have releases for. As this week was a joint JPEG/MPEG meeting, I found that the developer and scientific head behind mozjpeg is an MPEG member (I'm JPEG), so we had a nice chat. Thus, I believe the code is in good hands and they are doing a good job in the right direction. I was somehow afraid that mozjpeg would be another "something like JPEG but incompatible codec", sort of the same nonsense that the one-man IJ Group does, but that is not at all the case. It's an updated JPEG implementation that exploits the available freedom in the encoder and thus improves performance - there are lots of papers available on such methods, actually. Thus, thumbs up from my side.

**roytam1** · 14th April 2014, 18:09

update binary with pengvado's patch making progress faster by 36% in encode_mcu_AC_first(), 15% overall time improvement.
https://github.com/pengvado/mozjpeg/...75ec011f804468

**nikkho** · 15th April 2014, 09:10

Originally Posted by roytam1

update binary with pengvado's patch making progress faster by 36% in encode_mcu_AC_first(), 15% overall time improvement.
https://github.com/pengvado/mozjpeg/...75ec011f804468

Thank you very much for the compile.

Thread: mozjpeg

Thread Tools

Search Thread

Display

mozjpeg

Thanks:

Thanks:

Thanks (2):

Thanks:

Thanks (2):

Thanks:

Thanks (2):

Posting Permissions