As much as I want JXL to become the standard image sharing format, I welcome AVIF as the go-to bulk web image format. The fact that you can meet strict size requirements and still have the result look decent means it can be automated well.One use case would be 4chan thumbnails. Some of them on the catalog can be as big as 10KB, and there are 150 of them on /g/. The site could potentially save a megabyte of data for every single user deciding to view the catalog. That quickly adds up.As a bonus, it would filter retards who save thumbnails and try to post them. Total ant death.
put on the trip, pixdaiz
uncompressed webp images are great, but man is it slow as fuck.
>>101559207Case in point, this super simple thumbnail is 4.7KB and has visible artifacts AVIF wouldn't show.
>>101559207I personally really dislike the blocky artefacts of jpeg xl. I would much prefer AVIF nuke grain than get those DISGUSTING HIDEOUS blocky artecacts.
>>101559207>As much as I want JXL to become the standard image sharing format, I welcome AVIF as the go-to bulk web image format.I believe they can coexist together.
>>101560168they can. OP is just a faggot. along with JPG and PNG purists.
>>101560168>>101560248The whole point of a next-gen image format was to reduce clutter. If neither AVIF or jpeg-xl can do that then both are deemed emberrasing failures.
>>101560248I never disputed that, retard.
>>101559681What good is that if there is banding up the ass?AVIF on the left. JXL on the right. Contrast turned up here to demonstrate the effect. 10-bit and 90+ quality is used.
>>101560326I don't know what your meme test shows exactly. All I know is that jpeg xl images above distance 1.0 look like...COMPLETEAND TOTALFUCKINGDOOOOGSHIT
>>101560351>I don't know what your meme test shows exactly.You may want to visit an optometrist.Hint: Look around her right shoulderOn a good screen, this is visible without manipulation.
>>101560429Cool inspector gadget, now test again at 150 KB max file size.Protip: you won't and you're too chickenshit to admit how much jpeg xl bloats file size.
>>101560444
>>101560451>"NOOOO DON'T TEST FILE SIZES WHERE AVIF EXCELS AT, YOU HAVE TO BLOAT UP THE IMAGES SO THAT JPEG XL WON'T LOOK LIKE A GIANT TURD!">"BANDWIDTH? WHAT'S THAT?"
my only gripes with jxl are the frankly terrible load times for animations without hwaccel, and s2png's converted to jxl are larger, but that one's somewhat excusable because it's noisy data and not photographic/vector/artistic/whateverbtw anyone else convert gifs to webp and find that mpv can't play them? my image viewer does it fine, though sometimes it takes a second to load
>>101560480It's a good thing AVIF is getting hw accel so we can finally replace GIF. That motyerfucker has been a giant throbbing headache for everyone on the planet.
>>101560475>Noooo who cares about image integrity. Just compress that shit to smithereens and view it on your shitty LCD phone>32 inch LG OLED? What's that?
>>101560516why would avif need to be animated, it's already derived from a moving picture format
>>101559233that's more like an argument for svg
>>101559207Ah yes the hourly avif shill thread, how refreshing!
>>101560516AVIF can't replace GIF, only supersede it. JXL can consistently compress GIF's losslessly, meaning you can reverse them if there is a need for that.
>>101560287apologies.
>>10156069699℅ of GIFs are not lossless though.AVIFs derived from AV1 video however can be lossless.
>>101560979Are you going to post a 1080p high-quality AVIF to use as a reaction image on a Georgian cave painting forum?You'd most likely just take something preexisting and irreversably compress it into a tiny AVIF.The point is that GIF's already exist for their specific use case, and whether or not they come from an originally better source, they need not be degraded any further.
>>101561108I don't want a 360p render on my 1440p phone, that's extremely silly. 1080p will absolutely be the new "GIF" resolution once 4K displays are everywhere even in phones.
>>101561130Since when do you view GIF's in full screen? They are as big as they need to be on the page they are seen in.Heck, most WebM's posted on 4chan are far from 1080p, because they gain nothing from taking up the entire screen.>But 4K displaysDPI upscaling says hi.
>>101561200We can't keep catering to the retards using CRT displays forever.
>>101560692based
>>101561229Nice scapegoat.My CRT in the basement can do 2048x1536. Meanwhile, I still see the occasional 1366x768 laptop in use.
>>101559207while i'm a big fan of 4chan not changing much, i do think it's probably about time we get double size thumbnails, so they look good at higher dpisome people work around that by preloading all images, but that's obviously incredibly wasteful both on 4chan and the user
are blacks in reencodes still a shit in av1 or was that a skill issue for re-encoders? Downloaded some av1 re-encodes awhile ago and they were not worth downloading
>>101561289The real solution is to use better formats (lossy WebP/AVIF, for transparency support) and at a higher quality (the current JPEG quality is absolutely trash), then have multiple sizes for different DPIs in a <picture> srcset.Of course, that would require a few hours of 4chan developer time, so it'll never happen.
>>101561303>>>/pol/
>>101561315You really only need Q50 AVIF (default) to cover 90℅ of users, which would be phoneposters. Not really worth catering to 10℅ of users.
>>10156134010% of the users being unable to view thumbnails would be quite unacceptable for any website. A proper fallback (ideally JPG/PNG, but WebP might be acceptable these days) would be necessary.
>>101561353I dunno, catering to the 10℅ is why we've been stuck with libjpeg turbo for the past 100 years or so.
>>101561374You literally have an option to deliver new formats to supported browsers and old ones to those that can't view them."New for 90%, nothing for 10%" is not even an option. It's between "new for 90%, old for 10%" and "old for 100%".
>>101561340why did you use the care of symbol there instead of percent?
>>101561389Because I enjoy watching you suffer.
>>101561318you read the first two words and jumped to conclusions, did you?his post is not even hinting at racehe means blacks as in literal dark colours/scenes, which are in fact a a point of specific concern with video encoding
call me a shill or tell me to buy an ad but AVIF is better in every way (except maybe writing a de/encoder) than jpeg-xl
>>101561318..?>>101561409I KNEEL.
>>101561423They don't care, if you're not testing jpeg xl above 0.5 BPP then you're an anti-semite who won't donate half of his income to fund mass genocide in gaza.
>>101561423i can't think of anything avif does better than jxl except perhaps produce more pleasant looking extremely compressed images (even if they're less accurate to the original the jxl)avif generally performs worse overall at lossy, it performs much worse at lossless, it has limited pixel format support, severe image size limitation (even 4chan's image resolution limit is greater than avif's), jxl has far better generational loss resistance, you can losslessly recompress existing jpeg's, avif has no progressive decoding support, etc, etcavif is actually pretty shit, honestly, and especially for the purposes of the web
>>101561510see >>101559681
>>101561521See https://cloudinary-marketing-res.cloudinary.com/image/upload/v1682076683/CID22.pdf
>>101561521i said generally, not alwaysa few hand picked examples where avif does better doesn't make up for all the rest of the features it doesn't havei couldn't even post a photo from my phone camera without tiling with avif (which can leave edge seams), and you'd have to wait for the whole image to download before you see any of it, and if someone recompresses it, you lose more detail than with jxl. to name a few issueseven if avif was consistently a bit better at lossy compression, it's not enough. avif is a video format still and it really shows
>>101561560>even if avif was consistently a bit better at lossyHow the FUCK is >>101559681 """""""""a bit better""""""""""The jpeg xl image literally looks like a smoldering turd.
>>101560475polished turds is all avif is good atthat is, it can make better looking low quality images, at any level where you actually care to keep details, it can't keep upit's like the "he-aac" of pictures
>>101561665see >>101559681
>>101561303Yes, this is what happens when encoders are not psychovisually optimized.What makes JXL good is the encoder, not the codec itself, meaning that AVIF can get a lot better, but JXL probably can't. libaom is a joke based on Google's libvpx shitware.
>>101561879see post above you
>>101561879>What makes JXL good is the encoder, not the codec itself, meaning that AVIF can get a lot better, but JXL probably can't.Uhlibjxl is actually well known to only implement a subset of JXL features and that there's still quite a lot that can be improvedAlso there's a lot more money and dev time going into various AV1 encoders (note that the best current video encoders are proprietary ones, not libaom)
>>101561934You didn't even see the very post chain you quoted.
>>101561947Such as? I thought reference encoders were supposed to be feature-complete.
>>101561972Decoders are supposed to be able to decode the whole formats, but I don't think that anyone claims that encoders are complete. Hell, we are still getting new JPEG encoders with more features 30 years after the format got released.
>>101561987It's by definition feature-complete if it supports all the codec tools that the decoder can deal with.This is what libaom is. It can still improve a lot, but it's not in an unfinished state where some part of the spec is neglected.MozJPEG and the likes are as good as they are because of psychovisual optimiations. Even Google's new thing is based around encoding in XYB, which is a visually optimized color space.
>>101562037The libjxl doesn't use splines, plus potentially some other features (I'm not an expert on JXL's internal workings). All JPEG encoders but Jpegli round the DCTs into 8-BPC, so 10+ BPC of Jpegli is essentially a new, previously-unimplemented feature. XYB is actually just one of the options in Jpegli and isn't even on by default; the whole encoding and decoding process being in high-resolution floats instead of rounding to 8-bit integers several times is one of the main reasons why it's so good.
>>101562050Good point about splines, but are they even intended to be used in raster images? It seems more like a quasi-SVG replacement.
>>101562084I don't know exactly what they're used for, but I'd imagine that it's likely for edges or other such shapes. Maybe the spec talks more about it, but I haven't read it.
>>101562094They are used in their demo showcase. This is 740 bytes.They have a separate tool for these, so you can perhaps also consider that complete.https://jxl-art.surma.technology/
>>101562121This is a manually written image, directly using JXL instructions. This does not count as part of any actual raster image encoder and is not feature-complete in any real way.
>>101562133>This does not count as part of any actual raster imageThat's my point. They are seemingly not meant to be.
>>101562168No, that website isn't a spline drawing app, it's an interface that lets you manually compose instructions for the Modular encoding. Many, but not all, of these are used by libjxl as well.I think that there are other improvements waiting to be done, not just splines. IIRC, patches and lossy palette were among them?
>>101562191>that website isn't a spline drawing appDoesn't need to be. It's not the job of the JXL tools to facilitate raster drawing either. All it needs to do is accept pixel data or spline data and convert them appropriately.More damning is the description from the documentation.>Splines: centripetal Catmull-Rom splines can be encoded, with a color and a thickness that can vary along the arclength of the curve. Although the current encoder does not use this bitstream feature yet, we anticipate that it can be useful to complement DCT-encoded data, since thin lines are hard to represent faithfully using the DCT.So work needs to be done indeed.
>>101559681The AVIF looks like total complete shit.Why would anyone use that crap?
I only care about lossless compression. Lossy should be banned except for shit like thumbnails. Which format is best at lossless compression?
>>101563239JXL. WebP is competitive when you need simple 8-BPC stuff without extra features, but that's mainly due to a more mature encoder and even then JXL beats it most of the time.
>>101563239The OP image is 36KB in lossless JXL.
>>101563502And it's 5KB if you don't convert it from a svg to a raster format. It's even smaller if you gzip it.
>>101563239jxl a good margin
>Add AV1 WebM support>Post single-frame videos>You now have AVIF
>>101559207Who cares? AVIF works in every single browser and major software. JewXL works absolutely nowhere except of fagOS. It's obvious which format will be the future.
>>101564360>Anonymous 07/25/21>Who cares? WebP works in every single browser and major software. AVIF works absolutely nowhere except Jewgle Coomium. It's obvious which format will be the future.
>>101564360how does google's cock taste, anon? chrome's the only thing refusing to support jxl
>>101564470Bullshit, firefox knows about >>101559681
>>101562940delusional
>>101564470JewXL was made by Google
>>101565148No, they just leased their patents.https://github.com/libjxl/libjxl/blob/main/PATENTSThe actual developer is a B*lgian socialist.
>>101565428Just say kike, we're not reddit.
>>101565477That's doing him a favor.
>>101564360>AVIF works in every single browser and major softwareYet nobody uses it. Which tells you that it is shit.AVIF lost against webp, it was unable to dethrone webp for that single compress-as-hard-as-possible use case.
>>101566380https://ylilauta.org/
