Some sites are starting to implement JXL image delivery in their backend, filling in for AVIF as a higher-quality alternative.
https://assets.nintendo.com/image/upload/ar_16:9,b_auto:border,c_lpad/b_white/f_jxl/q_auto/dpr_1.0/c_scale,w_1200/ncom/en_US/products/hardware/nintendo-switch-oled-model-white-set/115461-switch-oled-white-boxart-1200x675
 Thalidomide Vintage Ad Shirt $22.14 |
 Nothing Ever Happens Shirt $21.68 |
Thalidomide Vintage Ad Shirt $22.14 |
Doesn't work, not gonna download your virus
>.bin
Nice try tho
EMBARRASSING
Can't you jpeg xl shills at least pull up one of the many BLM and apple sponsored websites to shill your shitty format that lacks hardware acceleration? I'm sure they support it.
Oh no no no
>ssimulacra2
Yeah I'm sure this benchmark made by the jpeg xl creator isn't biased or anything.
Communists NEVER lie, right?
Copium.
https://afontenot.github.io/image-formats-comparison/#end-of-show&avif=l&jxl=l
>Nooo it's all just israeli LIES!!!
Nice fake statistics but the real images say something else
>encode speed
Who the frick cares?
When you have to encode many millions of images, it matters.
Who is that, exactly?
Web servers
>millions
Let's be real here: it only matters for slow backends which are generating or converting images on the fly
All these stats are fake because they are tested on high-end hardware in isolation. Except in real world scenario most people will decode and encode not one but many images at the same time with million different programs running in the background. So the only reliable way to test them is by using only 2 cores max. If you do it you will realize how painfully slow jxl really is.
the father of cope
It's true tho. All benchmarks are shit and fake. Real life scenarios count.
works on my thorium
Yeah I'm totally gonna download some jay eks el file and then I'm gonna download safari so I can open the file. Most sane way to view an image in 2024 according to jxlshills.
That's worse than a strawman, you just put a hat on a hay bale. Find an image viewer that can open it if yours doesn't already work.
Why would I change my prefered software just to view a meme format that nobody uses?
You might not even need to, if you can just install the libjxl library.
Also, your appeal to popularity tells me not to listen to anything further you have to say.
I will not install anything for a format that nobody uses. If it doesn't display in my browser I will just close the tab and that's it. Has nothing to do with popularity.
based.
What a wild timeline we are on where Apple and Nintendo are the ones pushing good technology while freetards are taking it up the ass from Google.
Jxlbros I don't feel so good...
>Manga
Got you, senpai.
Yeah, WebP is the only real competition JXL has for lossless and even that's catching up. I'm still using WebP for screenshots on my machine, but at this point, that's just because Spectacle does not have JXL effort as a configurable parameter.
why are neither lossless?
Wtf is Nintendo doing that is so ground breaking?
>80 kB AVIF VS 110 kB JXL
JPEGsisters... I don't feel so good.
>JPEG XL Won
I'm all for JXL's success, but when will Firefox (stable) and Chromium support it? Right now Safari is the only major browser right now that supports it by default.
and don't forget about android... or even windows
>inb4 just install an image viewer
that doesn't work for the normies + you need a separate program to get thumbnails (which is only possible on winblows and not on android)
also generally on android an image format being natively supported means it will just werk across apps (maybe with jpeg transcoding), lack of native system support means developers aren't going to bother supporting it ever because they'd need to implement their own decoders and shit
if you combine chromium, windows and android's market share, basically 95+% of stuff out there doesn't have support for jxl
I'm a huge fan of it but it looks like it's already over to me, unfortunately nowdays google decides what lives or dies
>or even windows
Windows support is coming. MS devs are cooking.
Source: Windows insider builds registry and strings in dll
how long till the tripgay shows up
He's already here, here's his first post ITT
nintendo uses opus and zstd in some of their games lol
it was quite surprising when i got to know it considering the japanese don't often care of things like these, it's maybe because of their french r&d division
>nintendo uses opus
proof?
they do have vorbis and webm listed in the license page of all of their games but never saw opus mentioned there
look up for "vgmstream opus"
>the files are actually encoded as 196kbps CBR opus
Nice! they are using Opus in shitty cbr mode at bitrates that are overkill even for Vorbis! way to go nintendo!
well they can use all the space they want as long as it fits within the cartridge or the arbitrary limit they set
but why use opus at that point
also, no, that doesn't make sense
a smaller game means less size to download/store for those that buy the game on the eshop, and looking at xci/nsp files, there aren't differences in data between digital and physical releases
so filling a 32 gb cartridge with junk data or poorly optimized assets would make the game bigger for the eshop version as well
>this thread
Something about the way nobody assumes nor acts in good faith makes me sad. I prefer jxl, but either way we'll have better image format(s) once it's settled, and you can always store what you want on your machine. Why does one format have to be better at everything, anyway? Gif, jpeg, and png were all used for different strengths.
>Something about the way nobody assumes nor acts in good faith makes me sad.
Yeah that's totally not because a single guy is spamming jxl shill threads for months despite it only working in one fricking irrelevant browser.
>Single guy spamming image format threads
So pixDAIZ
Why do you like this troony so much that he lives rent free in your head so much?
I'm not the one bringing up a supposed scapegoat spammer, moron.
>Nintendo using a new codec that's extremely performant and effective
Not as surprising as you might expect. They've always used low-end hardware so that they can sell accessibly cheap consoles, so they need performance even more than most game devs, and they need effective compression to match; Tears of the Kingdom is one of the "biggest" games ever made, but only 18 GB. Most developers would have used at least ten times that.
JXL is actually an alarmingly good fit for video games anyway. The way it does progressive loading gives you LOD's for free. You just need a progressive decoder, but since browsers refuse to implement the format at all, they'd need to make one for themselves.
I wouldn't be surprised at all if they've already done that, and they're just putting it in their website's backend simply because they can.
>JXL is actually an alarmingly good fit for video games anyway. The way it does progressive loading gives you LOD's for free. You just need a progressive decoder
The frick are you talking about? Games use vector based graphics and avif buttfricks jxl in that area. Also games don't use progressive decoding. You keep bringing up topics that you have no idea about. Jxl is ONLY good for lossless photography archiving and even there it's not that much better than avif, not to mention that you need to reencode everything anyway if you want to use it on the internet because jxl has no support on any relevant platform.
>Games use vector based graphics
no its not you stupid moronic homosexual lmao
JXL and AVIF are both poor fit for most video games because there exist image formats that can decode on GPUs. Otherwise, that aside, JXL its fastest modes (i.e. fast lossless) might be usable. General-purpose image formats usually don't really aim to cover such specialized use cases.
>video games because there exist image formats that can decode on GPUs
what are the best image formats for video games?
I'm not an expert on GPU-decodable formats and many are proprietary and come as a part of whatever game framework. Basis Universal is a FOSS example: https://github.com/BinomialLLC/basis_universal
Decoding on GPU for games doesn't seem like a good idea. When you're struggling for decent FPS, especially on Nintendo hardware, it's the GPU that's the bottleneck. You don't want to be giving it any more work when fast decoding on the CPU is an option.
That's definitely not the case.
?t=338
Either way, hardware acceleration does not use the same silicon as 3D rendering. There's no reason why you can't mix them.
You can't use it for texture compression, though. That claim is idiotic.
Ehhh, hardware acceleration for video games is a bit complicated. Especially if, as mentioned before, we're talking about Nintendo hardware. The GPU in a new Nintendo system is typically already 5 years old, and hardware acceleration tends to be on formats that are already 5 years old.
So, what's even the use case? Maybe their next console can hardware decode HEVC for faster cutscene load times?
>Maybe their next console can hardware decode HEVC for faster cutscene load times?
the current switch can hardware decode mpeg2/h264/h265/vp8/vp9 already
source: I use https://github.com/proconsule/nxmp on a daily basis to watch stuff on it
it's not surprising at all since it's the same SoC that the shield tv uses, why would you think it doesn't decode h265?
That's a good example. Letting the hardware do all the presentation work so the CPU won't cause hitching. I'm pretty sure this is already the norm.
Copying big textures through the CPU to the GPU is quite a bit slower than a format optimized to decode into GPU texture pixel formats directly on the GPU with good performance. Note that these formats tend to have significantly worse compression and/or quality ratios than normal general-purpose image formats, but they're good at the job they're designed for.
These textures do not use the video decoders on the GPU. They decode with compute shaders or whatever and minimize the amount of memory transfers required. Using the video decode pipeline for this would be a disaster in terms of performance.
How so? The API's on PC can output fixed-function decoders directly to video memory and forego any CPU interaction aside from sending the compressed stream.
https://learn.microsoft.com/en-us/previous-versions/windows/desktop/bb324209(v=vs.85)
Textures have to get moved from storage, to RAM, to the GPU anyway. If compression isn't very good because it needs to be decodable on the GPU, you're not saving much time by moving it to the GPU while still encoded. Especially compared to the extra transfer time moving a larger file from storage to RAM.
The whole point is to move a compressed texture to the GPU and decode it there instead of decoding it on the CPU and then moving the uncompressed one. Just because it doesn't meet the ratios of normal image formats doesn't mean it's useless.
Not an expert on this so I can't give you an exact answer. Is initializing and using the video decoder fast enough to not cause any performance issues there? Is it concurrent enough to be used for all the textures that need to be decoded? Can it output the pixel format that the 3D renderer part of the GPU requires?
Either way, GPU-decodable textures are a thing while I don't know of anyone using video decoders for textures like that.
virus
mods please delete
Works on my PC
It's been awfully quiet here after that mass reply post was deleted. Could it really be what I am thinking?
https://desuarchive.org/g/thread/99167108/#99167108
Reminder that every AVIF shill post comes from literally one shitposter who is probably not getting paid by Google.
It's either Daiz or some other dork pretending to be Daiz because he or Google thinks IQfy likes Daiz and will listen to anything he says.
The shitposter took his trip code off after someone looked into an archive which he genuinely didn't expect anyone to do.
Now he pretends to be multiple people.
My theory is that Google is hoping that IQfy will adopt AVIF and the format takes off from there like how IQfy made WebM popular.
we already know that, now shut up redditspacer
>we
>reddit invented paragraphs
Hello mentally ill phoneposting newbie
rent free
Why the frick would Google care about a Kazakh carpet weaving forum? All it takes is the will of a single schizo to shit up a board.
>Why does Google care about one of the most popular image sharing websites that made WebM popular
moron
>The same site that only added Google's actual homemade video codec 10 years after it was made available
Imbecile.
>Formats are made in one day and gain widespread support on the same day
moron
>Format got popular before IQfy even accepted it
Imbecile.
Proof?
VP9 hardware many years ago
https://bloggeek.me/vp9-hardware-acceleration/
VP9 usage number from Google's service
https://techcrunch.com/2015/04/06/google-says-youtube-users-watched-25-billion-hours-of-vp9-video-in-the-last-year/?guccounter=1
IQfy adding VP9 less than two years ago
https://desuarchive.org/g/thread/87627488/#87627488
Yeah because someone watching a video on YouTube knows the format, you fricking moron
Why did you turn your trip off, Daiz?
>Nobody ever downloaded a video off Youtube
>There's not this controversial program that made Google so mad they had to DMCA it
Holy fricking tard.
>Why did you turn your trip off, Daiz?
Yeah, you're officially fricking braindead. I'm not even referecinng AV1, let alone the image format war, yet you somehow had to bring in that tripgay into the discussion.
Ironically, your dismissal attitude is exactly how DAIZ behaves.
>Nobody ever downloaded a video off Youtube
that's not what he said though...
yes, 99.9% of normies have never heard of "webm" or "vp9", and have no idea what format the video they're watching is encoded in, there's nothing wrong there, nta.
also... no, you don't need yt-dlp to figure out if you are watching vp9 or not
literally right click > stats for nerds
holy fricking tard.
>literally right click > stats for nerds
No shit, homosexual. That's completely moot.
Popularity and relevance is gained from saving, deriving, and sharing. That VP9 WebM originating from Youtube shared on some meme-ridden social site means infinitely more than three letters on an overlay.
And those sites have historically not been IQfy since that ruled out VP9.
Youtube implicitly has millions of AVIF's already. Can you say the same about gay ex el?
>Save image from google
>it's a fricking .jxl or avif
>can't send it on discord
>can't send it on IQfy
>need to take a screenshot of it and send that instead
>but hey at least I saved the backend 0.0001 seconds of transferring the fricking useless file to me
>NOOOOOOOO YOU MUST WASTE BANDWIDTH BECAUSE I'VE ADHD
What did the AVIF shill mean by this
read again
>Save image from google
>it's a .jxl or .avif
>can send it on telegram just fine, it gets automatically transcoded in jpeg
pisscord could never compete
> it's a .jxl or .avif
> can send it on telegram just fine, it gets automatically transcoded in jpeg
Transcoding to JPEG is not good enough.
Vote for https://bugs.telegram.org/c/3520 and also for https://bugs.telegram.org/c/15667 (for the native support of AVIF and JXL in Telegram).
Notice that both suggestions are posted by the same user.
> Wait, IQfy supports that bullshit?
Safari also supports WebM now.
I'll attach a screenshot of its release notes.
Please have a look.
>Transcoding to JPEG is not good enough.
feel free to send it as a file then
>https://bugs.telegram.org/c/15667 (for the native support of AVIF and JXL in Telegram).
it's already supported, wtf is this moron asking?
sending avif or jxl as a file literally lets you view it directly in the app already
> sending avif or jxl as a file literally lets you view it directly in the app already
Not directly enough.
No chat-wide previews, no Telegraph uploads, registration required to view the file, etc.
>Not directly enough.
???
literally click on the thumbnail and it opens, the same goes for every other image format, why should avif/jxl be treated differently?
>No chat-wide previews
correct, because that's how telegram's infrastructure works, they want to make sure your picture is encoded just like every other, there's no reason to change this for jxl/avif, yes, they are on average more efficient, but I could be uploading a 100 mpx 12 mb jxl image, which wouldn't be ideal.
>no telegraph uploads
honestly, who gives a frick?
>registration required to view the file
???
yes, you need an account to view stuff on telegram
yes, I also don't like that
...but that has absolutely nothing to do with jxl/avif support
Avif is shit, youre talking to the avif shikl and you're a newbie who made yourself mentally ill
that has nothing to do with my post, and you don't even know basic english
I think you're the mentally ill one
>can't write a normal post nor read
>says others are mentally ill and don't know basic English
How many times did your parents drop you
Hilarious that you think formatting your post like mentally ill newbies do won't make anyone realize it's you, Daiz
You fricking moron, you claim that YouTube serving their shit in WebM is what made the format popular
That is why you keep bringing up streaming
Why can't you stick to your original point?
But let's respond to your gish galloping
Now you're claiming that WebM became popular because of someone downloading YouTube videos
Yet programs didn't add support for WebM until IQfy allowed WebM
Whoops, there goes your second disingenuous argument out of the window
I really wish someone could take care of you so we don't have to be bothered with your shit
> programs didn't add support for WebM until IQfy allowed WebM
You'll lie about anything, you rat
he's delusional, he thinks IQfy made webm popular, he thinks that he doesn't go outside this website where everyone uses mp4
he thinks that because he*
>Why can't you stick to your original point?
maybe because i'm not the guy you were replying to?
learn basic english
Anon misquoted your post. That's obvous to us but not to you because you're mentally ill.
> yes, you need an account to view stuff on telegram
No, you can open (for example) https://t.me/twitt_ota/18149 in a web browser.
(Have a look at the attached screenshot.)
You wouldn't be able to view the same picture if it were AVIF (or JXL) sent “as a file” without JPEG recompression.
And now is when you tell me “honestly, who gives a frick?” once again, right?
>You wouldn't be able to view the same picture if it were AVIF (or JXL) sent “as a file” without JPEG recompression.
that also applies to every other format... it's not an avif/jxl thing
>And now is when you tell me “honestly, who gives a frick?” once again, right?
no... this is when i tell you that these are completely different issues once again
you are saying telegram doesn't fully support jxl/avif because of something that applies to literally every other format as well
>.jxl is just a transcoded JPEG
>Can be converted on the fly with no repercussions
>Continue as normal
Woah.
is there a winblows program that can add a "transcode to jxl/jpg losslessly" button to the right click menu?
how do you "convert on the fly"?
I don't know about any plugin, but the encoder library already does this completely automatically. All it needs is some browser frontend.
been converting a lot of big filesize images (jpg lossless and png at dist 0.5) into jxl lately, very good results. asiaticmoot needs to let me post jxl soon. only problem ive had is that ther's no decent android jxl compatible gallery yet but thats a minor concern.
i have a script that does this using libjxl with a custom context menu entry. very handy
Have fun converting everything back in order to use it anywhere
>saving the backend 0.0001 seconds of transferring the file
In the scope of the site
>can't send it on discord
>can't send it on IQfy
Not in the scope of the site
Google creates WebM
No one knows what it is
Until IQfy supports it
IQfy added support for it when Moot was tripgayging
Moot became a Google employee when he stopped tripgayging and sold IQfy
I'm sure this is purely coincidental
Wait, IQfy supports that bullshit?
you've never seen a fricking webm on IQfy???
you must be an extremelynewbie
I thought he said webp. That would have been topical in a JXL thread.
The shill "pixDaiz" claims anyone who watches YouTube looks up all of the technical details of the video
Jxlbros I don't feel so good..
Funny that Daiz stopped posting in this thread because he's too busy samegayging in his newer thread
frick, there's another one already that I'm missing?
Yes he advertised it here
>daiz calling others delusional and schizos
>daiz arguing that no one uses webm because mp4 exists
Try making an argument that isn't disingenuous or a self-projection, daiz
Imagine something like a booru (gelbooru, danbooru) converting all their absurdres png files to lossless jxl, imagine how much space they can save.
Imagine also pixiv.
>imagine how much space they can save
It's significant. Over 20% at effort values that are just as fast as downloading them. Somewhere in the 30-40% range if you go balls to the wall with high effort.
t. currently hoarding images I've converted to JXL for a ML project
Jxl is utterly garbage for anime images compared to avif. Like it's not even close how much worse it is and it has already been proven with many examples. Why are you schizos still pretending jxl is good for this use case? If you aren't aware some boorus have already started to accept avif.
>same phoneposting moron in every thread
What's wrong? Out of arguments so we switch to name-calling now? Yes very mature, that will surely make people like your meme format more.
>out of arguments
avif shill has exactly two weak arguments that have been debunked over and over for more than a year now: muh anime and muh hw accel
then when presented with any actual arguments they ignore them or resort to (gasp) name-calling (how scandalous!)
>no I'm actually a different person that just uses exactly the same shit points as the tripgay that you only see on IQfy
never seen something shilled with such incredibly bad-faith arguments on IQfy before so consistently. you can only have the same stupid conversation with the same stupid results so many times before people just stop giving (You) (You)s, like I'm about to do.
OK then tell me how do I take high quality jxl screencaps from a video. It doesn't even need to be AV1 or anime. Also tell me how I save anime images losslessly so they are have smaller file size than the lossless avif equivalent. For some reason you keep ignoring these questions. I'm waiting for your answers.
Yes, Daizy, we all know you think AVIF is better for anime screenshots if the most desirable thing is small file sizes, and not preservation of details. You're probably right, but that's not anyone's use case but yours.
We're talking about boorus here, which disagree with you. If Danbooru has two versions of an image available, and one is lossless, then even if the lossy one is completely indistinguishable, the lossless original is designated the parent in order to identify it as superior. Want an example?
https://danbooru.donmai.us/posts/6069012
The AVIF is <1% the size of the PNG, yes. But the site considers it inferior to the PNG because it's lossy. The users evidently agree, based on the score and favcount.
We're also talking about ML. I'm teaching my model about images created by humans, not about compression algorithms. Making any changes to the source image during transcoding is unacceptable, because even changes which are imperceptible to humans are very much perceptible to a machine, and will end up magnified if used on every single image. So, any transcoded image must be 100% identical, down to the last pixel, when decoded. AVIF is absolutely worthless for this purpose, whereas JXL could not possibly fit more perfectly.
>AVIF is absolutely worthless for this purpose
NTA, but (playing devil's advocate for the sake of fairness) AVIF also has a lossless mode (though in my experience inferior compared to JXL).
Your justified laments are directed at lossy encoding per se, not AVIF specifically.
Yes, but this guy notoriously refuses to accept that anyone actually wants lossless encoding. So I'm giving him the exact reason why I need it.
But besides that, AVIF in lossless mode just isn't very good. JXL, WEBP, and often even PNG give better lossless compression. AVIF would only be worth considering if AVIF and PNG were the only options, but given since almost everything lossless is already PNG, it wouldn't be worth the effort to transcode to AVIF.
Just did some testing with "lossless" booru images and the lossless jxl is minimal smaller but takes 10x as long to encode compared to avif. It doesn't make up for the storage savings at all. Most images on booru are already lossy anyway but you probably already knew that.
version and settings?
https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/edit?hl=en#gid=174429822
this includes a large corpus of lossless manga
avif is, predictably, trash while jxl dominates
The VAST majority of images on the internet are lossy. Go on and use your meme format to archive lossless images and save 20kb per image. Have fun reencoding everything again to avif to use it on the internet.
you didn't read or at least comprehend the reply chain above that
read it again and realize why I posted lossless benchmarks
Even in lossy, JXL takes the lead.
It's just optimized for still images, whereas AV1 is made for videos, the two inherently branch out differently when optimizing the format for either purpose, there is no one-size-fits-both use-cases.
>Even in lossy, JXL takes the lead.
OK
View at 100%, not 400%, and again, technically, right has more detail, left less, because it's optimized for a sequence that will in all likeliness geometrically change, so it crushes out color detail and biases towards edges.
Essentially, the pic proves it's working correctly, you misunderstand how the comparison is to be viewed.
You could maybe alleviate this in JXL by passing it a profile that would optimize it for rather vector-y than raster-y type of input.
I chose a spectrum pic with reason, namely it has a (approaching) infinitesimal color range on at least one color channel and intricate and delicate geometric details and fonts.
Anime and Manga are, from an image-detail-standpoint, (most of the time) pretty simplistic.
Left is literally original bluray quality. Right has fricked up and washed out colors, is blurry, and has tons of artefacts. I know you jxlgays are just pretend to not see it but this amount of cope is unreal.
>Left is literally original bluray quality
It's AVIF and it's not lossless (obviously), and, as far as I know, original BluRay quality is EXCLUSIVELY H264 for 1080p and H265 for 4K, I am not aware of any BluRay that would be in AV1, where a lossless extract (i.e. transcode-less) of an AV1 keyframe to AVIF would be possible.
So, no, it literally CANNOT be the original.
Original quality, not original encoding. Learn how to read.
You have a very loose definition of original quality then...
>the jxlshills clawing on every straw
it doesn't matter if it's original or reencoded, are you just gonna keep pretending that you don't see the artefacts and fricked up colors on the right one? This is INEXCUSABLE for an image format.
In IQfy's thumbnail pic at least, the right one looks better, and there is no pic comparing both at 100% scaling, only zoomed-in, so there is at least reasonable doubt to be held to take this comparison at face value.
homosexual.
All the original files were provided here but you already knew that didn't you
i only see avif and jxl encodes there
surely you wouldn't encode jxl's from the avif you're comparing it to, would you?
He does, that's apparently the main way how you "win" with avif: Complain that jxl is slightly worse dealing with the compression artifacts avif naturally generateds (the "random" information choices it decides on with *heavy* compression).
Because it doesn't win lossless or when both compress to a not at all ugly image from a pristine drawn artwork source.
Give me me the jxl video version of it and I'll extract the jxl and convert it to lossless avif. Oh you can't? Because it doesn't exist? Oh well then I'm just gonna continue using my superior AV1 videos and avif screencaps. Not avif's fault that jxl is a moronic meme format that doesn't support videos.
You took something with compression artifacts and losslessly reencoded that and then are complaining the output is bigger than the input?
I'm sure that's been told to you in that thread, I think I may have seen it, read your OP and just shook my head and moved along.
He's a phoneposting moron who thinks the only usecase for images is screengrabs of his favorite korean cartoons for children and has been samegayging up the other thread extremely hard.
>Left is literally original bluray quality
post an example with the actual original as well, it's hard to compare how differently a lossy encode degrades the image without the original to compare to
Good, it's the best web usable image format.
In most cases it does. Avif isn't so bad that it is in ALL cases.
Cartoons are for children
Daiz claims boorus prefer AVIF, an awful format that rapes the image quality so hard the pixels can be counted on one hand
I wonder what desktop environments will support the new format wallpapers.
There's qt6-*-image-plugin in the AUR for KDE, I'm not familiar with gnome though.
arch qt supports jxl if you have kimageformats+libjxl installed, which should be default for most kde setups
but doesn't matter if google says no
>still can't realistically make an independent foss implementation because they let ISO gatekeep the spec
meh
there are several independent jxl decoders, e.g.:
https://github.com/lifthrasiir/j40
https://github.com/libjxl/jxl-rs
https://github.com/Traneptora/jxlatte
anon@anon:~/temp$ yt-dlp -x -o test -f 251 https://www.youtube.com/watch?v=aqz-KE-bpKQ
[youtube] Extracting URL: https://www.youtube.com/watch?v=aqz-KE-bpKQ
[...]
[ExtractAudio] Destination: test.opus
Deleting original file test (pass -k to keep)
anon@anon:~/temp$ ffmpeg -v error -i test.opus -filter_complex showspectrumpic test.png
anon@anon:~/temp$ time ffmpeg -v error -i test.png -c:v libjxl -distance 0 test.jxl
real 0m17,841s
user 0m24,563s
sys 0m4,018s
anon@anon:~/temp$ time ffmpeg -v error -i test.png -c:v libaom-av1 -still-picture 1 -crf 0 test.avif
real 0m42,682s
user 7m5,014s
sys 0m0,120s
anon@anon:~/temp$ ls -l test*
-rw-r--r-- 1 anon anon 10296586 Mar 26 15:34 test.avif
-rw-r--r-- 1 anon anon 8365089 Mar 26 15:33 test.jxl
-rw-r--r-- 1 anon anon 10056997 Oct 30 23:19 test.opus
-rw-r--r-- 1 anon anon 10444770 Mar 26 15:33 test.png
anon@anon:~/temp$ neofetch
`.-::---.. anon@anon
.:++++ooooosssoo:. ----------------
.+o++::. `.:oos+. OS: LMDE 6 (faye) x86_64
:oo:.` -+oo: Kernel: 6.1.0-18-amd64
`+o/` .::::::-. .++-` Uptime: 2 days, 13 mins
`/s/ .yyyyyyyyyyo: +o-` Packages: 2779 (dpkg), 15 (flatpak)
`so .ss ohyo` :s-: Shell: bash 5.2.15
`s/ .ss h m myy/ /s`` Resolution: 1920x1080
`s: `oo s m Myy+-o:` DE: Cinnamon 6.0.4
`oo :+sdoohyoydyso/. WM: Mutter (Muffin)
:o. .:////////++: WM Theme: Mint-Y-Dark (Mint-Y)
`/++ -:::::- Theme: Mint-Y-Dark [GTK2/3]
`++- Icons: Mint-Y [GTK2/3]
`/+- Terminal: gnome-terminal
.+/. CPU: AMD Ryzen 7 2700X (16) @ 3.700GHz
.:+-. GPU: AMD ATI Radeon RX 470/480/570/570X/580/580X/590
`--.`` Memory: 2214MiB / 15917MiB
Quartered dimensions of original for upload.
don't mind me just pirating this png
anon@anon:~/temp$ for i in test.png test.jxl test.avif; do ffmpeg -v error -i $i -f hash -; done
SHA256=105ab24355e5770eac0235b3eb7ada5b91126ddc38c3a0dc45a26b6e8d2bb4a5
SHA256=105ab24355e5770eac0235b3eb7ada5b91126ddc38c3a0dc45a26b6e8d2bb4a5
SHA256=dfb220caffd15252b3e485d72b595450684f89c62eb07788916fd23d50c9e591
I must've fricked something up with AVIF though. FFmpeg is v5.1.4, so, according to the manual, I should be using crf=0 as the lossless param, not the aomparams-thing.
You can't pirate freedom.
So let's see, JXL is
>faster
>smaller
>more idiot-proof in producing correct results
For me, that's a case closed.
It's significantly slower. Not sure what you mean by idiot-proof, avif takes one simple command to extract.
I tried converting a PNG to an AVIF file, which you would've known if you would've checked the commands I used.
This isn't keyframe extraction, this is encoding an RGBA input raster image.
Hi
https://news.ycombinator.com/item?id=39829485
I got second-hand embarrassment from seeing this thread shared anywhere.
mentally ill pixelphile thread
Buncha morons ITT.
AVIF is a joke on a technical level. Similarly to HEIC images it's an AV1 video bitstream in the HEIF container. It's a video codec - it has no progressive decoding for I-frames (blurhash hacks don't count and are inefficient). But compared to HEVC the bitstream cannot handle transparency and it's way too late to fix that, so AVIF relies on a secondary video track in HEIF that's grayscale to supplement transparency.
On top of that, lossless AV1 isn't a priority for any of the encoder developer teams and never has been. Considering that the alpha layer is best kept lossless that's fricking shit, not to mention using AVIF for hi-fidelity images or archival purposes (but that's another rabbit hole about how YCbCr/601 matrix are significantly better than RGB for AV1).
With that said AVIF is the first lossy image format since forever that's not totally utterly dogshit (jpeg2000 and webp lol) and has normal interframe compression that's miles better than JXL (because it's a video format lol) making it over 100x better in filesize, not to mention the quality than gifs/apng/awebp in literally any scenario except very very tiny 1 frame icons (header overheads, which you wouldn't use gif for anyways in 2024) and making it the first animated+alpha medium that doesn't suck and will have wider adoption (looking at you, fricking vp8/9 with yuva420p and hevc with alpha).
Now consider how fast decoding AV1 with libdav1d is and how despite all of this JXL struggles to remain on top or sometimes struggles to stay competitive considering it's literally designed to be one thing only*. Not to mention the AV1 hardware decoding capabilities that will eventually apply to AVIF. You now understand why JXL is frowned upon by many.
With that said, fricking hell, why not let both live? JXL has its clear advantages and AVIF clear disadvantages. Why debate JXL vs AVIF at all? Old IQfy would bash big corpo for not supporting both.
>/thread
Forgot to mention how JXL often shits the bed for line art and complex repeating patterns (and fractals somehow) in paragraph 3 as can be seen by images ITT.
It is better at line art tho, unless you pick specific lossy parameters.
First of all we need a good LOSSLESS format. The lossy formats will anyhow be generative AI sooner or later, why send kilobytes of information for a super compressed ugly 8k or 16k image when you can send bytes of pose information and a general character description and a reused logo and get the correct thing.
Also forgot to mention AVIF being easy to extract from AV1 videos. And the noise synth working on images.
Huh.
go back to your other shit thread, homosexual
Yes, for video purposes AV1 is awesome, it makes sense this translates well to animated imagery, which, however, is only a niche in an image-based web.
You'd either animate an SVG for vectors and size-saving or it's a .webm thumbnail from moving pics and that would be AV1's thing.
The rare case would be an animated AVIF replacing the gif, which is basically only used on image-boards nowadays (RIP MySpace).
For everything else, whether rasterized vector graphic or photographic content, there's JXL.
So, to me at least, in the first step, it would be more important to establish JXL than AVIF, as AV1 (and therefore (animated) AVIF) will be (is?) automatically included with .webm support.
Basically, what I'm saying is, if you want both, you should be shilling JXL, because AVIF will in all likeliness be included anyways, it's JXL that requires overcoming more entropy.
I want both, and also universal .cb7 with JXL support would be amazing.
At least THIS future can be bright, come on.
Are you sure that AVIF with its alpha hack is a superior transparent video format compared to VP9?
i thought i'd try it myself since a certain someone doesn't want to post the source he used to encode the examples, or he's a moron and encoded the jxl from the av1 he got the avif from
i tried with a png anime-style drawing, default jxl quality, "10" (best) effort, versus avif default effort, crf 11 to match jxl size
the avif looks better, though i'd say they'd be very hard to distinguish with photographic content instead
it takes take quite a bit longer to encode the avif, it's worth noting
i agree both should be supported, jxl has many important features such as jpeg recompression, progressive decoding, generational loss resistance, support for >8k resolution without tiles, and so on. as an image format it's better by a long shot
in the rare case i want to save an av1 keyframe, i'll use avif, i suppose
Can you also try with AVIF speed 0 (slowest/best effort), and another pair where the JXL uses the default effort? Otherwise, JXL on slowest mode and AVIF on speed 6 is an unfair encode speed comparison.
As for the quality, how about some objective metrics? SSIMULACRA2 and DSSIM should be fine, since neither codec was optimized for them.
>since neither codec was optimized for them
Don't the same people who make -psy forks of AV1 encoders compare against ssimulacra2 and then get some of their improvements merged into the core encoders?
I don't really know, perhaps. They did it for butteraugli in the past, at least, but I'm not sure if any of it was merged anywhere. My avifenc only lists PSNR and SSIM (both awful metrics) for libaom's tune option in --help.
SVTAV1 also has tune=0 which is documented as "VQ"
It's dogshit.
https://wiki.x266.mov/blog/svt-av1-deep-dive
>x266.mov
I'm sure they are in no way biased at all against AV1.
The article is pro AV1 you fricking schizo. It's just a meme name for the codec wiki.
>he doesn't know
please don't post in future AV1 threads, i hope this was ironic
Ok, so I took a look at it, and hats off to the *extensive* graphing, but I actually already knew the conclusion in advance.
My bad for misinterpreting from the domain's name alone, I did a judge a book by it's cover.
The key to a good density encode is to have a high-bitrate original source (less compression artifacts) and pre-filtering the image, the most obvious culprit film grain, but opinions are split on this on whether it is an artistic component of the recording or a technical artifact of its time.
If you view it by the latter and cleanly denoise grain, you can sometimes even squash things down to 50%, though that may only seem excessive because the output file size with heavy grain is quite high.
You gotta think like the encoder, it needs to know the shapes and colors.
Oh yeah, and 10-bit encoding to avoid blocky artifacts in dark areas (or switch color range from TV to PC, the reason is flooring because not the full 0-255 color channel value is used).
10-bit can still help a bit since YCbCr has rounding issues at 8-bit, but YMMV.
Butteraugli only works with 8-bit, though, so I use that.
>10-bit can still help a bit since YCbCr has rounding issues at 8-bit, but YMMV.
Thanks, Anon, I did not know that <3
That's absurd. You either control for speed or just use the best either have to offer. It's not unfair to use a faster preset on one if you're trying to achieve the former.
You can't use a slow preset on one, fast preset on other and then say "the fast preset one is faster than the slow preset one!".
>and then say "the fast preset one is faster than the slow preset one!".
The opposite was said.
Oh, my apologies then. I've misread that bit.
To be fair, thread count also interferes with that metric.
>why not let both live?
Because jxl will shit up the internet just like webp does right now. I don't need another image format that isn't supported by anything, I don't want to download jxl just to convert it back to jpg so I can use it.
More non-browser software supports JXL but not AVIF than AVIF but not JXL, although most supports either both or neither.
jxl has a better chance of being supported by picture viewers/editors than webp, since webp was only ever intended for web viewing
webp i don't think improved the web, they were barely any smaller than jpeg, and had some of the same problems avif does, such as no progressive decoding (which plain old early '90s jpeg does), like what's the point in shaving 5% off the file size when a progressive jpeg can let you see the whole picture while it's only half loaded?
Don't get a mad on, get the add-on.
https://addons.mozilla.org/en-US/firefox/addon/jxl/
https://chromewebstore.google.com/detail/jpeg-xl-viewer/
Doesn't work. "Image contains errors and can't be displayed."
Must be the website.
Nothing supports jxl
It's a meme
>i only use google products
Ok shill
0.0 is lossless
i am aware 0.0 is lossless, i find 0.5 to produce 99.9% visually identical results with considerable filesize reduction
I don't even use Google or any of its services. AV1 and AVIF are the superior technology, doesn't matter who created it.
Literally cannot open on Firefox or Chrome.
What the frick is the point?
you replied to a post telling you how to do it in Firefox........
It's not the default, you fricking moron.
Nobody cares about:config hacks that let you do something that isn't the default. Not to mention that even if they make it the default it would still mean that only 5% of web users would be able to see any jxl image you have.
Do you not understand how this alone makes the entire thing a fricking joke considering the competing format already has support?
Already has support*, better or at least comparable compression rates and is faster.
Once again JXL lost before the fight even started.
Anon, are you for real?
Telling them to use image.jxl.enabled in about:config without telling that it works in Nightly builds only — and even there it is pretty much outdated/broken —
That'll cause one hell of an anti-JXL impression.
Why are you doing this?
Have you perhaps been mind-raped in a similar fashion?
If that's true, I didn't know. Works in Librewolf, though it seems to save it in a temp folder somewhere on my computer and opens that
I have one open on my desktop right now, and I didn't download any special image software.
works on my machine
https://github.com/sylikc/jpegview
about:config -> image.jxl.enabled=true
Frick Google. Frick Chrome.
The free web will prevail. The will of the developers will.
AV1 is shit. Google is shit.
Yout hatred towards Google has never been a worthy argument for Google's JXL vs. Google's AVIF.
At this point, it's Apple's. Google's royalty free patent holds no power.
Why Apple's?
Just because Apple supported JXL in Apple's web browsers?
Fine, then it's Apple's JXL vs. Apple's AVIF, lol.
Apple was late to the AVIF party, so that doesn't count.
No you got it all wrong
It's Daiz's AVIF vs. Daiz's JXL
Name one post that you've made without attacking JPEG XL, Daiz.
So umm explain something to me real quick, if av1 video keyframes are in avif, why isn't it possible to create a video codec that has jxl keyframes?
It is possible.
There was Motion JPEG.
There was Motion JPEG 2000.
Thus some Motion JPEG XL is also possible.
You already can. It supports animations.
You shouldn't, though.
Do you mean jxl shouldn't be used as an alternative for gif? Because I think gif is a horrid format and needs to die as much as webp does 🙂
>gif is a horrid format and needs to die
Give it a break, it's from a more innocent time.
But yes, some replacement is due.
I'm fine using AVIF for these though, that seems cut-out for it.
JXL is not optimized for interframe processing.
There was some talk about replacing AV1 iframes with JXL and leaving the rest the same, but I don't think that anyone spent a significant amount of time implementing that.
is the grain just a fact for avif?
For me it's webp because it has "p" on it