Page 1 of 4 123 ... LastLast
Results 1 to 30 of 102

Thread: mozjpeg

  1. #1
    Member
    Join Date
    May 2008
    Location
    France
    Posts
    48
    Thanks
    1
    Thanked 1 Time in 1 Post

    mozjpeg

    Hi everyone,

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



    Best regards
    Jérémie

  2. #2
    Member
    Join Date
    Apr 2011
    Location
    Russia
    Posts
    168
    Thanks
    163
    Thanked 9 Times in 8 Posts
    Please compile a version for windows?

  3. #3
    Member caveman's Avatar
    Join Date
    Jul 2009
    Location
    Strasbourg, France
    Posts
    190
    Thanks
    8
    Thanked 64 Times in 33 Posts
    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.

  4. #4
    Member
    Join Date
    Jun 2013
    Location
    USA
    Posts
    98
    Thanks
    4
    Thanked 14 Times in 12 Posts
    from a quick look all it looks like is they've changed the cjpeg defaults to output progressive jpegs.

  5. #5
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    Quote Originally Posted by caveman View Post
    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.

    Quote Originally Posted by caveman View Post
    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.

  6. #6
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    We'll find out what they are after. I sent them a ping.

  7. #7
    Member caveman's Avatar
    Join Date
    Jul 2009
    Location
    Strasbourg, France
    Posts
    190
    Thanks
    8
    Thanked 64 Times in 33 Posts
    Quote Originally Posted by thorfdbg View Post
    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?

  8. Thanks:

    just a worm (7th March 2014)

  9. #8
    Member
    Join Date
    May 2009
    Location
    France
    Posts
    99
    Thanks
    13
    Thanked 75 Times in 45 Posts
    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.
    Last edited by AiZ; 7th March 2014 at 00:27. Reason: More cases.

  10. #9
    Member
    Join Date
    Jun 2013
    Location
    USA
    Posts
    98
    Thanks
    4
    Thanked 14 Times in 12 Posts
    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.

  11. #10
    Member
    Join Date
    May 2008
    Location
    HK
    Posts
    160
    Thanks
    4
    Thanked 25 Times in 15 Posts
    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.
    Attached Files Attached Files

  12. Thanks:

    spark (2nd May 2014)

  13. #11
    Member
    Join Date
    Jun 2013
    Location
    USA
    Posts
    98
    Thanks
    4
    Thanked 14 Times in 12 Posts
    this thing is extremely buggy. I haven't found a JPEG where it will work.

  14. #12
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    Quote Originally Posted by caveman View Post
    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.

    Quote Originally Posted by caveman View Post
    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.

  15. #13
    Member
    Join Date
    May 2009
    Location
    France
    Posts
    99
    Thanks
    13
    Thanked 75 Times in 45 Posts
    @Mangix
    Please try again with the -outfile switch to output your JPEG file, don't use redirection (>).
    Last edited by AiZ; 7th March 2014 at 10:29. Reason: Call me stupid

  16. Thanks (2):

    lorents17 (7th March 2014),roytam1 (7th March 2014)

  17. #14
    Member
    Join Date
    May 2009
    Location
    France
    Posts
    99
    Thanks
    13
    Thanked 75 Times in 45 Posts
    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.

  18. #15
    Member
    Join Date
    Jun 2013
    Location
    USA
    Posts
    98
    Thanks
    4
    Thanked 14 Times in 12 Posts
    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.
    Last edited by Mangix; 8th March 2014 at 01:09.

  19. Thanks:

    PSHUFB (9th August 2014)

  20. #16
    Member
    Join Date
    May 2008
    Location
    HK
    Posts
    160
    Thanks
    4
    Thanked 25 Times in 15 Posts
    isn't arithmetic mode is not supported by most of decoders?
    So mozilla won't care about this.

  21. #17
    Member
    Join Date
    Jun 2013
    Location
    USA
    Posts
    98
    Thanks
    4
    Thanked 14 Times in 12 Posts
    it seems to be a bug in the last build that was posted here. when i checked github, the code was recent.

  22. #18
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    Quote Originally Posted by Mangix View Post
    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.

  23. #19
    Member
    Join Date
    May 2008
    Location
    HK
    Posts
    160
    Thanks
    4
    Thanked 25 Times in 15 Posts
    just caught a bug which will cause segfault on certain files.
    https://github.com/mozilla/mozjpeg/issues/23

  24. #20
    Member
    Join Date
    Apr 2011
    Location
    Russia
    Posts
    168
    Thanks
    163
    Thanked 9 Times in 8 Posts
    compile, please, mozjpeg v1.0.1 for Windows
    Last edited by lorents17; 29th March 2014 at 16:36.

  25. #21
    Member
    Join Date
    Sep 2011
    Location
    uk
    Posts
    239
    Thanks
    189
    Thanked 17 Times in 12 Posts
    Did I miss something? - there was request for a windows version- where is it please? John

  26. #22
    Member
    Join Date
    May 2008
    Location
    HK
    Posts
    160
    Thanks
    4
    Thanked 25 Times in 15 Posts
    v1.0.1 ICC 9.1 /Qipo /QaxT ICCPatched static jpegtran build uploaded.
    Attached Files Attached Files

  27. Thanks (2):

    lorents17 (30th March 2014),spark (2nd May 2014)

  28. #23
    Member
    Join Date
    Apr 2011
    Location
    Russia
    Posts
    168
    Thanks
    163
    Thanked 9 Times in 8 Posts
    Thank you very much!

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

  29. #24
    Member
    Join Date
    May 2008
    Location
    HK
    Posts
    160
    Thanks
    4
    Thanked 25 Times in 15 Posts
    Quote Originally Posted by lorents17 View Post
    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

  30. Thanks:

    lorents17 (30th March 2014)

  31. #25
    Member
    Join Date
    Sep 2011
    Location
    uk
    Posts
    239
    Thanks
    189
    Thanked 17 Times in 12 Posts
    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

  32. #26
    Member nikkho's Avatar
    Join Date
    Jul 2011
    Location
    Spain
    Posts
    552
    Thanks
    223
    Thanked 165 Times in 106 Posts
    Quote Originally Posted by roytam1 View Post
    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.

  33. #27
    Member
    Join Date
    May 2008
    Location
    HK
    Posts
    160
    Thanks
    4
    Thanked 25 Times in 15 Posts
    Quote Originally Posted by avitar View Post
    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

  34. #28
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    448
    Thanks
    1
    Thanked 101 Times in 61 Posts
    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.

  35. #29
    Member
    Join Date
    May 2008
    Location
    HK
    Posts
    160
    Thanks
    4
    Thanked 25 Times in 15 Posts
    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
    Attached Files Attached Files
    Last edited by roytam1; 15th April 2014 at 04:19.

  36. Thanks (2):

    lorents17 (15th April 2014),spark (2nd May 2014)

  37. #30
    Member nikkho's Avatar
    Join Date
    Jul 2011
    Location
    Spain
    Posts
    552
    Thanks
    223
    Thanked 165 Times in 106 Posts
    Quote Originally Posted by roytam1 View Post
    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.

Page 1 of 4 123 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •