8 ms·
Pay attention to just how good WebP is at _lossless_ comparison though! I've always thought that one as flying under the radar. Most get stuck on WebP not offe
by jug 3y ago
Pay attention to just how good WebP is at _lossless_ comparison though!
I've always thought that one as flying under the radar. Most get stuck on WebP not offering tangible enough benefits (or even worse) over MozJPEG encoding, but WebP _lossless_ is absolutely fantastic for performance/speed! PNG or even OptiPNG is far worse. And very well supported online now, and leaving the horrible lossless AVIF in the dust too of course.
- jonsneyers 3y agoLossless WebP is very good indeed. The main problem is that it is not very future-proof since it only supports 8-bit. For SDR images that's fine, but for HDR this is a fundamental limitation that is about as bad as GIF's limitation to 256 colors.
- jug 3y agoAh, I didn't know this and I agree this is a fairly big issue and increasingly so over time. I think smartphones in particular hastened the demand for HDR quite a bit, what was once a premium/enthusiast feature you only had to explicitly buy into.
- fluidcruft 3y agoHDR is also important for medical imaging applications (which have been moving to web)
- omoikane 3y agoI haven't ran across websites that serves up HDR images, I am not sure I would notice the difference. WebP seems appropriately named and optimized for image delivery on the web. Maybe you are thinking of high bit depth for archival use? I can see some use cases there where 8-bit is not sufficient, though personally I store high bit depth images in whatever raw format was produced by my camera (which is usually some variant of TIFF).
- lonjil 3y ago8-bit can have banding even without "HDR". Definitely not enough. 10 bit HDR video is becoming more common, and popularity for images will follow. Adoption is hampered by the fact that Windows has bad HDR support, but it all works plenty well on macOS and mobile platforms.
- adgjlsfhk1 3y agounfortunately linux HDR is pretty much completely absent. That said, Wayland slowly looks like it's getting there.
- toastal 3y agoX11 supports 10-bit SDR… which Wayland doesn’t
- JyrkiAlakuijala 3y agoIt would be nice if everything was non tone-mapped HDR all the time for software, and the windowing system or the monitor would do the (local) tone mapping.
- kllrnohj 3y agoNo, you don't want that. You want your windowing system & UI/graphics layers working in display native range (see eg, Apple's EDR). The consistency of appearance of the SDR range is too important to leave it up to unknown tone mapping. Also it's too power expensive to have your display in HDR if you're only showing SDR UIs, which not only is the common reality but will continue to be so for the foreseeable future.
- JyrkiAlakuijala 3y agoI think both approaches have advantages. Requiring every game, photo viewing app, drawing program, ... every application to decide how to do it's HDR->SDR seems unnecessary complication due to poor abstractions. The locality of local tone mapping (the ideal approach to HDR->SDR mapping) would expose the window boundaries. Two photos or two halves of the same photo in different windows (as opposed to being in the same window) would create an artificial discontinuity for the correction fields being artificially contained within each window instead of spanning the users visual field as best as possible. Every local tone mapping needs to make an assumption of the surrounding colors: is the window surrounded by black, gray, colored or bright light should influence how the tone mapping is done at borders. This information is not available for an app: it can only be done at the windowing system level or in the monitor. The higher the quality of the HDR->SDR mapping in a system, the more opportunity there is to limit the maximum brightness, and thus also the opportunity for energy savings.
- chungy 3y agoLossless WebP is also stuck with a low axis limit of 16383. It is a good format when you can use it, but JPEG XL almost always compresses better anyway, and lacks color space and dimension limits.
- JyrkiAlakuijala 3y agoThis limit didn't exist in my first version as well as the 4 GB limit. These were artificially introduced to "match" the properties of lossy WebP. We could have done better there.
- mardifoufs 3y agoWere you involved in creating WebP? If so that's super cool! Why would they want to match webp's lossy compression though? To make it more uniform? And do you know why lossy WebP had such a limitation in the first place? Thank you!
- JyrkiAlakuijala 3y agoI designed the WebP lossless format, wrote the spec, and implemented the first encoder. The constraint was in WebP lossy to facilitate exact compatibility with VP8 specification and hoping that it would allow hardware decoding and encoding of WebP images using VP8 hardware. Hardware encoding and decoding were never used, but the limitation stuck. There was no serious plan to do hardware lossless, but the constraint was copied for "reducing confusion". I didn't and don't like it that much as more PNG images couldn't be represented as WebP lossless as a result of that.
- chungy 3y agoWow, that really sucks. I appreciate the explanation as well as your frustration with it. My desktop had a mixture of PNG and WebP files solely because of this limitation. I use the past tense because they've now all been converted to JPEG XL lossless.
- kllrnohj 3y agoFor things where you actually care about lossless you probably also don't care about HDR. HDR is (or can be) good for video & photography, but it's absolutely ass for UI. Besides, you can just throw a gainmap approach at it if you really care. Works great with jpeg, and gainmaps are being added to heif & avif as well, no reason jpegxl couldn't get the same treatment. The lack of "true 10-bit" is significantly less impactful at that point
- JyrkiAlakuijala 3y agoGainmaps don't solve 8-bit mach banding. If anything you get more banding: two bandings, one banding from each of the two 8-bit fields multiplied together. Gainmaps "solve" the problem of computing a local tone mapping by declaring that it needs to be done at server side or at image creation time rather than at viewing time. My prediction: Gainmaps are going to be too complex of a solution for us as a community and we are going to find something else that is easier. Perhaps we could end up standardizing a small set of local tone mapping algorithms applied at viewing time.
- kllrnohj 3y ago> Gainmaps "solve" the problem of computing a local tone mapping by declaring that it needs to be done at server side or at image creation time rather than at viewing time. Which was already the case. A huge amount of phone camera quality is from advanced processing, not sensor improveds. Trying to get that same level of investment in all downstream clients is both unrealistic and significantly harder. A big aspect of why DolbyVision looks better is just Dolby forces everyone to use their tone mapping, and client consistency is critical. Gainmaps also avoid the proprietary metadata disaster that plaugues HLG/PQ video content. > If anything you get more banding: two bandings, one banding from each of the two 8-bit fields multiplied together. The math works out such that you get the equivalent of something like 9 bits of depth but you're also not wasting bits on colors and luminance ranges you aren't using like you are with bt2020 hlg or PQ
- JyrkiAlakuijala 3y ago
- JyrkiAlakuijala 3y agoThank you! <3 WebP also has a near-lossless encoding mode based on lossless WebP specification that is mostly unadvertised, but should be preferred over real lossless in almost every use case. Often you can half the size without additional visible loss.
- netol 3y agoIs this mode picked automatically in "mixed" mode? Unfortunately, that option doesn't seem to be available in gif2webp (I mostly use WebP for GIF images - as animated AVIF support is poor on browsers and that has an impact in interoperability)
- JyrkiAlakuijala 3y agoI don't know
- edflsafoiewq 3y agoNot in gif2webp, no. It is available in img2webp as a global (not per-frame) option. It looks like when you pass it, it will be used for all lossless encoding, including when "-mixed" tries the lossless mode.
- kurtextrem 3y agodo you know why Jon didn't compare near-lossless in the "visually lossless" part?
- JyrkiAlakuijala 3y agoWebP near-lossless is very far in compression density against that kind of visually lossless. Still 2-3x more bits I think. No reason to compare. The near-lossless (at settings 60 and 80) is closer to pixel perfect no matter how much you zoom, whereas Jon's "visually lossless" is what I'd rather call usual very high quality lossy without pixel precision guarantees.
- a-french-anon 3y agoAn issue with lossless WebP is that it only supports (A)RGB and encodes grayscale via hacks that aren't as good as simply supporting monochrome. If you compress a whole manga, PNG (via oxipng, optipng is basically deprecated) is still the way to go. Another something not mentioned in here is that lossless JPEG2000 can be surprisingly good and fast on photographic content.
- edflsafoiewq 3y agoIIRC the way you encode grayscale in WebP is a SUBTRACT_GREEN transform that makes the red and blue channel 0 everywhere, and then use a 1-element prefix code for R and B, so the R and B for each pixel take zero bits. Same idea with A for opaque images. Do you know why that's not good enough?
- JyrkiAlakuijala 3y agoI made a mistake there with subtract green. If I had just added 128 to the residuals, all remaining prediction arithmetic would have worked better and it would have given 1 % more density. This is because most related arithmetic for predicting pixels is done in unsigned 8 bit arithmetic. Subtract green moves such predictions to often cross the 0 -> 255 boundary, and then averaging, deltas etc make little sense and add to the entropy.
- edflsafoiewq 3y agoCan you explain why?
- JyrkiAlakuijala 3y agoI edited the answer into the previous message for better flow.
- a-french-anon 3y agoThankfully the following comment explains more than I know, I was speaking purely from empiric experience.
- Akronymus 3y agoI really like webp. Sadly there's still a lot of applications that dont work with it (looking at discord)
- ocdtrekkie 3y agoIt is ironic you said this because when I disabled webp in my browser because it had a huge security vulnerability, Discord was the only site which broke and didn't immediately just serving me more reasonable image formats.
- deleted 3y ago[deleted]
- kodabbb 3y agoLooks like there are more savings coming on lossless AVIF: https://www.reddit.com/r/AV1/comments/1b3lh08/comment/kstmbru/?utm_source=reddit&utm_medium=web2x&context=3 https://www.reddit.com/r/AV1/comments/1b3lh08/comment/kstmbr...
- JyrkiAlakuijala 3y agoAlso more savings will come for JPEG XL soon. Possibly mostly focused on medium and low quality.
- kodabbb 3y agowill those require a bitstream change too?
- jonsneyers 3y agoIt is unlikely that there will be any bitstream changes in JPEG XL. There is still a lot of potential for encoder improvements within the current bitstream, both for lossy and for lossless.
- JyrkiAlakuijala 3y agoNo bitstream changes. In JPEG XL we have a 3-bit control field for each 8x8 square to guide which pixels participate in smoothing. The heuristics (here https://github.com/libjxl/libjxl/blob/main/lib/jxl/enc_ar_control_field.cc#L37 https://github.com/libjxl/libjxl/blob/main/lib/jxl/enc_ar_co...) for choosing that value are quite primitive and produces only two values: no smoothing and some smoothing (values 0 and 4). If we replace those heuristics with a search that tries out which of the values is closest to the original, we should get better quality, especially at the lowest bitrates where smoothing is important.
- deleted 3y ago[deleted]
- ummonk 3y agoI'm actually shocked by how poorly the lossless versions of new image formats (AVIF and HEIC) perform compared to the venerable png.
- KingOfCoders 3y agoBut all compression in the graph is lossless. The whole article is basically about JPEG XL lossless. Am I missing something?
- artemisart 3y agoAbout 3/4 of the article? There is a lot of analysis on lossy compression too after the lossless part.
- account42 3y agoLast time I tested cwebp it did not handle (PNG) color spaces correctly so the result of a supposedly lossless conversion actually looked different from the original. What good is better lossless compression if it is not actually lossless visually?