8 ms·
Brunsli: Practical JPEG repacker (now part of JPEG XL)
- jncraton 7y agoDoes anyone know how this compares to other projects such as Lepton? https://github.com/dropbox/lepton https://github.com/dropbox/lepton The goals and results appear similar. Is the primary difference that brunsli will likely actually be part of a standard (JPEG XL)?
- gbanfalvi 7y agoAnd how does it compare against HEIF?
- 0-_-0 7y agoHEIF can't compress JPEG images losslessly
- rndgermandude 7y agoIndeed, HEIF/HEIC is basically a slightly dumbed down HEVC (h.265) i-frame (full frame) (HEIC)[1] and new container format (HEIF)[2], similar to WEBP being VP8 i-frames in a RIFF container. So they are used as full blown codecs in practice, usually not in a lossless mode, so shifting JPEG to HEIC or WEBP will lose some quality. [1] Decoding HEIC in Windows (10) requires you to have installed a compatible HEVC decoder. Which is 99 cents (and the hassle of setting up a store accounts and payment processing with MS) or an alternative free one which will use the HEVC codec that is shipped with hardware such as newer Intels (QSV) or GPUs. Thank you patent mess! [2] HEIF the container format can contain JPEG data, but in practice does not or only as a supplementary image (previews, pre-renders, thumbnails, etc)
- deleted 7y ago[deleted]
- ksec 7y agoBelow 0.5 bpp, both HEIF or BPG [1] and AVIF performs quite a bit better than JPEG XL , XL shines in 0.8 bpp. At least in initial testing. [1] https://bellard.org/bpg/ https://bellard.org/bpg/
- ajnin 7y agoDo you have a link for JPEG XL comparisons ? The comparisons on that page are with JPEG XR, which is a different thing.
- ksec 7y agoUnfortunately It couldn't find the exact one, it was from the author's presentation against a few other codec on common metrics such as PSNR and SSIM. There is a thread on Doom9 [1] with similar results though. [1] https://forum.doom9.org/showpost.php?p=1894341&postcount=167 https://forum.doom9.org/showpost.php?p=1894341&postcount=167
- duskwuff 7y agoNot comparable. Brunsli and Lepton are lossless compressors for JPEG files; HEIF is a completely different lossy image encoder. To compare the size of a Brunsli/Lepton encoded JPEG file with an HEIF image, you'd need to define some sort of quality equivalence between the two, which gets complicated fast.
- todotask 7y agoHave you tried to test on your machine? You'll see various results with lossless/lossy image optimisers. I got <22% with Brunsli.
- llarsson 7y agoTheir respective READMEs both claim a 22% size reduction, which sounds like an interesting coincidence. Have they identified a similar inefficiency in the format itself?
- ksec 7y agoJPEG's entropy encoding is ancient. Adding modern arithmetic coding can save significant bits without changing the actual visual data.
- robryk 7y agoAnother inefficiency of JPEG is that each block (8x8 pixels in size) is compressed independently[^]. This means that the correlations between pixels that are adjacent across a block boundary are not used. If I were to take a JPEG image and randomly flip its blocks (mirror them along x and/or y axis), the resulting JPEG would have a very similar filesize, even though it's a much less likely image. Brunsli and, IIUC, Lepton, make use of these correlations. [^] the average color of blocks is not compressed strictly independently, but the space used on those is small compared to all the rest of the information about a block Disclaimer: I've worked on Brunsli.
- londons_explore 7y agoThat might prove to be a good measure of image compression 'efficiency'. Present to a user two images, one an image compressed by image compressor X, and one compressed by the same image compressor with a single bit of output flipped. In an ideal image compression scenario, the decompressed images would not be the same, but a user could not tell which was the 'correct' image, since both would look equally realistic.
- robryk 7y agoIf a scheme had something like that property and satisfied some simpler conditions, I would wager that it necessarily is a good compression scheme. However, this is very much not required of a good compression scheme: Imagine that a compression scheme used the first bit to indicate if the encoded image is an image of a cat or not. Changing that bit would then have very obvious and significant implications on the encoded image. If that example seems too unrealistic, imagine a modification of a compression scheme that, before decoding, xors every non-first bit with the first bit. Then flipping the first bit in the modified scheme is equivalent to flipping a lot of bits in the unmodified scheme, but they are equivalently good at encoding images. Edit: To put it short, the important property is that equally-long encoded images are "equally plausible": it's not important how many bits differ between them, and it doesn't matter if they are similar to each other.
- tpetry 7y agoThe files created by lepton cant be displayed by any client. Brunsli is a converter for JPEG <-> JPEG XR which is losless, and by the improved jpeg xr algorithms decreases filesize. The interesting part is you can therefore convert between these formats thousands of times without visual regressions. You could (in a few years) only store the jpeg xr file and your webserver may transcode it to jpeg for legacy browsers.
- ksec 7y ago>Brunsli is a converter for JPEG <-> JPEG XR which is losless... You mean JPEG XL? JPEG XR is a completely different thing [1] [1] https://en.wikipedia.org/wiki/JPEG_XR https://en.wikipedia.org/wiki/JPEG_XR
- thedance 7y agoThey may still be comparable. If the point of Lepton is to save space, and if a round-trip through Brunsli costs less than Lepton encoding while saving similar amounts of space, then it could be a design alternative.
- JyrkiAlakuijala 7y agoSingle-threaded brunsli runs 2.5x faster than single-threaded lepton, but brunsli compresses 1 % less. Brunsli is able to compress more JPEGs (including more exotic JPEG configurations) than lepton.
- thedance 7y agoJust to put numbers on this, on an Intel Skylake CPU, brunsli compressed a 1MB image in .16s, lepton needed .5s, more than triple the CPU time. Brunsli peaked at 100MB while lepton peaked at 44MB of RAM. Decoding with lepton wants .23s and 8MB of RAM while brunsli used .13s and 42MB of RAM.
- oefrha 7y agoHuh, 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).
- taf2 7y agoI like the check list for features... can't wait for "Nginx transcoding module"
- deleted 7y ago[deleted]
- sischoel 7y agoIf someone is wondering where the name comes from: https://www.saveur.com/article/Recipes/Basler-Brunsli-Chocolate-Almond-Spice-Cookies/ https://www.saveur.com/article/Recipes/Basler-Brunsli-Chocol... Not sure if it is the best recipe - the ones I use are usually written in German.
- waffle_ss 7y agoBrotli, another compression algorithm created by Google is also named after a Swiss baked good: https://en.wikipedia.org/wiki/Spanisch_Br%C3%B6tli https://en.wikipedia.org/wiki/Spanisch_Br%C3%B6tli
- pw6hv 7y agoZopfli also comes from a Swiss bakery product. Developers must like carbohydrates :)
- spider-mario 7y agoAnd let’s not forget Gipfeli and Knusperli ;) https://github.com/google/gipfeli https://github.com/google/gipfeli https://github.com/google/knusperli https://github.com/google/knusperli
- camillovisini 7y agoHow about grittibanzli? https://github.com/google/grittibanzli https://github.com/google/grittibanzli
- crazygringo 7y agoSorry, can someone here clarify -- Does this reduce the size of JPEG files, maintaining JPEG format? Or is this about repacking JPEG files into JPEG XL files (while reducing size), while maintaining the ability to losslessly revert to JPEG? The page never explicitly states what format the "repacking" is into, and it has so many references to JPEG XL that it no longer seems obvious that it's into just JPEG?
- donatj 7y agoMy understanding is it converts normal JPEGs to incompatible JPEG XL files, losslessly. The README does a poor job explaining this.
- rndgermandude 7y agoIt does not maintain the JPEG format, tho it will be part of the JPEG XL format. It is repacking/recoding jpegs in a lossless and reversible manner, so that clients supporting brunsli can be served directly with the optimized version (their apache and nginx modules seem to serve files with a image/x-j mime), and clients without support can be served with the original jpeg file (or served with a brunsli file and decoded with a wasm-brunsli->native jpeg decoder pipeline if wasm is an option), while you only have to keep the brunsli (or original jpeg) file around. Since JPEG XL isn't finished yet, there still might be minor differences in the end that make the current brunsli format incompatible to the JPEG XL format, so I wouldn't mass-convert your files just yet.
- rndgermandude 7y agoPreemptive disclaimer: I don't want to belittle the work the authors did here in any way, and are actually excited especially about the reversible, lossless jpeg<->brunsli coding and that google's buy in and network effects will most likely mean this comes to a viewer/editing software near you in the not so distant future (unlike lepton, which never got out of it's tiny niche). But seeing the 22% improvement figure reminded me that the typical JPEG file on the internet is rather unoptimized even on write-once-read-many services like imgur or i.reddit.com which transform files (stripping meta data etc) and do not preserve the original files. Just using the regular vanilla libjpeg encoder you can usually save 5%-10% just by lossless recoding of the coeffs and the better-yet-more-computionally-intense mozjpeg coder can even get you a bit further than that. Then again, the imgur single image view page (desktop) I just randomly opened by randomly clicking an item on their homepage transfers 2.9MiB of data with ads blocked (3.9MiB deflated), 385KiB of which was the actual image, and that image can be lossless recoded by mozjpeg to 361KiB (24KiB difference, a 6.2% reduction), so the 24KiB (0.8%) reduction out of 2.9MiB of cruft hardly matters to them I suppose and may be cheaper in bandwidth and storage cost to them than the compute cost (and humans writing and maintaining the code). Using brunsli, that same 385KiB imgur file went down to 307KiB so roughly a 20% reduction, but still only 2.6% reduction of that massive 2.9MiB the imgur site transferred in total.
- Santosh83 7y agoYes not so useful for small images but when users view multi-megabyte images then I guess the savings will start to be significant even with the page overhead. Say a 4Mb image can be optimised to 2.5Mb then total download comes down from 6.9Mb to 5.4Mb which is not trivial, especially when the same page has multiple images (some people upload a gallery of images on sites like imgur) or when viewing lots of image URLs. Especially on a limited data plan these small savings will start adding up.
- rndgermandude 7y agoYes, it would be a win for the users, especially on limited data plans. Though I wouldn't hold my breath for most sites to actually implement it; most sites do not mind serving megabytes of data for a single page view to users, incl megabytes of scripts, even to mobile users. 4MiB to 2.5MiB is out of range for brunsli, more like 3.2MiB if you're lucky. I also tried with a 54 MiB JPEG[1] just now. The brunsli coding is 49MiB so not even a 10% reduction on this particular file. And it took a wallclock time of 16 seconds on my last gen Intel. Decoding it back to JPEG took 11 seconds on the same box. [1] A picture of a wedding cake, taken with a NIKON D810, one of the largest JPEGs I had available. I was "exported" by Lightroom 9 it seems from a NEF/RAW source, and is full of meta data too, around 100KiB of it.
- wiradikusuma 7y agoCould someone explain what a "repacker" is? What I know: In Photoshop, when I save an image as JPEG, I can decide the "quality" (Low, Medium, High, etc). The lower it is, the smaller the file size but the image will have (more) artifacts. The resulting image can then be opened in any image viewer including browsers. Also, I was told to save the "master" copy in a lossless format (e.g. TIFF or PNG) because JPEG is a lossy format (like MP3 to WAV). So how does a "repacker" come to play?
- detaro 7y ago> Brunsli allows for a 22% decrease in file size while allowing the original JPEG to be recovered byte-by-byte. It's a lossless file compression application that's specialized on compressing a specific file format, so it can beat generic compression tools like gzip.
- mkl 7y agoJPEG compression works in two phases: 1. Discrete Cosine Transform, discarding insignificant information. 2. Compression of bitstream. Step 1 is lossy in practice because it throws away things that seem insignificant. The "quality" control determines what counts as insignificant. Step 2 is lossless, and just tries to make the data coming out of Step 1 take up as little space as possible. A repacker redoes Step 2 better: it makes the file smaller without reducing the quality, by changing how the data is compressed, not changing which parts are kept.
- zxcvbn4038 7y agoI understand what your saying but when your storing millions of images and transferring them frequently those small reductions in size are very significant when you get your storage and/or transit bill at end of month. A lot of the fluff and filler you mentioned is compressed and cached, so your not bringing it down every request and not in raw form. Even if you are sending a huge amount of uncachable stuff with each request it doesn’t mean savings wouldn’t be appreciated. It’s funds for a team lunch if nothing else!
- wyoh 7y ago> Brunsli has been specified as the lossless JPEG transport layer in the Committee Draft of JPEG XL Image Coding System and is ready to power faster and more economical transfer and storage of photographs. I thought the lossless part of JPEG XL was done by FUIF, am I misunderstanding something?
- janwas 7y agoLossless transcoding of JPEG bitstreams is done by Brunsli, there is also lossless storage of pixels, based on tech from FUIF plus an adaptive predictor by Alex Rhatushnyak.
- JyrkiAlakuijala 7y agoPlus the 'select' predictor from WebP lossless :-)
- jonsneyers 7y agoPlus tons of cross-pollination from the PIK/VarDCT mode, e.g. the (MA)ANS and Brotli entropy coding and the Patches intra/inter block copy mechanism :)
- twotwotwo 7y agoThis could be what provides the 'activation energy' to get large Web sites working with JXL; it avoids the situation where you don't want to touch a new standard until everyone else switches too. If Google ships a decoder in Chromium, I would give JXL decent odds of getting a lasting niche. Also, 20% off JPEG1 sizes is better than it may sound; you only save about 30% more by switching to any of the new codecs (JXL's VarDCT or the video-codec-based ones) that apply a ton of new tools. Given JPEG1 was published 1992, that just confirms to me Tim Terriberry's quip that it was "alien technology from the future." Working against JPEG XL: it's four modern image formats in one (VarDCT, Brunsli, FUIF, and a separate lossless codec) so a ton of work to independently implement. Also, video codecs already have ecosystem support, and have or will probably get hardware support first. Further out: "JPEG restoration" is something I mostly see experimental work about but could also take the old format a bit further. The idea is to use priors about what real images should look like to make an educated guess at the information that was quantized away, so you get less of the characteristic blocking and ringing from overcompresed images. (For example, look at Knusperli, JXL's "edge-preserving filter", or AV1's CDEF. The "quantization constraint" supported by the first two of those is, to me, what makes it "restoration" and not just another loop filter: it can always return pixels that could have compressed to the exact DCT coefficients in the file.)
- JyrkiAlakuijala 7y agoThe separate lossless codec and FUIF and some additional ideas have been integrated into the modular mode. The modular mode and VarDCT can be mixed in the same image. JPEG XL decoder no longer performs 'quantization constraint', it is a classic loop filter, just with heuristics and control fields to maintain detail much better than loop filters in video codecs. If you start with sharp high quality originals that don't have yuv420 in them, you usually will see 65 % savings with JPEG XL, i.e. more than 30 % on top of brunsli. You can think of VarDCT-mode as guetzli(-35 %) + brunsli(-22 %) + format specific changes(-30 %) like variable sized dcts, better colorspace, adaptive quantization and loop filtering.
- twotwotwo 7y agoThanks, I appreciate the corrections and detail. I was mostly going by the committee draft on the arXiv (https://arxiv.org/abs/1908.03565 https://arxiv.org/abs/1908.03565 ), which still mentioned the quantization constraint (J.3) and a "mathematically lossless" mode (annex O) distinct from modular. "Four formats" was just imprecise wording on my part. The material already public about JPEG XL's design rationale, testing, and so on has been really fun to follow as an outsider. I selfishly hope there's more of it as the work on it and rollout continue. Even with the standard itself public, a lot can be mysterious to those not immersed in this stuff.