5 ms·
All 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.
by moring 6y ago
All 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.