26 ms·
You can argue the toss over quality, but JPEG can't do transparency while WebP can. So if you need transparency, you need to compare the size savings to PNG, n
by JimDabell 6y ago
You can argue the toss over quality, but JPEG can't do transparency while WebP can. So if you need transparency, you need to compare the size savings to PNG, not JPEG. WebP is the clear winner there.
- moring 6y agoIf transparency was the main issue, adding transparency to JPEG sounds easier than coming up with a completely new encoding, especially a lossy one.
- agumonkey 6y agoclearly we need to dig in past work to find who tried that
- asjw 6y agoFlash could do it
- TylerE 6y agoHow? Do you know how many binaries link to some old version of libjpeg? You're breaking 99.9% of the world and 80% of it is stuff that can't even be recompiled, probably. In fact, JPEG 2000, which was standardized, in, well, 2000, already has transparency support, and 20 years later still have no meaningful support.
- moring 6y agoAll that is true for WebP too, isn't it? If you cannot recompile a piece of software, how are you going to add WebP support to it? And you aren't breaking it. In a theoretical world where transparency got added to JPEG, software that doesn't support it will show a fully opaque JPEG (adding transparency in a backwards compatible way isn't rocket science). Compare that to using WebP instead, where software that can't handle it won't even show the image.
- TylerE 6y agoYou don't have 15 year old binaries linking against an 18 year old version of libwebp.
- wizzwizz4 6y agoNo; you just have no compatibility whatsoever.
- shuntress 6y agoIt's not too unreasonable to assume that a given ancient program would have logic to differentiate between "This is a jpg and I know what to do with it" and "this is a something else and I don't know what to do with it" so it will technically handle webp images safely while it may not safely handle something that claims to be a jpg but apparently is not.
- pornel 6y ago> In a theoretical world where transparency got added to JPEG It's not theoretical. It's the JPEG XT spec. It adds alpha channel and HDR to standard JPEG in a backwards-compatible manner.
- danudey 6y agoYou offer two versions: * A webp version with transparency, which won't be supported by most clients but the ones which do will support everything * A JPEG version without transparency, or with "faked" transparency (i.e. baked-in background color), which will be supported by basically everyone but with less quality. That way, if the client is capable of loading the "good" version it will, and if it can't then it will load the "good enough" version.
- rndgermandude 6y agoBecause JPEG 2000 was essentially a patent-covered mess that nobody wanted to touch
- jandrese 6y agoShouldn't those patents be expiring soon? Edit: Did some more research and the patent risk appears to have passed as of 2016. Still nobody seems to have interest in JPEG2000.
- duaoebg 6y agoIt’s too compute intensive
- jandrese 6y agoThat's kind of scary for something developed in the 90s. It was originally run on Pentiums, K6s, PPC 604s, and the like and it's still too expensive for a Ryzen 7?
- duaoebg 6y agoImages got bigger... it’s not that it’s too expensive it’s just way more expensive that good enough alternatives. There are other reasons too but that’s a surprising one
- willglynn 6y agoYep. There's a ton of data dependencies, where e.g. you can't begin decoding the next bit until you've finished decoding the current bit. It's all about progressive decoding so there's multiple passes over each group of wavelet coefficients, accessed in a data-dependent sequence. Each wavelet transform involves accessing and interleaving the same 2D arrays in both row- and column-oriented fashions. These design decisions all made sense when clock rates were exponentiating, but they're all nightmares now that we rely on branch prediction and memory prefetching and superscalar execution units. The codec is simply not a good fit for the computing architectures we have today.
- leni536 6y agoOn the web you can do it with SVG. https://github.com/leni536/trans_jpg https://github.com/leni536/trans_jpg
- pseudosavant 6y agoThat is really cool. I had never thought about (ab)using SVG in that way. SVG is such an underappreciated technology that is in every browser. Why do icon fonts exist when you could just use SVGs just like you do PNGs and JPEGs? You can even inline them in your HTML so there isn't an additional HTTP request if you want.
- coopsmgoops 6y agoWouldn't it probably be one request per icon instead of just one request for a while font?
- pikelet 6y agoNot necessarily. You can have a single SVG file with multiple 'defs' that you can reference around the page, or just embed the SVG code in the HTML itself (via a templating language) if you're not using too many.
- cmroanirgo 6y agoGreat idea, I love 'thinking outside the box' solutions, but doesn't seem to work on Firefox mobile. (Perhaps it's just me.)
- alwillis 6y agoIn fact, JPEG 2000, which was standardized, in, well, 2000, already has transparency support, and 20 years later still have no meaningful support. Every iOS and macOS device supports JPEG 2000… that should be pretty meaningful.
- TylerE 6y agoChrome and Firefox don't.
- kbenson 6y agoThat accounts for significantly less than half the whole market, and half the mobile and desktop markets if you split it out. If it's also supported by other OS's and headsets and browsers that bring it significantly closer to 100%, then maybe we have something meaningful.
- alwillis 6y agoWell, 2 billion devices is a meaningful number of devices, no matter how you slice it.
- kbenson 6y agoThat's entirely dependent on context. In the context of "can I use this and expect it to work most the time" it's nowhere close enough. All that matters in that respect is percentage of the whole, and at less than half, it's not really much. As an example, we could talk about the number of connected IoT devices that are supported and up to date, and it's probably in the billions. But compared to the number of connected out of date and unsupported devices, it's likely inconsequential in comparison by metrics of total numbers, percentage of a whole, and importance (alternatively, total number of unsupported and possible exploitable devices does matter, because of what it implies about how they can be used destructively).
- dvhh 6y agoIs there still some licensing issues with jpeg 2000?
- jws 6y agoI did some proof-of-concepts ages ago (October 2010) exploring different ways of embedding a PNG alpha channel in JPEG application specific fields to have 100% JPEG compliant files which web browsers could display with transparency. It worked just fine. If you want transparent JPEGs on your web page that works. Back then the number of GETs was really important, so stuffing the mask into the JPEG made sense. Now with our HTTP/3 and QUIC world that isn't such a big deal.You might be better off just using a CSS mask image.
- mehrdadn 6y agoI think the idea is "if you're going to break compatibility, might as well make all the improvements at once".
- deleted 6y ago[deleted]
- surround 6y agoWebP also supports animation, which is important because GIFs are notoriously large.
- sprokolopolis 6y agoAlso, gif only supports one-bit transparency; Whereas webp and png allow partial/gradated transparency.
- arcticbull 6y agoAnimations should just be videos. No reason for an animated image format, an animated image is just a video with no audio track.
- auxym 6y agoMy understanding is that webp is video. That is, it's a still frame using the vp8 codec.
- catalogia 6y agoAs far as I can tell though, it has to be VP8 and can't be VP9. Maybe I'm mistaken about that, but all the webp literature I've read or skimmed talks about VP8 specifically. So what's the advantage of an animated webp using VP8 over a webm using VP9?
- TazeTSchnitzel 6y agoIt only has VP8's intraframe compression, not VP8's interframe compression, so animated WebP is not a proper video codec and is a different beast to WebM video.
- dtech 6y agoAn animated WebP is basically a WebM video. Or let me rephrase, why is WebP as a animated picture / video format insufficient?
- 6y ago
- romwell 6y ago>JPEG can't do transparency JPEG "can't" do depth maps either, and yet it manages to do them just fine. "Portrait mode" on Android is simply JPEG + greyscale JPEG embedded in metadata. If anyone really wanted transparency, it is very easy to add it to JPEG. That said, in practice, transparency is not needed in non-vector / non-generated graphics formats. The nature doesn't really have an alpha channel, photographs certainly do not. Transparency is extra information, and can be passed along as such.
- m45t3r 6y agoThe problem is always standards. I want transparency to work correctly everywhere, not just in one application and broken everywhere else. Even if transparency was add to JPEG right now, it would take sometime to become available everywhere, and you would have tons of legacy devices showing broken transparency. The advantage of a new format that supports transparency from is interception is that every device that is compatible with it will display it correctly. So there is no issue with some devices supporting the format partially.
- romwell 6y agoThe larger picture is that you can use PNG or SVG anywhere you need transparency, which are also better suited for the content that has transparency. JPEG is optimized for photos, which don't have transparent parts. SVG and PNG are optimized for graphics. So, if you need transparency, WEBP is probably not the format you'd choose anyway.
- m45t3r 6y ago> The larger picture is that you can use PNG or SVG anywhere you need transparency, which are also better suited for the content that has transparency. It is pretty common to have anime characters where you remove the background to use as reactions, and while you can use PNG in those cases it makes the images huge. WebP makes it ideal for those cases, this is even the case that I saw this being used in some image boards (specially also including animation, another thing that is popular). Just because you can't think in a use case there isn't mean that there isn't a use case.
- waheoo 6y agoDo you though? The transparent png use case is largely being replaced by svg. There are some situations where transparency is legitimately needed but im not sold it can justify webp and all that comes with it.
- httpsterio 6y agovector graphics and raster graphics aren't really comparable.
- waheoo 6y agoWhy not? They display an image. Bit if a weak argument to say they dont matter when theyre being used to create the same final outcome.
- httpsterio 6y agoHow would you show a photographed image as a svg? Either you would have to "vectorize" the image which would look totally different or you'd create a grid of vectors with different hue values, ultimately representing pixels in an extremely inefficient format. Raster graphics and vector graphics can't be compared because sure, you could create 2 million vector squares with individual positions, sizes and colors and align it into a 16:9 grid or you could just use a jpg. The latter being a fraction of the size and processing power needed to display it.
- waheoo 6y agoWhy would you show a photograph as an svg? You wouldnt. Thats what jpegs are for. We're discussing transparency and the use case for it. I dont think ive ever heard of someone wanting transparency in a photo. The only times i see the need is if theyre doing something that is better off in a vector format. I.e. png, which is being supplanted by svg, which alleviates the size problems raised about pngs. I.e. webp is a format solution in search of a problem. Downvoted, wow, petty.