Jpeg xl is pretty good and I’m still pissed Google deleted it from Chromium before it could even try to get any market share.
Jpeg xl can do everything jpeg & png can do, but more efficiently.
i dispise webp
edit: fuck all other formats png best.
Google makes some really fuckin bullshit decisions. Jpeg XL being removed from chrome, same with DHCPv6 missing in android. I hate google
There’s not much to improve on PNG. It’s essentially a zipped up BMP with optional filters to rearrange pixels in a way that will hopefully lead to better compression at the zip stage.
Last time I tested this, if you used xz or zstd to compress a BMP with max settings, it made smaller files than PNG.
WebP and JXL is where it’s at.
Experts warn the obesity epidemic may require adoption of JpegXXL standard, at least for American selfies.
ny PNG elitist brain interprets this as PNG being so good than JpeG had to be upgraded and a new format (WebP)
WebP solves use cases for both PNG and JPEG as the same format can be lossless or lossy, while getting the benefits of a much more powerful codec.
PNG is good for certain types of graphics. Take a full size 48MP picture and encode it in PNG and it’s going to be massive compared to JPEG.
PNG is a pretty simple and effective format but it’s not especially good nowadays, there’s a reason WebP is popular. Much smaller files for the same quality. Same for JPEG XL.
Webp = google = convert to PNG
bro, we have enough image formats. thank you
what the bomboclat you talking abt?
jxl can also do lossless compression and transparency, so the important features of png are there
Quite Okay Imaging. One-page spec, comically fast, similar ratios.
I got thoroughly nerd-sniped by the same guy’s Quite Okay Audio format, because he did a much less mic-drop job of that one. The target bitrate is high, for a drop-in replacement on MP3 or Vorbis, and the complexity level is… weird. QOI is shockingly simple; QOA involves brute force and magic numbers. I thought I could do better.
I embraced the 64-bit “frame” concept, did some Javascript for encoding and decoding as a real-time audio filter, and got one-bit samples sounding pretty good… in some contexts. Basically I implemented delta coding. Each one-bit sample goes up or down by a value specified in that frame - with separate up and down values, defined in log scale, using very few bits. Searching for good up/down values invites obsession but works fine with guess-and-check because each dataset is tiny. I settled on simulated annealing.
Where I ditched this is shortly after doing double-delta coding. So instead of a 0 making sample N+1 be sample N plus the Down value, sample N+1 is always sample N plus the Change value, and a 0 makes Change equal Change plus the Down value. This turns out to be really good at encoding a wiggly line, one millisecond at a time. If it’s low-frequency. Low frequencies sound fantastic. Old-timey music? Gorgeous, slight hiss. Speech? Crystal clear. Techno? Complete honking garbage. Hilariously bad. Throw a high sine wave at delta coding and you get noise. Double delta coding, you get pleasant noise, but it’s still nonsense bearing little resemblance to the input. It’s not even a low-pass filter; the encoding method just chokes.
The clear fix would be re-implementing an initial test, where you specify high and low absolute values, and your one-bit samples just pick between them. It’s naive carried-error quantization and it sounds like a child’s toy that’s never getting new batteries. But I’d do it alongside the delta options. Selecting which approach produces the least error would be done per-millisecond. You’d get occasional artifacting instead of mangled output or constant buzzing. I just ran out of steam and couldn’t be arsed.
