JPEG XL

Damn, I was busy running benchmarks xD

But yeah, that was during a charity stream with a friend, so not your usual gameplay

On PC?

Yeah

If you have an HDR display with Nvidia App or Xbox Game Bar, it would be JXR

I know, I have JXR files even in SDR

Interesting I thought JXR is for only HDR screenshots on Windows

I use the default capture so they're always PNG

That was using NVIDIA photo mode. Usually I just print screen

My GPU is from AMD so that's not possible

The JXR is broken anyway, so it doesn't matter

Looks pretty surreal

Very red, that's for sure

Writing a tutorial about using WebP lossless (including near-lossless) for a Chinese forum

It explicitly says WebP lossy is worse than current JPEG encoders

Uh an account is required for thumbnails https://www.tyboard.net/forum.php?mod=viewthread&tid=1770

Didn't know I could upload WebP on Discord now

WebP has worked on Discord for quite a while

Hmm I haven't tried it for long time

So impressive that thumbnails display more information than original images

Discord breaks if you don't have webp support :/

One of the only websites that won't allow you to disable webp in the browser and accept headers

I wouldn't disable something part of <@532010383041363969>'s masterpiece

Lossy wasn't his work, but yeah

He was ordered to cripple it on purpose too, to match the limits of the crappy lossy mode.

Even though there was no technical reason not to support higher bit depths and larger image sizes

Image sizes no, hardcoding for 8-bit does allow some things that become harder when you also have to support higher bit depths though. Such as the color cache.

Decided to follow this for PNG again https://imageoptim.com/color-profiles.html

Fed up by many weird colour profiles (not spaces)

> Save images in the sRGB profile with gamma 2.2, but don't embed any profile in the image. That's the most compatible and most efficient solution. heresy

boy I hate this

if you want accuracy, save with 2.2 *and tag with 2.2*

that way colormanaged applications will do it right, and non colormanaged applications can get it rough 50% of the time

He has some strong hates on something like animated images

Do JPEG and JPEG XL both always add sRGB IEC61966-2.1 on purpose when the original PNG file doesn't include any colour profile?

I legitimately did this for a time, most apps I was using didn't have color management (or a really bad implementation) so stripping out the profile after converting to srgb was more consistent and less of a hassle for me. 😅

I thought the icc profile was just bloat

Apparently at the time leaving your images untagged was the most consistent for some reason. https://kornel.ski/en/color

If you don't agree with his reasoning, you can just ping the dev, he's here in the server

I’m not sure I realised that ICC profiles even existed before I learnt of their function

Using untagged implicitly sRGB images is kind of OK imo, probably even a good idea a few years ago, but I think today many displays are P3 and it's better not to clamp the gamut.

and even libjxl’s Display-P3 ICC profile (not enum) is 536 bytes, nowhere near the 100 kB mentioned on that imageoptim page

using untagged images is ok as long as you have no care for decent accuracy

whether an app linearizes the image using the inverse sRGB oetf or using a pure 2.2 is up in the air. and ofc you have the issues of display too but you have that anyways

Usually only CMYK profiles get really big, as in hundreds of kB. Typical RGB spaces can all be described in an ICC profile well under 1kB.

Untagged means sRGB according to W3C, and by now I think all browsers follow that.

realistically, don't most people use color managed applications (web browsers) with ~2.2 displays and the default (sRGB) icc profile? that makes it look wrong

we don't know how displays work on average, best guess is a survey filmlight that found around that at minimum 25% of displays, possibly 50% use a inverse sRGB oetf. We also can't always know for sure how our source image was graded. This is why tagging 2.2 is ideal. On a color managed pipeline it will work perfectly. Applications can take the 2.2 tagged image and convert it to to display properly on an inverse oetf monitor. On a color managed application and a non colormanaged display, the color managed application *should* pass through the 2.2 as is, so should the non color managed application. at this point you have a "best guess" of around 75-50% chance your image will display correctly. this also has the benefit of making editing the image way easier since we don't need to guess if it was sRGB encoded or 2.2 encoded

> On a color managed application and a non colormanaged display, the color managed application *should* pass through the 2.2 as is right, except iirc that's neither what chrome nor firefox does if you just have the default sRGB profile assigned in windows

yeah but then you have a color managed application and a colormanaged display

i'm just talking about what windows does out of the box

iirc windows sets the default profile based on EDID

no, you just get the sRGB profile

hmmm, last time I checked my TV defaulted to a rec709 profile, but I can check again

maybe if your on Windows 11 and have some bleeding new monitor but in my experience whenever I or a friend try plugging in a P3 monitor Windows will have no clue it's P3 and you need to go out of your way to download the ICC from the manufacturer and set the monitor to it

this is how it's been for all my P3 monitors and most if not all of my friend's P3 monitors

> by now I think all browsers follow that Last time I checked, Firefox default was still to displayed untagged images in monitor‘s colourspace? (they’ve fixed it and then went back) But I haven‘t checked in a while.

Maybe that's an issue only for JPEG and PNG

Does FileOptimizer use more efforts on PNG by default? The optimisation took longer than my expectation

Usually I use ImageOptim on macOS

For a 2 MiB PNG, FileOptimizer took about 10 minutes by default (effort 5), and it took about 30 minutes at effort 9 with additional saving of... 2 KiB

Converting to lossless WebP could be significantly slower than lossless JXL but still be massively faster than PNG optimisation

FileOptimizer simply uses ECT under the hood (between others), but I don't remember what was their default compression setting (I saw many times `-60099`, but not sure)

The OxiPNG phrase took the longest

Oxipng never takes more than a second or two per image for me on an ancient cpu

Usually under a second

Well, depends on settings, and the image

Worst case it's using Zopfli, which isn't a multithreaded fork like ECT

Is there any PNG optimisation that utilises multithreads?

Well, *sometimes* ECT does with `--mt-deflate`

Just use default oxipng...

It's crazy fast

I didn't change anything for that 10-minute optimisation

Everything was default

oxipng standalone (not part of some other image optimizer ui) never takes that long

When I run oxipng by itself on the command line it always finishes in 1 second

How big was the image?

I've said, about 2 MiB

This one

<:garfieldneutral:823249094180732998> Neuron Activation<:garfieldsurprised:823250154319773727>

Much faster with ImageOptim but the compression isn't that aggresive

About 6 KiB larger than the highest effort of FileOptimizer unfortunately

pingo is also multithreaded and is somewhat faster than ECT in my testing

```wintime -- oxipng -a --strip all janeDoe.png PageFaultCount: 66614 PeakWorkingSetSize: 71.63 MiB QuotaPeakPagedPoolUsage: 29.79 KiB QuotaPeakNonPagedPoolUsage: 7.297 KiB PeakPagefileUsage: 106.9 MiB Wall time: 0 days, 00:00:00.940 (0.94 seconds) User time: 0 days, 00:00:00.078 (0.08 seconds) Kernel time: 0 days, 00:00:01.265 (1.27 seconds) wintime -- pingo -l -strip janeDoe.png PageFaultCount: 60378 PeakWorkingSetSize: 63.04 MiB QuotaPeakPagedPoolUsage: 28.73 KiB QuotaPeakNonPagedPoolUsage: 7.43 KiB PeakPagefileUsage: 73.99 MiB Wall time: 0 days, 00:00:00.632 (0.63 seconds) User time: 0 days, 00:00:00.046 (0.05 seconds) Kernel time: 0 days, 00:00:00.625 (0.62 seconds) wintime -- ect --mt-deflate -strip janeDoe.png PageFaultCount: 163015 PeakWorkingSetSize: 68.36 MiB QuotaPeakPagedPoolUsage: 25.8 KiB QuotaPeakNonPagedPoolUsage: 9.422 KiB PeakPagefileUsage: 74.86 MiB Wall time: 0 days, 00:00:01.592 (1.59 seconds) User time: 0 days, 00:00:00.093 (0.09 seconds) Kernel time: 0 days, 00:00:02.640 (2.64 seconds)```

```oxipng - 1,897,397 bytes pingo -- 1,906,135 bytes ECT ---- 1,907,564 bytes```

Isn't -a (--alpha) of OxiPNG somehow a bit lossy for the Alpha channel?

Testing again as I didn't put --strip correctly

I thought -s and --strip were exactly identical

Unless you're using the 100% transparent pixel values for something, the loss is not important.

`dssim 0.00000000 ssimulacra2 100.00000000` That's true

And interesting that `oxipng -o max -a -Z` performed significantly faster than without -a

I would recommend using `--fast` with `-Z`

speeds things up quite a bit

`byte sec command 1,891,258 236 -o max -a -Z 1,895,231 4 -o max -a 1,895,231 93 (ImageOptim Pngcrush+OxiPNG) 1,895,597 111 -o max -a -Z --fast 1,981,670 386 -o max -Z 1,981,670 162 -o max -Z --fast 1,987,272 5 -o max`

all with `--strip all`

Surprisingly efficient with `oxipng -o max -a --strip all`

fun fact, `-o 4` is often just as small as `-o max` so if you want speed its a good option

Doing -o max -a -Z on my favourites and wow about 20 KB is saved within 2 hours

nice

That's for images already optimised before

Sometimes it would say "Could not optimize further, no change written"

file size = 3335881 bytes (2510 bytes = 0.08% decrease)

```1,893,329 48m10s ect -99999 --mt-deflate -strip 1,893,382 8m46s ect -80199 --mt-deflate -strip 1,893,877 4.7s ect -9 --mt-deflate -strip``` I think that ECT is a little bad at dealing with alpha all the cases where I saw ECT loosing (ie not giving the smallest output) had alpha perhaps there is no alpha loss at all (even if completely transparent and would not change anything visually)?

It took 40 minutes more for saving another 53 bytes

<:YEP:808828808127971399>

and perhaps it could save a few bytes again by not using `--mt-deflate` [⠀](https://cdn.discordapp.com/emojis/654081052108652544.webp?size=48&name=av1_Hmmm)

ZopfliPNG prevails

no

Still spending my entire weekend on using ZopfliPNG via OxiPNG towards my favourites

Sometimes it could save about 1% additionally that's impressive

`11296138 bytes (34 bytes = 0.00% decrease)` Niiiiiiiiiice

`ffmpeg -i INPUT -movflags +faststart -pix_fmt yuv420p -vf "hqdn3d=luma_spatial=1:chroma_spatial=1:chroma_tmp=2:luma_tmp=3,zscale=w=1280:h=-2:filter=spline36" -c:a libopus -b:a 120k -frame_duration 60 -vbr on -c:v libx265 -preset placebo -bf 5 -refs 4 -crf 26 -g 900 -x265-params "open-gop=1:me=star:rskip=0:tskip=0:scenecut=0:rc_lookahead=60:aq-mode=3:lookahead-slices=0:wpp=1:ctu=32:b-intra=1:qg-size=32:subme=7:qpstep=10:aq-mode=3:weightp=0:weightb=0:aq-strength=1.4:tu-intra-depth=4:tu-inter-depth=4:early-skip=1:rd=6:qcomp=0.7:rect=0:amp=0:psy-rd=0:rdoq=0:psy-rdoq=0:cbqpoffs=-2:crqpoffs=-4:min-cu-size=16:no-deblock=1:max-merge=5:merange=92:frame-threads=1" TG_OUT_EASYHEVC.mp4` special key for hevc. I make it for a very long time. hevc result in decoding speed is same to avc at the same resolution. Default for 4-6 cores. For parallelization on 8+ cores replace frame-threads=1 with frame-threads=4 at the end 1280x only. crf 26-28 only.

made for telegram <:H265_HEVC:805856045347242016>

`16201380 bytes (13 bytes = 0.00% decrease)` Yeeeeeeees

Wonder if I can't reach closer to 0

is it that file ?

I've been optimising other files

It always makes me sad when I read things like "There is little support for JXL and it is unclear if it will gain acceptance on the web (especially as Chrome removed support)." - https://github.com/lovell/sharp/issues/4314

we can be in comfort knowing they are wrong because apple devices are already a, while a minority, still a significant one

It makes me wince seeing UltraHDR when jpegli can already do it without having to bloat filesizes

"UltraHDR" is cringe

ultraHDR is chad [av1_chad](https://cdn.discordapp.com/emojis/862625638238257183.webp?size=48&name=av1_chad)

anything that helps me leave cursed SDR is good in my books 😎

~~Meanwhile me on my 8 year old hardware~~

Linux and panel swap time [av1_chad](https://cdn.discordapp.com/emojis/862625638238257183.webp?size=48&name=av1_chad)

It took over 4 hours to optimise 4 images about 300 KiB each, with ZopfliPNG via OxiPNG on an office laptop

https://www.jwz.org/blog/2023/09/webp-is-going-great/

I love jwz :D

OxiPNG: `public.png: Invalid PNG header detected`

OxiPNG: `55530 bytes (17.92% smaller): ...\dog.png`

This is actually an AVIF

Hmm that damn source calls it PNG

That `dog.png` is hosted by the website itself instead

hold on, does discord now support AVIF previewing?!

you only need to rename them to a png? <:kekw:808717074305122316>

Apparently on Desktop, yes

On my phone it was broken

huh

that's news for me

yeah, discord desktop is just an electron app, so it uses electron to render the preview

Wait, nevermind, it's sending WebP

I don't have a JXL capable browser signed into Discord but I'm gonna assume it doesn't work lol

so, the previous behavior (for the longest time) was that discord used to refuse to give a preview of AVIF files

if you are on desktop app or chrome, better discord has an extension that lets you embed more formats directly

yeah, for the desktop app it was likely because of old chromium. on web app it worked for me for a long time

interesting 🤔

https://github.com/Knewest/embed-more-images

aww it still doesn't work for jxls

worth the 5 second try though

yeah since it relies on the browser, if you use betterdiscord in a modded chromium and mod this extension it does work

I did try with the wasm extensions but it doesnt work, chromium itself needs to support it

it's worse IIRC, discord clients have code to show which image/video attachments are "thumbnailable", so the previous behavior was that if you dragged an AVIF as an attachment, you got a preview of the file (because the underlying Electron browser supporting the format), but once uploaded there was no thumbnail and the attachment just looked like a regular file

this is without extensions of course

extensions are love and life <:Hypers:808826266060193874>

yes. that is because discord transcodes the image themselves and creates the thumbnail. This is necessary, but since they use their own software its fairly limited

I wish they would've worked on supporting AV1 video first, it would've caused an overall greater impact

but I guess they're too worried about inconsistent behavior because of iOS users without HW accelerated AV1 playback being unable to play those vids

i dunno, all I know is that I wish we had more third party apps lol

me too

we also have https://github.com/Knewest/uncompressed-discord-images extension which is nice

the only one I know of is https://github.com/diamondburned/dissent/ which requires gtk sadly

I thought they used AV1 for streaming at this point?

only for certain nvidia cards with AV1 HW acceleration IIRC

https://support.discord.com/hc/en-us/articles/12158692510743-Video-Codec-FAQ#h_01GRYP1FMKTKBCHQ198JCPM0Q1

i.e. nvidia paid discord some mad money and discord said "yes master"

(to add, only encoding acceleration is required from the streamer, everyone will see AV1 streams regardless, according to the above support page)

Wait so it doesn't work on systems that have other AV1 encoding hardware? Just Nvidia GPUs?

I wonder if there is a client mod to use it for amd andintel ones

Man that's kinda scummy

I guess Nvidia's deal is a net positive even if it's costing them more in bandwidth to serve H.264 compared to AV1

nope, just nvidia right now AFAICT

they might've even used a vendor-specific API FWIW

I wonder so too, they'd need to write some kind of wrapper to translate between API calls I guess

this was done pre-Vulkan video encode extensions

Maybe you can point an AV1 stream at their API endpoint instead of letting the Discord client generate a H.264 stream

it is just chromium, so no need

it will use what chromium uses.

likely vaapi, they are likely checking gpu on linux? dunno never looked into it

I mean the encode part, I'm not entirely sure if they used the stock chromium video encode API, or wrote an Electron extension to talk to a custom API and bundled it with their standalone clients (but this seems way less likely)

couldnt say

a good exercise for modders to investigate 😎

They were meant to have a fallback, so that if a viewer doesn't have hardware decoding, the stream fallsback to H264/H264... That doesn't work, as I found out when my friend with a 4090 reduced my computer to a stutter by sharing their 4K screen

I was in a game at the time, wondered why I was only getting 12fps and huge stutters... Had a hunch, opened the debug info and it was 4K AV1

I think the Discord-approved solution to this is that you should also buy a 4090 from their business partner

5090

lmao

discord dev moment

that being said, I would stream 720p easily assuming decent down sampling, too bad thats pretty hard to do for text

Is that the one that people thought had great improvements but the provided benchmarks used frame generation?

WHAT

LMAO thats messed up

Yeah it was like, for every frame there were two AI generated ones, and that mode was used for the benchmarked games

Or that's what I heard, I didn't watch it

I don't really care personally, I'm content with my laptop and steam deck

https://discord.com/channels/794206087879852103/806898911091753051/1331362457041768482

Wouldn't frame generation massively increase input lag?

Around 1 to 2 (real) frames

That's really awful actually. So it's basically no different than enabling vsync + motion blur to add a ton of lag to your screen like a drunk and intoxicated effect. But it's even worse because it "increases" your fps making you think you're getting faster performance when it's actually making it tremendously slower to react to your input and movements

someone did a test of 60-80 ms, which is not great

They combat it with 'Just use Reflex' and now with Reflex 2 it *might* feel like better latency even if it's fake

5000s new multi-frame gen doesn't seem to be too good

it generates too many shimmering and ghosting artifacts

the new transformer upscaling does look promising though

yeah, Discord web & desktop now support AVIF attachments & embeds, requested as WebP by the app for broader compatibility

excellent job!

question: are there plans to support HDR?

the current resizer seems to handle HDR in a funky way -- the colors look washed out

example:

<:PepeGlasses:878298516965982308> no way

yeah, resizing converts images to 8-bit depth, but does propagate ICC color profile data that image uses 12-bit color, so the conversion from 12->8 bit color is probably what's goin on

ah, that's probably why

yep, one major advantage of JPEG-XL and AVIF for sure

this is small BRUH because when you open the original, discord force download, not viewing it as a webp/jpeg/png

the image doesn't have an ICC profile, just CICP metadata

it's not mine, but it was most likely a frame taken from a video capture

so most likely the PQ transfer is getting messed up with the conversion to webp

where can I report this? the lilliput repo?

this is likely the discord CDN need to be taught the correct MIME type for AVIFs

finally 0 kb image

yeah, plz do, just open an issue here with details: https://github.com/discord/lilliput

sweet, will do

for this one, is there a specific place to report?

It really amazes me how they can work like this. How can they add format support BUT never open it. just how possible <:NotLikeThis:805132742819053610>

that's prob because that falls under the purview of a different team (CDN in this case I think)

my friend says that his discord crash when he tries to upload my picture lol

this repo is best for that CDN mime-type issue: https://github.com/discord/discord-api-docs/issues/

I've already got a fix staged fwiw

Well, this explains why Discord hasn't received native Av1 support for 7 years now

<:Stonks:806137886726553651>

oh sweet, looking forward to it 👍

IIRC, this one was because the that software that creates the embed (including the thumbnail) requires an environment that understands parsing an AV1 video bitstream

which wasn't the case for the longest time, not sure nowadays

it might be now a case of "yep, we understand AV1 streams now" and the embedder will just work just like with VP9, AVC and HEVC

hope <:JXL:805850130203934781> gets the respect it deserves soon too

tbf, I doubt discord will want to ship a wasm decoder any time soon which kinda bones web users.

it could be done in a best-effort manner too: probe Electron/browser/etc for AV1 decoding/JXL decoding support, and only show the embed if there is support, otherwise show a regular attachment or serve a transcode

but anyways, it's their choice

There *are* maintained patches for Chromium adding JXL support back in, ready for when they revise their decision, but Electron could be a bit more hassle

i wonder if one of the extensions things could bundles wasm [Hmm](https://cdn.discordapp.com/emojis/1113499891314991275.webp?size=48&name=Hmm)

A bad choice is also a choice. which says something Well, or as they say. "WE implemented support for the animated webp, but WE haven't implemented support for apng, which had in our stickers for many years."

That's bad. Add that point you should add lag to the audio for it to not appear out of sync...

Our brain can somewhat adapt to audio lagging behind, and even some input lag, but not video lagging behind audio...

Any video lag relative to audio of more than ~40ms is unacceptable.

I may be getting ahead of myself but I'm unreasonably excited that the Discord Media Infrastructure EM just joined this server

My immediate thought was "Time to show them what JPEG XL is made of"

With the sheer amount of JPEGs uploaded by users that are just sitting in storage, and mostly have their webp previews served, I imagine the 'lossless JPEG transcoding' could be pretty huge just for storage even if you're never serving them to users

But this goes for many platforms, I'd expect the Internet Archive, Wikimedia etc to be all over this but they're not

Maybe a 20% reduction in storage usage isn't worth the effort

Mine was "don't scare them away with your enthusiasm" <:galaxybrain:821831336372338729>

Well, currently mobile uploads are recompressed as quality 40 JPEGs, so you'd want normal lossy rather than transcoding to get more bang for your buck

Personally I'm kinda sad about half baked formats like webp and avif wasting so much time and space.

Oh are they? Like you can't get the original back with 'Open in Browser' either?

And being forced on everyone just because the guy who leads the team that pushed those formats also happens to be the key/sole decision maker over what codecs Chromium will support.

Oh that is so much worse than I expected

Oh that actually explains a lot

You know I thought "wow phone cameras these days really go all out with tone mapping and post processing" but I guess they were just being compressed more. The tone mapping argument remains though xD

Uploading from Desktop still sends the raw file, so that's also still true. You can tell when someone's sent from mobile, not even sure how blue got into the black of the tunnel

I honestly feel the exact opposite, working with JPEG XL, Rust, and other technologies that are significant improvements unironically fills me with determination

Strange that they lowered the quality instead of resolution, means absurdly high res files get rewarded more quality just from downscaling, even though they waste memory and time

Actually, <#803645746661425173>

looks like it's both lowered quality *and* resolution

original is 20 MP, encoded is 1.2 MP

But the Chromium Codec Lord and webp/avif lead has declared in his infinite wisdom and ego that there just "isn't enough interest" compared to his own half baked formats

Huh, so they took away the one way to work around it on mobile

desktop uploads should still work I think, testing:

yeah, desktop (more accurately, web interface) still keeps original resolution and quality

I'm just wondering why the black level on that image is so much brighter than the black discord chat background on my iphone

Why is black not black

That's clearly supposed to be a pitch black shadow, but it's brighter than the discord background

no idea TBH, I've seen cameras do blacks as dark grays as some sort of stylistic choice

"Ugly and stupid and wrong" is not a valid stylistic preference... :(

yeah, there's no way other than changing the extension unfortunately on mobile

other than using a 3rd party client or literally load the desktop experience on the web

Here's the RAW, also wow. 8 years old and my phone has native 7z compression

Okay so discord did also downscale the resolution then

I didn't notice that at first, I was getting worried when at distance 24 it still wasn't smaller than Discord's JPEG 💀

--resampling 8

:>

ooo I like that

delightfully devilish

prob --resampling 4 is best to match discord's target (that's what discord used to downscale it to)

Aurora Borealis, at this time of year, entirely localised to a Quality 40 JPEG?

may I see it? ȳ̵̚e̵̪͗ś̴̺!

Seymour! The colors are banding!

*Steamed Hams Recited From Memory But I'm Obsessed With Image Formats*

It's worse than I thought, maybe they do have some kind of size target that trades resolution for quality?

filed https://github.com/discord/lilliput/issues/214

github doesn't want avif or webp attachments? just rename their extensions to jpeg!

they originally joined the av1 discord, I just brought them here <:kekw:992848817324052601>

No, mother, it's just macroblocking

-d 25 —resampling 8

https://www.rxddit.com/r/discordapp/comments/1i8c38s/i_hate_10mb_limit/ oh god not this again

can we at least get mozjpeg q95 if compression is enabled

If you're gonna change it, why not jpegli

Get the size of WebP but with actual progressive loading too

Now these macroblocks are quire similar to the ones from JPEG '92 Oh ho ho ho ho noo, patent-free VarDCT! New quality coding tool!

it's better? <:av1_thinkies:895863009820414004>

I haven't messed with images for a while now

<https://giannirosato.com/blog/post/jpegli-xyb/>

Better than WebP, and better than AVIF above a score of 60 or so

Then throw in the progressive loading, the gracefully degrading [10~bit encoding](<https://github.com/RawTherapee/RawTherapee/issues/7125#issuecomment-2538513015>)....

intriguing

I'll switch over rq then

looks like the fix is in

the original AVIF is opening in the browser now

Huh, well at least we know it's optmized https://cms.accuweather.com/wp-content/uploads/2025/01/trimmeduk-ezgif.com-overlay-smaller.gif?w=632

Éowyn

does any1 know how to extract avif from an av1 video the *right way*?

doing this results in a low quality image: `ffmpeg -ss 10:00 -t 1 -i in.mkv -frames:v 1 -c copy out.avif`

what do you mean by low quailty? I've tried your method and it seems to work fine

in the av1 server in scripts channel search bsf

the img looks much worse than the video itself

I can't seem to replicate, comparing a screenshot of the video and the extracted avif, they look about the same

is this a context skill diff? export as a png and diff it

not on desktop rn

ill try ur script later

does anyone know about the APV codec?

looks like google scam <:VP9:981490623452430376> <:avif:1280859209751334913>

like EVC codec scam <:ReeCat:806087208678588437>

https://github.com/openapv/openapv

it doesn't work last I checked it

it just produced garbage

looking at the readme, it seems to be intended as something like DNxHR / DNxHD / ProRes?

not sure why I’d use it on an Android device

I believe so yes, I was sadly never able to get it working, but my workflow works just fine with jxl punted into an mkv anyways

Phone capture, Generally (when paired with some light processing) phone cameras are generally capable enough to fit the needs of many videographers, the main issue is that we have HEVC or AVC for capture, both of which are... bad to put it in the best possible light

this is to compete with iphone + prores

actually, I wonder. I bet an hwaccel jxl encoder could do this quite nicely [Hmm](https://cdn.discordapp.com/emojis/1113499891314991275.webp?size=48&name=Hmm)

Maybe Google plans for parity in regards to video recording? Since Apple supports ProRes capture on the iPhone

Very exciting it true

DNjxL

They probably want it for Pixel phones, the camera is a selling point

I'm not sure we would have had their HDR JPEGs either if Pixel wasn't a thing

yes, the same shit as the EVC. There are no encoders binary, no decoder, no comparisons of quality, speed, and no sense at all in all this It looks like they couldn't create an efficient AV1 encoder and don't want to take intel svt-av 1. just because. It's just that there's something that **one developer** want and could push into Android 16 for personal purposes. It's all very strange

Okay. Let's we'll see later. Because I can't even look. This is what was done literally yesterday "by the standards metric", there are not even any tests anywhere. This year I faced the fact that AV1 is 10 times more expensive than AVC and I just can't use it as an codec that anyone can play. at 1280x720 resolution. Therefore, I spent a lot of time to create a HEVC version that will have super-fast decoding speed comparable to AVC. https://discord.com/channels/794206087879852103/805176455658733570/1330805672127758336 APV could probably be a good candidate to replace HEVC. Provided that the decoding complexity is the same. Provided that the quality is better than HEVC. Provided that the encoding speed is faster. -- but if at least one of these conditions is not met, well, it will be a useless codec. Because besides HEVC there is VP9 which also meets all the conditions, and even the decoding speed of VP9 is almost the same as AVC.

vp9 is killed by parallelization issues at the design level of the standard

svt-vp9 to be honest, worse than x264

https://tinydng.com/

Interesting > TinyDNG parses the input DNG file, and then it replaces the preview images with the Jpegli re-encoded data and replaces the high-resolution part with the JPEG-XL encoded data. The compression process runs in the browser, and no server is needed.

Some mentioned before but I missed

I'm fairly sure it uses JXL not jpegli for the preview

Samsung is the ones announced to be supporting it

that in the end doesn't make much sense for this, since it is something only application/hardware devs will use

APV is going to be like, 10x bigger then hevc or vp9

<:galaxybrain:821831336372338729>

yup, as said here > The APV codec is a professional video codec, which was developed in response to the need for professional level high quality video recording and post production. it's intended as a replacement to something like prores/cineform/dnxhr basically, it's a mezzanine, you will likely get similar file sizes by just encoding a sequence of jxl frames

clear. in general, the thing is not for normie people then it makes sense

apart from avc and hevc, there are no other formats that can compress near loseless

or some 12+ bits color

yup, and even then AVC and HEVC are far too slow to deal with in most workflows that this is intended for

Seems they treat d0.5 as visually lossless

which it is

d0.5 is lossless enough in most cases

From the AIC-3 draft <@794205442175402004> shared in October

So there are some formal values for quality points

Use cases as well

This is still just a draft, it may change during the process. Plan is to submit DIS in April, and then it's about half a year for national standardization bodies to comment.

Sure just for references and not official yet

Then WebP's recommended near-lossless 60 is also roughly identical to "boosted visually lossless"

I feel like that's my private recommendation -- has that been lifted into an official recommendation by the webp maintenance team?

Yeah it's not officially recommended. No value is defined.

I would presume that this feature has been forgotten for years and there was even no review for it

I wouldn't call my short tutorial and comparison as a review

No one should give Google any money or watch YouTube without an ad blocker frankly

You're already paying them with your taxes

Did you do some further testing after this?

not yet

no i don't <:trollhq:1116404564007080067>

You don't pay taxes? Nice. It's typically not a good idea in the long term to give gangs and protection rackets what they want.

> Specify the level of near-lossless image preprocessing. This option adjusts pixel values to help compressibility, but has minimal impact on the visual quality. It triggers lossless compression mode automatically. The range is 0 (maximum preprocessing) to 100 (no preprocessing, the default). The typical value is around 60. Note that lossy with -q 100 can at times yield better results.

I evade taxes daily

like buying food

<:trollhq:1116404564007080067>

https://tenor.com/view/giga-chad-gigachad-big-gif-21053844

The metric for WebP in this test looks questionable for me https://www.ctrl.blog/entry/webp-vs-guetzli-zopfli.html

And it seems that the author confuses with how those encoders really did

Wait, does the author assume that webp qX is the same quality as guetzli qX or libjpeg-turbo qX?

Coincidentally I tested some lossy WebP results yesterday and its q88 was closer to JXL d2.0

Yes distance 2.0

the images should always be included. it was a huge eyeopener for me seeing what the appraised ultralow filesizes for another format actually represented (unusable quality levels far worse than what wouldve been tolerated with jpeg)

I found it as I was seeking some reviews about WebP near-lossless. But `-near_lossless 98` in that isn't quite meaningful at all

I could say Jpegli could be even better than WebP near-lossless in terms of compression ratio

This makes the use cases of WebP near-lossless significantly fewer

Not specifically near-lossless, but https://giannirosato.com/blog/post/jpegli-xyb/

Yeah this is where I know that Jpegli supports XYB

Visually lossless is a better word to describe the high fidelity qualilty range.

Which is something WebP can't do well, even Jpeg blows it out of the water

But the function of near-lossless is part of WebP lossless and the author recommended using it for normal cases

Based on my little test, the use cases would be significantly narrowed down to -near_lossless 60 or 80 when the image has Alpha

oh yeah I forgot images with alpha <:WebP:1279637593868210368>

is jxl good for animated images (medium quality, literal video ported as an image for web uses)

or should i use avif

I thought animated AVIF was just an AV1 video

If that's the case, definitely AVIF

Oh it's apparently not exactly the same, but it's close and does use a lot of the same interframe compression

it's pretty much 1:1 with some extras tacked on

IIRC AVIF *was* distinct, but a while back they just said screw it and allowed normal AV1 payloads

only for a brief time during the v 0.0.whatever phase

at first it was somewhat ambigous, then they said they wanted it to be limited down, then a month or two later they said they wanted a fill video

The only interframe compression JXL can support is copying segments of previous frames over to new frames, and it can do so using blend modes, so you can for example store new frames as the residuals of some blend operation, to effectively get lossless (or lossy, with some more constraints) interframe video compression. You could theoretically even do some motion estimation for pan and tilt by patching the previous frame or segments of it to a different location in the next frame instead of to the exact same location, but you'd have to write an encoder that does so first. Currently the encoder attempts no interframe compression at all

I think JXL would be a pretty good fit for for example animated pixel art. Instead of storing every frame you just store the parts that move for every frame and patch copy them in

the answer is maybe one day jxl will be good for this ™️ but for now, just use avif

that's what I was looking for

Use the video format for video

for lossy video, av1 or any other video codec is much more suitable than jxl, which is a still image codec.

jxl may have some video applications but not web delivery of video. It could be useful as a mezzanine codec for lossless or very-high-quality intra-only video, where you'd currently maybe use ffv1 or prores, or j2k. It might also be useful for very specific types of animations that don't benefit (much) from inter frame, things like slideshows or some kinds of animated illustrations, or low-framerate stuff. Maybe for cinemagraphs it would also be more suitable than video codecs. But for the bulk of the web use cases for video, from short looping GIF-like meme videos to netflix, video codecs are the way to go.

Are there any good lossless video formats that support interframe compression?

You could use h264/h265 lossless

When significant lossless interframe compression gains are possible, x264 is probably the best option. x265 compresses worse, only reason one might want to use it is because lossless H.265 can be hardware-decoded, or because 12 bpc is needed.

x264 is already well optimized with default settings for lossless encoding, but x265 is not.

How fast is x264 lossless decode?

it's definitely not bad...

I can do a quick benchmark, actually, have some files lying around

ffv1 for reference

also, 10-bit hardware decoding is more widespread with H.265, isn’t it?

although sometimes only 4:2:0

Yes, very correct. However, for lossless, this makes no difference as H.264 uses its own profile for lossless anyway

whic is not supported by hardware decoders anyway

oh, right, somehow I missed the very first “lossless”

my brain just outright ignored it: “when significant interframe compression gains are possible”

but yeah, considering hardware decoding, I always wondered if H.265 might not be one of the very best options for beyond-transparency intermediate video encoding for editing and stuff

I would never use hwdec for video editing

like, at all at all

hmm, why

not reliable enough, hwdec can have corrupted frames, bad color rendering and all sorts of weird issues

preview is not export

no, but if you are doing any color work

well, why would there be issues...

color management is not part of the hardware decoder

because they can, and will, just straight up mess up rendering

how...

there are lots of potential stuff, for instance some gpus like intel igpus need to use some gpu processing to decode the stream properly which includes float math

some nvidia cards just straight up crap themselves on some x264 streams too

To be fair, serious colouring work would probably not be done with h264 video

you would be surprised, a lot of HQ video gets imported as h264. it doesn't always make sense to transcode to a mezzanine

I don’t remember any such issues editing H.265 footage from my camera

h265 is heavy AF which makes it a pain, editing more then 4 tracks cripples my PC lol

yeah, my desktop struggles a bit speed-wise sometimes

much smoother on my macbook pro

I assume you get hw decode for h265 on a macbook?

I would assume so

Reminds me of No Man's Sky's website again... Dozens of videos playing at once, 8K images... Eugh

lol

Yesterday on macOS I accidentally found that "lossless" JXR produced by jxrlib, isn't really lossless

I'll check on Windows as well

Well winget even doesn't include jxr

These settings (except Quality) for Jpegli can let XnConvert export the JPEG file exactly identical to what `cjpegli` produces by default

e.g. this exports the same as `cjpegli -q 96`

Not open-source however and it's free for non-commercial usages only

Yeah, that looks right. Though thinking about it, maybe subsampling should be changed based on this chart (At least for XYB). Then it *should* always beat WebP if not also AVIF

Hmm I just tried for the exact same result (verified with ssimulacra2)

Non-XYB has much smaller gains, but 4:2:0 to 4:4:4 could still be an improvement

You mean with XnConvert and Jpegli, or the graph I posted?

XnConvert vs cjpegli

Ah, yeah

Tried building jpegli on Windows but it was extremely troublesome comparing to macOS

Found the solution: Add `-l 0`

> -l overlapping 0: No overlapping > 1: One level overlapping (default) > 2: Two level overlapping > (if not set is One for quality >= 0.5 or Two for quality < 0.5)

XnConvert produces slightly different sizes for other formats like JXL and WebP. Because of older encoders?

The updated `cwebp` script for Windows .bat that can append the input file's modification time as the output file's creation time `@echo off for %%f in (%*) do ( cwebp -lossless -m 6 -q 100 -mt -v -progress "%%~f" -o "%%~nf.webp" powershell "(Get-Item '%%~nf.webp').CreationTime = (Get-Item '%%~f').LastWriteTime" ) pause`

Testing the similar mechanism on macOS as well

It's universal that other codecs including cjxl can follow too

I just don't and can't test cjxl on Windows

>not using sh pain

What

It's using CMD.EXE and powerhell

Quack's just complaining about that

Bourne/Korn shell is a little easier to use

I just use built-in features as much as possible for casual users

On some systems, /bin/sh is built in

On macOS I use AppleScript for it

Interesting https://youtu.be/7O9eKxH46ZE

We should buy that person a new PC

Use this now as the original with PowerShell would be flagged "Trojan:PowerShell/Timestomp.A" > `@echo off > for %%f in (%*) do ( > cwebp -lossless -m 6 -q 100 -mt -v -progress "%%~f" -o "%%~nf.webp" > coreutils touch -r "%%~f" "%%~nf.webp" > ) > pause`

Yes I made a Trojan horse

lul

But with copying and renaming it's fine 😏

The ultimate solution is using `touch`. Built-in solutions suck

touch is definitely the easiest solution, but does not support copying birth right, as you described earlier

Yeah I have to give up on the idea. Windows itself sucks at that too

`touch` can copy Btime on macOS however

which coreutils tho [av1_woag](https://cdn.discordapp.com/emojis/852007419474608208.webp?size=48&name=av1_woag)

This one. Is it all right? https://github.com/uutils/coreutils

yes [av1_chad](https://cdn.discordapp.com/emojis/862625638238257183.webp?size=48&name=av1_chad)

This is available on winget

[av1_woag](https://cdn.discordapp.com/emojis/852007419474608208.webp?size=48&name=av1_woag)

thats neat

I wonder if brush or rust-parallel are availible on winget

answer is no

coreutils uutils.coreutils 0.0.28 winget