@realcaseyrollins@realcaseyrollins 1) your ".webp" file could actually be a wrongly named png, 2) your webp is actually a webp file, and the software "supports" png so it won't complain, but the decoder inside is capable of decoding webp just fine, so when you feed it a ".png" and the data inside is a webp it just works, OR 3) a wild guess tbh but the data inside a png starts at the same offset as the first (or only) VP8 frame in a webp doesn't it? idk how vp8 works but i wouldn't be surprised if there's ways a generic image decoder could accidentally decode an vp8 frame stuck inside what it thinks a png is.
im very tired and never looked into webp tho, so idk. @mia would probably 🗞️ me for some error in my chain of thought here 🥺
@mia@realcaseyrollins@realcaseyrollins@lucy nup. generic decoders wouldn't decode vp8 or 9 in a png. png isn't a flexible container like matroska so there is only one pipeline if you find a png header.
@icedquinn@mia@lucy@realcaseyrollins This is all very helpful, it sounds like point 2 might be it since these are #webp files I get from like #GoogleImages or #YouTube. Some apps and sites that let you upload images (like #Soapbox, incidentally) don’t let you use upload #webp files because it filters them out, so I have to change the extension.
pretty much the whole industry wanted jxl because you can repack existing jpegs, with no loss of quality, and save maybe 5%, which amounts to a lot when you are facebook and are pushing millions of images. plus it handles lossless, so you can repack the pngs too, smaller, and open both with just one decoder. it's totally better.
Add comment