JPEG XL

Which encoder did they use?

If it's VVenC, then it currently doesn't support lossless.

If it is lossless, I would do some investigation.

My bad, mpeg-1 was already a 'real video codec' with inter-frame coding tools. I somehow was assuming it was just mjpeg because mjpeg and intra-only mpeg-1 are basically the same thing, but mpeg-1 does also define inter-frames.

*Some* h.264 can be optimized by replacing CAVLC with CABAC, but as far as I know there is no available tool to do this

Oh, so it has a setting to specifically be better in testing

there are only encoded images on this forum link <https://encode.su/threads/3397-JPEG-XL-vs-AVIF?p=79987&viewfull=1#post79987> then i guess it's just q100 vvc, like some people compare avif or webp without rgb lossless modes with "amazing" lossless compression but i don't have vvcdec so can't verify

So no 16 bit colours or 16 bit 4:2:0?

`vvc (Main 10), yuv420p10le(tv)` yeah, looks like it's not lossless

most H.264 already uses CABAC though

as far as I'm aware

Now - yes, but there are many existing files and CAVLC is not really rare

What is stateless

that it doesn't need to be re-initialized (slow) when you change to video stream with different parameters

Google suggests this: https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/dev-stateless-decoder.html

<:ReeCat:806087208678588437>

Why are they still looking at psnr, ssim and vmaf? There is no such thing as a reliable metric for objective image/video quality assessment, but these 3 are particularly bad...

I think because there is nothing much better than vmaf for video from widely used metrics <@794205442175402004> maybe propose ssimulacra2 for video, to some third party comparisons? even if it wasn't intended for moving frames, but psnr or (ms-)ssim also don't take motion into account as far as i know https://github.com/Netflix/vmaf/issues/1133

Vmaf takes motion into account but it's an appeal metric, not a fidelity metric. You can make any codec look great by first doing some sharpening, contrast and saturation stretching, and then vmaf will say "woohoo this is better than the original!" even if it's a crappy encode

So absolutely useless to test encoder improvements, it's trivial to optimize for it (whether consciously or by accident) but correlation with actual quality can be pretty low

Previsions of AVM

Currently 27,41% over AV1

I analyzed the quality of partition

is there any way to losslessly add a alpha channel to a pre-existing WebP file?

I know I've seen that AV1 isn't coming to iOS 17 even though we have avif and jxl

But what is this?

<:thinkW:368319852060082178>

which one?

I assume AV1 codec

What are the max compression settings for cwebp lossless?

I'm using `-z 9` but I'm not sure what settings that sets automatically

`-z 9` = `-lossless -q 100 -m 6`

is there anything EXTREME

if I can run overnight

no, but sometimes something other than `-z 9` can work better, so bruteforcing from `-z 3` to `-z 9` on some images may compress better

how would anything other then `-z 9` compress better? with `-z 9` the lossless "cruncher" gets enabled which does this: "Go over the whole compression step for each of the transforms and pick the best one."

also I would recommend adding `-mt` which makes the lossless cruncher take around half'ish the amount of time with the same output/results

probably because `-z 9` does not use all possible options `-mt` only if it is a single image, usually it is easier to encode multiple images in parallel

is there a tool to inspect the structure of a jpeg file?

i have a jpeg that is compressed to roughly 43% of its original size with jxl lossless recompression, and roughly 50% of its original size even with gzip, so i assume there is a lot of "dead space" or something inside the file but i'm not sure how to find it

<https://raw.githubusercontent.com/190n/jxl-fuse/main/originals/trails.jpg>

seems like your theory of there being a lot of dead space is right since there is a line in that file that contains 2,108,610 characters and only 43 of those characters aren't Space/NULL

at line 14715

oh, it's really that simple lol

now i wonder how that happened

this file came off a camera and hasn't been intentionally edited afaik, but it did migrate between a few different computers

Wonder if there was some filesystem corruption that listed the file being longer than it was

QOI is now supported by all KDE applications https://pointieststick.com/2023/08/11/this-week-in-kde-plasma-6-development-continues-2/

And jpegxl?

It's been in kimageformats for like a year now

Didn't know i'm more a gnome person 😅

https://tenor.com/view/seriously-really-wtf-wtf-is-going-on-norm-the-gnome-gif-19269788

Any details about AV2? When is it planned to be released? How much better and power hungry it will be in comparison to AV1?

8 minutes if you want to encode romanian girls at cpu 5

So very light

You need one hour to decode

One frame

It will apply 105 filters at cpu 4 and crash

But with a photo of my relatives it didn't

No plans. Until 2026, the format will not even be released, there is no point in it, the very fact that people are talking about it only knocks people down, panic is induced among companies that are just switching to av1 now. There is no point in talking about av2 until it is standardized, and this will not happen soon. Not soon at all. I want to say that av2 will by no means make the same leap as between vp9/hevc and av1. And even more so av2 will not be implemented HW at the same insane speed as av1

That is fun, there are still many years until the end of the development of av2, but they are already pushing what they are working on - in avif

Well, another aspect of av1 is now the best codec, the best of all competitors. It makes no sense to release av2 now, it will be a competition with ourselves (av1) But avif. A completely different conversation, just look at how avif lose to jpeg xl

<:JXL:805850130203934781>

Probably it is just nonsense to release without waiting a year aftee aom 4.3

Do yoy at least know when aom 4.3 will be out

We are at 3.7.0 rc1

I think 15 months

Plus another 12 for av2

AV2 is expected on September 2024

https://arxiv.org/pdf/2308.06570.pdf

Probably will be for 4K 5000 2500 and 760

Not very flexible when they will announce it

To be honest, I do not know why this codec is needed. Its computing power is so demanding that it makes it unsuitable for home use. And its decoding costs are so large that you can't do without a hardware decoder, just like in the 1990s during the first decoders of video accelerators, which were made for 1 codec....

They could indeed focus on the improvement of AV1 😄 ogg vorbis was fine tuned even years after it was out

https://www.androidpolice.com/google-photos-ultra-hdr-android-14/

why not just use <:JXL:805850130203934781>

Seems like not even AVIF is cutting it.

I think the goal of this is to allow HDR photos to be shared with older devices and still be viewed fine in hdr. the HDR part would be more or less an enhancement layer of sorts that would just be ignored by older devices

basically they're reinventing JPEG XT

JPEG XT's reference decoder is GPLv3-licensed though.

JPEG XT has a patent pool as well

unlike JXL and similar

I haven't like heard of any real plans to relicense it under an Apache license as well.

really? didn't know that

according to wikipedia*

this is what they cite

https://www.sisvel.com/news-events/news/sisvel-announces-the-launch-of-the-jpeg-xt-joint-licensing-program

https://www.sisvel.com/licensing-programs/legacy-programs/jpeg-xt/patent-owners

https://www.sisvel.com/licensing-programs/legacy-programs/jpeg-xt/license-terms

interesting

sisvel also has that for avif, right?

I don't know

they'll do all they can to go around jpeg xl ...

https://www.sisvel.com/licensing-programs/audio-and-video-coding-decoding/video-coding-platform/license-terms/av1-license-terms

*sisvel, we protect ideas* ... lol *we extort money" would be more suited

reminds me of Vectis IP with opus

Comment this: https://www.linkedin.com/posts/jan-ozer_from-codec-royalties-on-content-and-the-activity-7100890936968187905-8Wph

It's talking about AV2

I still believe that they didn't add JXL just to spite us.

Had they added JXL, it would have basically forced Chrome to add support for it.

It's not so simple. as someone who has worked with multiple android devs (though mainly bliss now) adding a new image support to android is really hard for two major reasons one of which avif was able to sidestep. These are not necessarily aosp's considerations but android is larger then just aosp devs in the end. 1. Backwards compatibility, this is still an issue with avif ofc. dont forget, android isn't apple they cant force update phones hat are 3+ years old. 2. the most important factor perf/security. Every single new dependency is a security liability to begin with let alone ones that the user directly interacts with. Not only does it need to be fast (which libjxl meets IMO) but security is an extremely massive concern. AVIF wins here simply because they already needed to include av1 decode (though aosp uses either libgav1 or libaom for decode, many roms are using dav1d anyway). Dont forget, android isnt like apple and cant just shove security patches down everyones throats (yet). with 1 of 2 major issues dealt with it becomes a LOT easier to sell avif. I think JXL will come to android, but I doubt it will happen until a16+

There is just so much risk when it comes to adding any new user intractable library its very much an uphill battle

who knows, maybe jxl-oxide might be an option thanks to aosp's love affair with rust, no idea. all I know is that it's a lot harder to get something into aosp then it is chrome

jxl oxide is faste in vadct and lossless ansocing

vadft i have th doubt

i can't wait to update sasha puglin to do libjxl in the windows os

<:kekw:808717074305122316>

They added something like JPEG-XT into Android, and not JXL. That argument would make more sense if they didn't add anything.

indeed it looks like a joke

all the new ultraHDR stuff is, is an xml metadata payload and an additonal map image for inverse tonemapping

basically no new tech was actually added

its effectively the three image HDR android already does compressed to two images and not processed

stupid regardless IMO but whatever

how does it handle the 8-bit limitation on legacy JPEG

Yeah, but no HBD.

Im not entirely sure it really effects them since they are using the data from both images. using both images may be able to represent data depths greater then 8bit. that being said, a multi channel image is possible but the document assumes a single channel luminance gain map

I doubt it will be *as good* as a 10+bit HDR image, but the goal is to be *good enough*

not like you can tell the difference on a 6" screen

well, android is used on a LOT more then just phones

but for most people it's just phones and this format is for phones to phones

its use case also involves tablets and the every growing chromebook market

not like you can tell the difference on a 12" screen

lots of larger chromeboosks, and I also forgot android TVs which are quite large

sure for the 5 people that use them

most people can't tell they're using a 6bit display

most people have iphones anyway

chromebook is one of the largest growing markets for dedicated computers, and android TV/boxes are are largely popular

nobody even has dedicated computers anymore

largest growing is also misleading

like don't 90% of those sit in a closet or in a landfill

they need to be stopped

not really, chromebooks are gaining popularity a lot, for older folk I really like them for sure, fleet PCs are also a strong market, desktop/laptop market is still strong

i myself am actually really happy with chromebooks from a usability perspective for normal folk, just wish they had flatpak support or something like that so we dont need to use the linux vm

all the older folk i know just use iphone

ok?

so all older people use iphones?

I dont know any old folk that use an iphone , or any apple product, doesnt mean that no one is

my issue with it is what is the point

?

two 8-bit images has effectively 9-bit depth fwiw

not really 16-bit

because one of them is just a stretch map

this is objectively false, iOS has less than 30% of the mobile market share

android-based OSes are ~70%

Q2 2023

https://www.statista.com/statistics/272698/

W thinks HDR on mobile is pointless, since "nobody can tell the difference"

yeah, it's not a lot of gain, but the goal is in the end to be "good enough" I think the solution they apply should be more or less good enough. here is the equations specifically used for rendering the final HDR image https://developer.android.com/guide/topics/media/platform/hdr-image-format#use_the_gain_map_to_create_adapted_HDR_rendition

ofc the app will still likely need to apply pq/hlg itself after since `HDR(x, y)` is linear

ofc it wont ever be as good as a dedicated proper HDR image which could contain proper amount of bits and other forms of metadata but it is what it is

ofc it's not like you can't do 8bit hdr so long as all you care about is contrast.

8bit HDR with a PQ curve can cause issues

hence the only care about contrast part

I may or may not have in the past, when asked for an hdr copy of an image I produced, simply taken the 8bit png i sent them, tonemap it up to a good value, applied pq and shipped the resulting image xD.

the gain is encoded logarithmically from what I can find, so in a way, isn’t it a form of 16-bit floating point?

16-bit floating point with an 8-bit mantissa isn't really fully 16-bit depth tbh

that's bfloat16 right?

but the exponent, is it shared between R, G and B or is it separate?

per https://developer.android.com/guide/topics/media/platform/hdr-image-format, it seems that 3-channel maps are supported, but they recommend “Use a single-channel gain map whenever possible.”

doing it per channel probably hurts compression too much

well they are gluing a full jpeg with another jpeg, multichannel or not, im not sure they are too concerned with size.

not in the US and only the US matters

not because HDR is pointless but because nobody can tell the difference between hbd

but also HDR is pointless

iOS is less than 60% of the market share in the US, a far cry from "everyone uses iOS"

phone market share vs device

I wouldn't call ~55% "most"

some stats say 80%

well those stats are wrong

Yeah and 1 gagillion devices run java doesn't mean that 1 gagillion people use java

that has nothing to do with what we're talking about

I'm obviously joking about the iPhone part

well it wasn't obvious to anyone here

https://css-ig.net/pingo - seems like Pingo 1.x was released this year. It's an advanced optimizer for PNG/APNG/JPEG/WebP. It's fast and produces small files with good quality or lossless 🙂

Looks interesting

Tried it, and was impressed by that it does lossless jpeg compression, since I'm unaware of any other program that does that lol

How does it compare to cjxl?

I can do some simple lossless tests tomorrow and share the results

does it still output a JPEG?

if so I'd bet cjxl is still ~15% better

pingo uses mozjpeg to do it, you can use jpegoptim and jpegtran to do it too

It just uses mozjpegtran for that...

hmm :- |

Here are my results: https://positron832.neocities.org/blog/pingo-vs-cjxl/ and <@179701849576833024> yes it still outputs a JPEG

Thank you for your work! Cjxl remains a super jpeg optimizer 😊

but jxl isnt jpeg

yeah, also cjxl can be used after pingo optimization and pingo uses modified mozjpegtran from ect

Is there any file size saving on pingo optimised jpg vs normal jpg after jxl transcoding?

Probably not

i get small savings on certain files, but haven't compared more recent versions with some changes in jpeg transcoding

Then in the next update Pingo just turns everything into JXL

https://chromereleases.googleblog.com/2023/09/stable-channel-update-for-desktop_11.html

based on the bug number, the relevant commit should be: https://github.com/webmproject/libwebp/commit/902bc9190331343b2017211debcec8d2ab87e17a

Cpu 8 AV2 enables 100 filters

With cpu 1 there are 90 but lot of edge filters

Still less than the average Instagram picture

Yes

Flip & IDT CCYX TX 6F

Those are Transformers for cpu 1

Will also slow down decode

Then there is an optional settings MSERI3

But it can't be used because decoding impact is absurdly

I need to try it

Mask compound one side compound snoothIperintraframe

Adaptive

Msrls

Flexible MV precisions

Tip

Those are slow tools

The edge filter also slow at the start of an image

12 seconds for 600x600

SmoothInterIntra Adaptive MVD resolution and Joint MVD coding are all slow together with also the PEC and bawp

Lot of cpu usage

In a merge request

https://gitlab.com/AOMediaCodec/avm/-/merge_requests/849/pipelines

This is probably contributed by Apple

I can see the slowness

https://www.opennet.ru/opennews/art.shtml?num=59746

Google has published an update to the Chrome browser 116.0.5845.187, which fixes a critical vulnerability (CVE-2023-4863) that allows you to bypass all levels of browser protection and execute code in the system outside the sandbox environment. Details have not yet been disclosed, it is only known that the critical vulnerability is caused by a buffer overflow in the WebP image format handler. The vulnerability allows you to execute your code when processing specially designed WebP images. The danger of vulnerability is aggravated by the fact that a working exploit has been identified in the network, which is already being used by attackers to commit attacks (0-day).

.

TIL: chrome has a dimension limit of 32768 pixels for avif images

avifenc can generate a 40000x100 image just fine, but then avifdec cannot decode it and neither can chrome

It also limits the maximum image size to 16384x16384. https://github.com/AOMediaCodec/libavif/blob/454adbf5c27d24e1645cae53c1c659d46e07f657/include/avif/avif.h#L71-L76

yeah but that is sensible, that's about the total number of pixels

For 32-bit systems, the image size in dav1d is limited to 8192x8192 (Chromium no longer uses libaom for AVIF decoding). https://code.videolan.org/videolan/dav1d/-/blob/8b419c16bf1e37bc98044089da58f06824462cb9/src/lib.c#L197-206

256 megapixels is a lot

but something like 40000x100 is just 4 megapixels

still doesn't decode in chrome

it's not the dav1d limit that is a problem, it's the libavif one here

already at the ISOBMFF parsing it aborts decode because the width is above the dimension limit

On 32bit system, libjxl can quickly fill memory with too big images too. It is good to have some reasonable limits.

yeah, just unnecessary to limit width and height, just limit only nb_pixels

it's buffer size that matters in the end

The other day I was in a voice channel on a server playing a game, streaming it, and tuned into a friend streaming their work. I noticed I was lagging a lot so stopped my stream, then my game and opened up task manager. Turns out Discord was using over 30% of my CPU, because the friend was streaming in 4K and has a 4090, so discord automatically used AV1 even though I don't have HW decoding. There was meant to be a h264 fallback when someone without hardware starts viewing, but I guess either it failed or it doesn't work in the first place

are you on windows by chance? I might be possible if you have the av1 codec installed that might be triggering it?

weird but I wouldnt put it past discord to mess that up

Chromium does not use system side codecs except Microsoft Edge

I also manually turned off AV1 in discord's settings, seems they just never bothered with the fallback

this is not true, chromium supports mediafoundation for decoding

also doesnt chrom{e/ium} now supporte HEVC via system codecs?

Yeah, it's supported using hardware for quite a while, namely H265/HEVC which I've been using for about a year

mediafoundation allows both software and hardware codecs, IIRC chromium allows you to use both

it's quite possible discord would check mediafoundation support and call it good

I believe AI can improve compression, but I doubt a bit 5x, let alone 50x in a near future.

I think 2-3x better compression can be done with AI codecs, but imo it comes at a significant cost: - could be risky for "atypical" pictures with content outside what was in the training set (either it doesn't compress well, or it hallucinates stuff) - significant computational resources are needed (memory/storage for the model, processing) - works best for low-fidelity high-appeal (very low bitrate, still looks plausible) but gains drop when going to higher fidelity - no fidelity guarantees, which is kind of going in the other direction compared to trends like the Content Authenticity Initiative (C2PA /JPEG Trust etc) — people want to be able to _trust_ digital photos, and putting in any generative component (like AI codecs) in the trust chain is probably going to be frowned upon.

I see more future in an AI-based encoder that targets a classic codec but mostly does things like better entropy coding heuristics where the effect on quality is zero or containable.

Influencing the decisions of a normal encoder rather than trying to remake the image entirely

jpeg xl + AI encoder ≟ <:Stonks:806137886726553651>

What about an ai for dividing an image into multiple layers to make it easier to compress, a la djvu

That could benefit jxl

Or an ai to determine the most effective algorithm or strategy to use depending on what kind of image it is

Think like opus

A model can guide the encoder on what tools to use

if you accept to have a 140Gb decoder, you can try to shave some bytes with this kind of research : https://arstechnica.com/information-technology/2023/09/ai-language-models-can-exceed-png-and-flac-in-lossless-compression-says-study/

You can have a lot of compression with AI if the content creator used the same AI to initially create it, like even millions of times more. If just usual data AI can be ~2x more dense but take 10000x more multiplications to decode. Reducing the number of multiplications makes the gap smaller. Similarly, adding more compute to traditional methods improves results there, reducing the gap.

https://nitter.net/MishaalRahman/status/1710037659786097106#m thhis is neat > Google Camera on the Pixel 8 not only saves photos in the new Ultra HDR format (JPEG_R) introduced with Android 14, but it also adds support for Display P3 capture! > > Display P3 wide gamut capture is a new capability of Android 14. Devices can capture wide gamut color images in JPEG format without using 10-bit HDR. > > There's apparently a setting in Google Camera on the Pixel 8 to opt out of wide gamut capture, whereas Ultra HDR captures are always enabled. > > Thanks to anon for the tip p3 photo support

is P3 the default?

or well wide gamut I mean

I assume it is based on the wording of "opt out"

that is a question I dont have the answer for

I hope that comes to older Pixels

Anyone got a list of video formats that support transparency?

**hevc/h265** displays alpha transparency in safari but not chrome **vp9** displays alpha transparency in chrome but not safari things might have changed since, but thats how it went with web browsers. unsure about local video players

as formats more suitable for video editing, you got **Prores** (limited to apple's ecosystem) and **DNxHR** (available for windows/linux). their 444 codecs in particular preserve embedded alpha information

so vp9 looks like the best play then

does AV1 support transparency?

not in the bitstream afaik. the containers av1 is used in need to support and expose that

do note its most common to just use transparency masks rather than actual transparency (always problematic to encode, limited support everywhere)

Gotcha

are there any other image formats that support having compressed metadata?

like for example does avif have anything like jxl's brob box?

png can use DEFLATE for metadata

other than that I don't know any examples

JUMBF (including e.g. C2PA) is probably going to allow `brob` content boxes, which will be a way to get compressed metadata in any format that supports JUMBF

320k opus seems a bit excessive

Yesterday builds 12 oct with fdk aac

Ffopus just guessed not complete

meme

lol

||I say, myself a hollow shell of a person.||

my friend got backwards experience. he would spend hours trying to configure vlc so that it didn't jolt the whole system when switching tabs. then I recommended mpv and in 5 minutes everything just worked and he could finally watch the damn video without any configuration.

I use both 😮

I use mpv so that at least, it’s colour-managed and I can enjoy the content without being distracted by gaudy colours

the only mpv configuration necessary for that was `icc-profile-auto = yes`

(I also have `keep-open = yes`, and the following `input.conf`: ) ``` WHEEL_UP ignore WHEEL_DOWN ignore ```

my mov config isnt to wild, mostly just some basic stuff for disabling vsync and somewhat decent hdr handling

(that's me btw. Please consider joining!)

(also me!)

Hey guys, pay us for this free thing

i actually hold a patent on a process for how to best come up with, file, and shake people down with dubious patents so every time these leeches pop up i get a kickback

Good lord AVIF is terrible

cant believe anyone would wonder why large resolutions are even in use

people still scan to file or email images (like with now defunct google's cloud print) at more than 600dpi and work with highly detailled image files they may just need sharable across the web with less artifacts and a workable filesize

Assuming I know what comment you're referring to, they're asking why you'd use AVIF for large files, since it can't preserve the quality properly for most workflows

Large files usually don't have much fine texture worth preserving

Is it just me or is AVIF lossless completely useless lol

it's not supposed to be used like that

<:YEP:808828808127971399> frequently loses to png

Lossless AVIF is still broken in WIC.

what is this, I've encoded way bigger images to AVIF?

depends on the speed

Speaking of speed, what about FFV1?

*WebP.

I've never seen it lose to PNG on my images.

They might mean optimized PNGs, they can go roughly 30% smaller than normal in bad cases (I had a few color masks go 98%)

I always use the smallest available PNGs for that of course.

lossless aomenc is generally pretty bad at cpu-used > 4

but I also doubt it'll ever lose to webp at cpu-used 0...

even jxl loses to webp sometimes in the lossless case. lossless webp is actually quite good

really...

I mean, I know it's very good

yea, plus the libjxl encoder isn't perfect. lots of room for improvement

afaik jxl lossless was heavily inspired by ffv1

modular mode comes from FUIF and FLIF originally

which in turn is inspired by ffv1

so yes but through a level of indirection

yeah, I know, I follow this since FLIF

earliest days of my deeper interest in media coding

They've wanted to take the pallete ordering from WebP and apply it to libjxl, since that appears to be making most of the difference currently

makes sense

Been on the backburner for a few months now I think

according to caniuse, Edge apparently stopped supporting av1 and avif even if you have the av1 extension installed. anyone knows more about this ?

I sent a feedback as av1 is not working in linux edge. They said the upcoming build will fix the issue

though Theora has never been a widely used format https://bugzilla.mozilla.org/show_bug.cgi?id=1860492

https://chromestatus.com/feature/5158654475239424

doesn't wikipedia use theora or am I remembering wrong?

oh I just looked at the bugzilla page and they mention wikipedia

Oh if only they understood bitrate...