4 ms·
This is really impressive even compared to WebP. And unlike WebP, it's backwards compatible. I have forever associated Webp with macroblocky, poor colors, and
by mips_r4300i 3y ago
This is really impressive even compared to WebP. And unlike WebP, it's backwards compatible.
I have forever associated Webp with macroblocky, poor colors, and a general ungraceful degradation that doesn't really happen the same way even with old JPEG.
I am gonna go look at the complexity of the JXL decoder vs WebP. Curious if it's even practical to decode on embedded. JPEG is easily decodable, and you can do it in small pieces at a time to work within memory constraints.
- bombcar 3y agoEveryone hates WebP because when you save it, nothing can open it. That's improved somewhat, but the formats that will have an easy time winning are the ones that people can use, even if that means a browser should "save JPGXL as JPEG" for awhile or something.
- ComputerGuru 3y agoEveryone hates webp for a different reason. I hate it because it can only do 4:2:0 chroma, except in lossless mode. Lossless WebP is better than PNG, but I will take the peace of mind of knowing PNG is always lossless over having a WebP and not knowing what was done to it.
- 149765 3y ago> peace of mind of knowing PNG is always lossless There is pngquant: > a command-line utility and a library for lossy compression of PNG images.
- bombcar 3y agoYou also have things like https://tinypng.com https://tinypng.com which do (basically) lossy PNG for you. Works pretty well.
- ComputerGuru 3y agoNeither of these are really what I'm referring to, as I view these as ~equivalent to converting a jpeg to png. What I mean is within a pipeline, once you have ingested a [png|webp|jpeg] and you need to now render it at various sizes or with various filters for $purposes. If you have a png, you know that you should always maintain losslessness. If you have a jpeg, you know you don't. You don't need to inspect the file or store additional metadata, the extension alone tells you what you need to know. But when you have a webp, the default assumption is that it's lossy but it can sometimes be otherwise.
- lonjil 3y agoActually, if you already have loss, you should try as hard as possible to avoid further loss.
- ComputerGuru 3y agoI don't disagree, in principle. But if I have a lossy 28MP jpeg, I'm not going to encode it as a lossless thumbnail (or other scaled-down version).
- lonjil 3y agoI think JXL has been seeing adoption by apps faster than Webp or AVIF.
- account42 3y agoUnfortunately its the other way around for web browsers :|
- mfkp 3y agoI've noticed in chrome-based browsers, you can right click on a webp file and "edit image". When you save it, it defaults to png download, which makes a simple conversion. Mobile browsers seem to default to downloading in png as well.
- CharlesW 3y ago> And unlike WebP, it's backwards compatible. No, JPEG XL files can't be viewed/decoded by software or devices that don't have a JPEG XL decoder.
- Zardoz84 3y agoJPEG XL can be converted to/from JPEG without any loss of quality. See another commenter where shows a example where doing JPEG -> JPEG XL -> JPEG generates a binary exact copy of the original JPEG. Yeah, this not means what usually we call backwards compatibility, but allows usage like storing the images as JPEG XL and, on the fly, send a JPEG to clients that can't use it, without any loss of information. WebP can't do that.
- F3nd0 3y agoBut that only works when the JXL has been losslessly converted from a JPEG in the first place, right? So this wouldn’t work for all JXL in practice. (Unless I’ve missed something and this is not the case.)
- JyrkiAlakuijala 3y agoYou could start with relatively good jpegli as a codec and then lossless recompress that with jpeg xl. Naturally some entity (server side, app, content encoding etc.) needs to unpack the jpeg xl jpeg into a usual jpeg before it can be consumed by a legacy system.