4 ms·
Huh, I always just used good ol’ jpegtran: jpegtran -copy none -optimize -progressive -outfile "$image" "$image" I have a wrapper script around this to allo
by oefrha 7y ago
Huh, I always just used good ol’ jpegtran:
jpegtran -copy none -optimize -progressive -outfile "$image" "$image"
I have a wrapper script around this to allow bulk optimization as well as calculating stats.
Time to switch I guess.
- marton78 7y agoYou should use mozjpeg instead. It's a jpegtran fork and drop in replacement which optimizes the Huffman table even better.
- oefrha 7y agoActually, I’ve been using mozjpeg’s version of jpegtran instead of libjpeg’s for god knows how long.
- jonsneyers 7y agoDoes it really optimize the Huffman trees better? I wouldn't think there's more you can do to optimize Huffman trees than make them reflect the actual histogram. Mozjpeg does try different progressive scan scripts – different scripts lead to different compression behavior. That helps a bit, though I don't like it when it separates the Cb and Cr planes, becauses that leads to "flash of weird color" when decoding progressively. See also: https://cloudinary.com/blog/progressive_jpegs_and_green_martians https://cloudinary.com/blog/progressive_jpegs_and_green_mart...
- jonsneyers 7y agoJPEG -> JPEG optimization certainly makes sense, since it doesn't require any decoder to be updated. JPEG -> [something else] compression (like Brunsli or Lepton) can compress better though, since they can use (better) predictors, entropy coding, context modeling, etc. But they do require either a new decoder (saving both bandwidth and storage), or an on-the-fly conversion back to JPEG (saving only storage; bandwidth wouldn't change).