7 ms·
If transparency was the main issue, adding transparency to JPEG sounds easier than coming up with a completely new encoding, especially a lossy one.
by moring 6y ago
If 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]