JPEG XL

that is the state

i was timeout on the seve

cause of my wifi

i keep eloading fiefox

and phones and disconnetting

while i was even connected to all the two

Honestly i don't gaf about Linux

I do like buying compyters while i want to like to please reddit to please English

I do not have passion I can't game

Also my music taste is far from great

And i never had froends in my life

Plus i have everything thats Linux

To me av1 is Windows and autistic thing

And i do not accept other opinions

Is like a thing to please English that i should do instead of praying god

Im not ashamed of That

Im in the server from 4 years and half

And reddit from 26 november 2017

So im an absolute expert i know everything

And i download everything i want

Qencoder is bad

I choose like two things if i can

I want to suncronize shazamed songs but i do not have any patience

I go in a server an type and copy whatever information i like

I download what i want

I do not spam since many year

I do not pay for a service

My ram in computer is screwed

Me if i go out in evening i can't even open the eyes im one of them

I got nervous and excited

Now 16:42:56 i take syrup

Probably at 8 second take valproic acid in my body

I do analysis to check that

Now im doing diet with subliminal

I do not know what are my liquid nothing

I change font five times a day

........

I gone to trips without any passport

Then use gamma binaural beat then not using and throwing every shit possible

And becoming fatter

As my parents bring lemons to my teachers

The pronunciation of downvotes don't make you more intelligent

I havent Logic, schizofrenia isnt logic

Ableton live is logic

Listen to 198 binaural at a second to calm you isnt logic

I think the same last thing even after 3 month

People don't think an object in the same way even after 3 month

I know about CAE Dynamic content optimization

epic blog tbh

try 5-htp sometime

They added more space in r/place

Can we put JXL at location 1024,512?

``` X X X X X X X XX X X XX ``` in turquoise

but who is going to maintain it?

We have a J

may be run a bot or something to maintain jxl logo 😆

I think there's a script on github for that

J is under threat

What is that thing on our left?

idk. probably they will claim that rectangular boundary

Maybe we can negotiate to have jxl on a black background there

Getting close

We can make the white black

it is them

Why?

Isn't that supposed to be black?

Looks like they want to draw something there

Is there another spot we could claim?

11x5 pixels is enough

Yes. There are lots of useless drawings and scribbles on right side.

<@!853026420792360980> Thank you for the help with the ffmpeg/mpv stuff 🙂

yw :)

One Japanese blogger wrote that webp is better than avif. They used 0xC0000054/avif-format plugin for Photoshop. https://momlove-fantasy.com/webp-vs-avif-which-one-is-really-light/

I think current av1 lossless can't compare webp lossless at this moment, but av1 lossy 444 will better than webp lossy 420, and av1 palette prediction can handle some edge case(DCT worst case).

The button on the left side to enter, the button on the right side not to enter.

Thanks

is lossless AVIF always so embarrassing

when does lossless AVIF shine

animations?

Never

not even when animated?

Idk about animated one.

would be fun to test that, but firefox doesn't animate AVIFs for some dumb reason

and libgdk-pixbuf doesn't support avif (at least not merged)

Do you know to make lossless avif animations?

yeah

i made one

or two

i think i did it correctly

take the yuv output from ffmpeg and pass to avifenc

What about RGB

I think lossless was a 'checkbox' they felt they had to tick in the avif/av1 feature set, but I don't think they ever intended on actually making it compress well

so lossless avif is never a fair comparison

and that's fine

PNGs will be with us for a long time

and still does great

does avifenc allow that for animations?

i believe it specifically wants a yuv format

Y4M

Idk. I stopped using avif since last year. I forgot everything about it. Probably it's possible to use ycocg-r and RGB by using a separate experimental branch of avifenc.

hardware AV1 encode (intel!) is something to look forward to

But hardware encoders don't to RGB lossless

and that's okay

i was only curious how well lossless animated AVIF does

The thing the shipped with Android 12 can't decode avif y444. I'm still angry about it.

or i guess just regular lossless AV1 video for that matter

Oh. I just updated to Android 12 L. I should test that again

I was testing AVIF a little and I found out that the AVIF extensions from MS Store are completely broken, displayed images are more or less glitched. In MS Edge, AVIF doesn't work at all.

Lossless avif animation can be created using avifenc (from libavif). You can have every frame in separate .PNG file and pass all those png filenames to avifenc via command line. My gimp-avif-plugin can save avif animation too, but not true RGB-lossless, only lossless YUV444.

libheif and libavif have plug-ins for gdk-pixbuf with AVIF support. The libavif plug-in can be improved to support avif animation if there is consumer demand.

how to set that up? package name?

`libavif-gdk-pixbuf` hmmm

the fedora package appears to be `avif-pixbuf-loader`

i will be sure to try it

On Gentoo: USE="gdk-pixbuf" emerge media-libs/libavif

As PNG was mentioned, I was testing animated PNG and I was not impressed. APNG doesn't support local palettes as GIF do, so many GIFs can't be converted to 8bpp APNG. Although PNG compression can barely gain any improvement on dithered animations.

I wonder which will get more interest from Mozilla, JXL or QOI https://bugzilla.mozilla.org/show_bug.cgi?id=1765908

doesn't fjxl beat qoi on efficiency and speed

Yes.

At this point, do people realize it perform close to on par with PNG? One problem with QOI is a lack of performance consistency, where JXL can work very well at.

what's the point of qoi for web

worst idea ive heard in a long time

Even png beats qoi in both density and speed (simultaneously)

Also qoi has no decent color profile support, good luck trying to do wide gamut with it in a consistent way

https://twitter.com/richgel999/status/1485976101692358656?t=hxN1ZkVLsBmJxYZ8zoGz_w&s=19

i feel like everyone asking for qoi support in software missed the point of qoi

maybe eventually tinyvg support in browsers could be interesting

tinyvg seems cool

How about [IconVG](https://github.com/google/iconvg) ?

that too

and no you can't embed links like that, unless it's a webhook message

yeah

phishing is already enough of a problem

or imagine

[https://www.google.com/](https://www.definitelygoogle.com/)

I remember seeing that one, the lack of text and image embedding is a bit of a weakness

Text at least can be converted to a path, but I can easily see reasons to want to embed small raster images

Can't you vectorize raster images by vector tracing?

Yeah, but current methods don't work super well for photographic images

Even future methods probably will never work well for photographic images

I mean of course if you add enough vectors, at some point you can just reproduce any raster image exactly (if needed using one vector per pixel), but it will be horribly inefficient in terms of both compression and render time, and there will be nothing scalable about it.

Lol

maybe in 2013

bpg never got out of the PoC stage, didn't it

Off topic spam nonsense promoting "Linuxism"

here's a screenshot xD

the desire to be a cult

https://c.tenor.com/assf_6gEdn4AAAAM/monty-python-and-the-holy-grail-head-smack.gif

vaporeon good pokemon kek

Hey, I already have some bash scripts for video (av1) and music (opus) compression. But i don't feel like there is a winner in the world of image codecs, so I was wondering what would be the best codec and/or parameters for images. The goal is to get a quality matching this output : ffmpeg -i a.jpg b.jpg (It is for gallery images btw) So I searched a little and found the jxl codec that seem efficient with large images, but I don't know if it "better" in what I am searching for :)

jxl is best for lossless, no competition

And lossy?

if you only do lossless then you dont ever have to think about it :^)

if your inputs are jpg, a jxl lossless transcode will almost always be better

Oh cool Ill do some tests Is there a ffmpeg binary with libjxl or do I need to compile it

anything else falls into the "it depends"

I think jpg recompression is only available in libjxl/cjxl right now

Okay thanks

Interesting lossy method. 🙂 > Image Compression with Singular Value Decomposition > http://timbaumann.info/svd-image-compression-demo/

linear algebra flashbacks

I test some different really non-photographic non-photo (anime) image on this lossy method, look like this method is better for photo content, I think delta palette probably a best lossy method for really non-photographic non-photo (anime) content.

I assume AVM is the verification model software for AV2?

the usual stages of software when making a new codec are like this: - Verification Model: experimental codebase to try out new coding tools etc - Reference software: bitstream is frozen, this code is supposed to produce and correctly decode valid bitstreams - Production software: code is mature, optimized and robust enough to be used at scale in practice

with libjxl we are doing all those stages within the same project, but that's actually rather exceptional

VM becoming reference software is not that exceptional, but usually it ends there, and production software is implemented from scratch or at least done in a separate fork

Looks like the worst flaws of Microsoft's AVIF implementation were fixed. The lossless AVIF now looks pretty good. However the colors are still off. I've used Gimp to create my test files and made sure all PNG and AVIF files (lossy and lossless) include the same color profile (sRGB). MS Paint still displays the pictures differently. Anyway, I just wanted to say that the implementation is not as bad as it was during my previous testing.

mspaint isn't color managed

That was a comparison, all tested formats has got the same testing conditions, so I expected they will produce the same output. I tested HEIC too for good measure. The colors were also wrong. Lossless HEIC didn't load at all for some reason. I guess the problem with color distortion is in the conversion from the video color space to RGB.

libopus is a good example of production and reference software overlapping. I find that it's more common for production and reference software to overlap nowadays

considering you have things like libaom for av1, or libopus for Opus, etc.

libvorbis is still the reference software for Vorbis too

as for AV2, the biggest issue I see with releasing a new codec every 2-4 years or so is longevity

if the goal is to replace legacy codecs, then you can't have such a short lifecycle

for video, I see av2 supplanting AV1, just like how AV1 supplants HEVC, but what I don't see is any of these supplanting H.264

not sure if libaom can be considered production software — there's svt-av1 that aims to be production-ready in the sense of speed, rav1e in the sense of safety, aurora is the one we

rav1e is, well, not good when it comes to quality/bbp curve

dav1d is definitely production software, tho

biggest issue with av1 I find is it doesn't scale well with threads, although that can be fixed by using a tool like av1an

and yes, the short lifecycle is OK for a small closed system like browsers + youtube/netflix, where it's not too hard to follow the lifecycle (and ditch support once something better arrives)

but not so much for longevity

TBF, the new AOM codec might just be getting started as an experiment, and still be 5+ years out.

still, the lifecycle of video codecs is pretty short

since h264 we've had vp8, vp9, hevc, av1, vvc, evc...

still none of those have been able to "dethrone h264" in the sense that they're not just better in compression but also as universally supported and able to reach a comparable encode/decode speed while still getting some gains

I just realized we have no VP8 emoji... guess it's not worthy of an emoji though <:KekDog:884736660376535040>

🇻 🇵 8️⃣

Good enough. Added it just for the memes, because apparently we had 35 emoji slots left

yea, a lot of users still rely on x264 cause none of the other encoders can match up to it when it comes to encode speed

if you have a newer GPU then maybe you can beat it with a hardware HEVC encoder but that's about it

(while also maintaining a reasonable quality and bpp)

And then there are forums like 4chan where people still use it... for whatever reason

When I see a webm on Discord: <:happy:853648793017778196> When I see it uses VP8 and Vorbis: <:PepeSad:815718285877444619>

vorbis is still like, the 2nd best audio codec there is, behind opus

Eh, AAC sounds better in my opinion, especially when you use CoreAudio

JXL is attempting to be like the "Opus of images" it seems tho

at low bitrates yes but at anything higher than, like, 48 kbps per channel, vorbis should be at least as good as every aac encoder

Really hope jxl succeeds in becoming the new general purpose image format. It's about time we get something that's good and can be used for basically everything

that isn't png lol

I don't believe PNG will ever be replaced simply because the overhead to implement it is so low

like there's PNG decoders in GRUB.

a bootloader.

Tbh, I often get annoyed by PNG not supporting 10 bit, but having to go all the way to 16 bit. For some things like flat art with a dark gradient as background 8b PNG just doesn't cut it

right but PNG being so primitive and widely supported makes it useful in a way that JXL can't do. like I don't forsee screenshots of your desktop being saved as lossless jxl, for example.

or your desktop clipboard being jxl

screenshots to file, maybe, but not screenshots to clipboard

Hm, don't know if I prefer LC-AAC or Vorbis for 96kbps stereo tbh. Vorbis sounds more open, but has more obvious artifacts and AAC sounds flatter, but doesn't really have the annoying artifacts

But tbh, Vorbis performed better than I expected <:KekDog:884736660376535040>

what's annoying is that discord does not embed `.opus` uploads but if you rename them `.ogg` then it embeds them and plays them fine

Yeah

And if you download .m4a files then it renames them to .mp3

And Discord doesn't allow a lot of characters in file names which is also annoying... including spaces

When encoding music, I don't go below 192 kbps. I guess modern codecs are doing very well at 128 kbps too. I personally didn't have a real need for encoding music in very low bitrates, unless you want to fit a whole song on a floppy.

Yeah, same for my usecase. 128kbps opus is supposed to be transparent, but I do 192kbps to be safe, and then my entire music library fits on my phone no problem.

If 128kbps is transparent depends a lot on the source tbh. Usually it's (near) transparent, but when there's a lot going on in the highs then compression can become noticeable

The short lifespan of video codecs is not good. Video playback really benefits from hardware decoding. However, before enough people gets the hardware supporting a certain video codec, there's another new codec and the hardware is obsolete.

I'm wondering why they can't add support for new video codecs to older GPUs by driver update. GPUs are capable of doing lots of things these days, not only graphics. Most video codecs are based on the same principes, so I don't think it would be too difficult.

Typically the video components in GPUs are dedicated hardware.

But GPU compute based video decoders could be cool.

GPU vendors want to sell GPUs, not spend effort in making already sold GPUs last longer

GPU manufacturers don't have to worry because they sell everything they can produce.

I guess something like OpenCL could be useful for it.

As that is cross platform, while CUDA is NVIDA only.

Or maybe SYCL, as that seems more modern, and Intel is pushing it hard with their oneAPI.

Certain components of vid encoding and decoding are very hard to gpu accelerate because they're highly branching

particularly things like CABAC which are expensive

Also, DRM!

So you can use GPU for rendering complex 3D scenes, you can compute physics and AI using GPU, you can use GPU for crypto mining, but you can't implement an arbitrary video codec on GPU? Unbelievable.

Yeah, but that's not how this works. There are lots of things where CPUs are just better at. There's also the fact fixed-function hardware like ASICs can't really be updated.

A lot of _parts_ of video codecs are suitable for GPUs, like transforms, filters, etc. Everything that has similar and non-branching computations per pixel or per block is great for GPU. Entropy coding is inherently branchy and sequential though, so better suited for cpu than for gpu.

If you want to do a full gpu codec, it has to be like the texture formats do it: fixed bpp per block

> Entropy coding is inherently branchy and sequential though https://github.com/NVIDIA/nvcomp would like to disagree 😛

(although in general it's true that at least *existing* image/video formats' entropy coders are not exactly GPU friendly)

Yes, I meant existing formats. You could design a format that avoids branching and sequential streams, to some extent. Probably does come at some cost in compression though, at least if you want to be able to do both encode and decode purely on gpu

Also what's good for GPU isn't always good for dedicated HW like ASICs 😛

The GTX 980 had a "hybrid" HEVC decoder, reused what parts it could from the H.264 decoding hardware and did everything else in software via compute

I'm pretty sure it worked so well that it was disabled via a driver update

Only for 8b.

10b was deemed too complex and demanding at the time.

Yeah, I never actually tried it much, but it wouldn't surprise me

I think to this day I've only seen like 3-4 HEVC files in the wild, having to pay extra for the decoder on Windows doesn't help (But VLC does)

HEVC was enforced by TV broadcasters so every TV has to support it to be able to pickup TV channels.

At least DivX/XviD and variants are finally dying out. This format was never properly supported in hardware. No wonder, it's a hacky mess. Even today the HW decoding is pretty buggy, especially on ARM based media players, and it's better to do in software.

Yeah I'm pretty sure our TV can do it, but any chance of actual broadcasts utilising it is years off

Main channels here (Australia) are still SD MPEG-2, HD channels are only 1080i

Here in the middle of Europe, most TV channels are in SD HEVC, they just have to pack as much ads in the small space as possible.

At least the audio improved a lot after switching from MPEG2. AAC sounds much much better than MP2 audio. MP2 was really awful even at 192 kbps.

I thought broadcast in the US was H.264 for HDTV but I'm not sure

SD I believe is still mpeg-2

In the UK SD is MPEG-2 and HD is H.264

in italy neve used aac the codec is e ac3

https://helpx.adobe.com/illustrator/using/whats-new/2022-3.html

Adobe Illustrator now has AVIF support

Not sure if it's a very useful export format for Illustrator. I would expect people to want to use SVG or PDF as export format when they have vector images, maybe PNG or lossless WebP if they really want it rasterized for some reason (e.g. because rendering the svg is too slow?)

On the other hand, for lossy rasterized illustrations, avif does manage to keep nice crisp lines...

I think probably full implement `more_patches ` improvement also can handle crisp lines from 2d drawing? I thought for still image use image codec always a good idea, use video codec replace other still image codec probably not a good idea.

For rasterized vector graphics, modular should perform quite well. My point was though that in a vector graphics authoring tool, I think the main thing you want is export to vector graphics formats (svg, pdf, postscript, maybe even html+css), not so much export to raster graphics and certainly not lossy raster graphics...

For 2d chart use modular and svg is a great choose, but I guess `Adobe` `Illustrator` creator also use `Illustrator` feature for create 2d drawing (also have hard and crisp lines). I notice some offical japanese manga jpeg and png image have adobe exif data...

I remember it was heavily promoted for anime/manga type illustrations as it does well with mostly straight lines and solid color filled areas.

Yeah, it does, if you don't mind the occasional rounding of line directions to the nearest directional prediction mode

For lossy raster illustrations it does work pretty well

But .svg.br should also work pretty well, and is fine for any viewport width

If you have vector sources, going to raster is a waste imo

It's like converting a video to gif and removing the original

Sure, sometimes you may need to do it, but preferably you just put svg on a website instead of making avif versions of it (for various resolutions, with jpeg and/or webp fallbacks, etc)

For storage, yes. For sticking on a website? Prefer JXL, but that's not available yet. <:SadCat:805389277247701002>

Most websites that let people upload content don't accept SVG.

& thats a good thing, last time i checked its still very easy to make xml bomb w svg

Yep, SVG can be dangerous - that's why so few places accept them. You can also embed javascript in them and if the software runs it, could potentially be dangerous.

Yes, for user-generated content it's maybe not a good idea...

SVG is nice, but it's too bloated to be used as a general purpose vector format. Writing SVG by hand was pretty fun though, kinda reminded me drawing in Qbasic.

I really hoping jxl lossy can replace jpeg and lossless can replace png for `really non-photographic non-photo`(manga, 2d drawing) content, butteraugli, XYB and patches,noise,dots features is really great for still image...

I'd hope lossless JXL could replace PNG for every use case

Agreed, using JPEG for drawings is dumb. PNG is showing the signs of its age and the compression is not great, especially for complex artworks.

I like a near-lossless(like webp near-lossless 60) version for network transfer, and a mathematically lossless version for cold storage.

I like ethereally lossless for communication with the dead.

VarDCT d=0.1 is better than pre-filtered and then lossless, tbh

since JXL has converging generation loss, recompressing files with VarDCT distance=0.1 won't cause them to get worse and worse and worse

well, it's not literally idempotent, there is still generation loss in vardct

in lossy FLIF I could make it literally idempotent: no amount of recompressing at various qualities would ever make the result different from what you had at the worst quality setting in the image history

but that only works because it's a lossless codec using integer arithmetic and more importantly there is nothing that can make errors spread or accumulate (no filters, no transforms even, FLIF is all just weird interlacing and fancy entropy coding)

d 0.1 is great, but sometime file size will large than lossless, I usually use d 0.3~0.5~1.0 e 8~9, but I think probably implement more improvement for non-photo content, can help reach transparency on d 0.5.

BPG, QOI, FLIF, - are good examples of the fact that without influence, simply by making a good product, absolutely no one needs it, except for self-sufficient closed systems

it's still converging though, isn't it? like there's a steady state where it will still be "worse" but it won't just stack up and become unviewable after any amount of recompressions, i.e. in the limit it reaches an idempotent value

isn't BPG basically just HEIF

oh no no no

as for flif, it was cool but it was way slower than JXL modular

unusably slow

well not unsusably but impractically slow

For starters, HEIF is a container that also uses the AV1 codec for AVIFFor starters, HEIF is a container that also uses the AV1 codec for AVIF

this is sad capitalist story, but HEIF for example for Apple is a 100% compatible keyframe with the HEVC codec, that is, literally, from a video, while BPG is the use of the same algorithms that are in the open source, but BPG is incompatible with the original HEVC

unfortunately no one has used BPG anywhere at all

it’s the same story with WEBP2, they just made him, and silently dropped, and, no plans are planned because Google is make up the avif and it makes no sense to support another codec WEBP2 from the very beginning looked to me like that, - "We didn’t want to upset the developers who made it," in the sense that it was clearly developed for this decade, and some of the algorithms were transferred to AV1 and AVIF, but, to tell the developers that all your other works - "the do in nonsensical, useless, wasted", and therefore it simply drop out the codec in such a state in which it is, nobody needs them and there will be no question of its support, because why? in numbers, it is no better than AVIF, and for the end user there is no difference that some of the codecs were encoded on the server side for longer, users would have to load the picture faster (or just can load/look)

I don't see how this can exist if the algorithms themselves are patent-encumbered

even if you re-implement them in a way that is incompatible with HEVC

again, did anyone support flif? maybe facebook? maybe a tweeter? telegram? google? at least some kind of noname danboru?

nobody supported flif because it was impractically slow and had very little gain over ffv1 (the design inspiration)

ffv1 was orders of magnitude faster than FLIF and provided more than 90% of the compression ratio

flif's main claim to fame was progressive decoding

just look at the discord that supports APNG for their animated stickers but can't make it support APNG as a file

that's because discord is LOL

discord is a big meme

when it comes to supporting formats

discord also doesn't play `.opus` audio files unless you rename them to `.ogg` and then it plays fine, despite using Opus for its voice chat

Thanks for you too

discord's supported media choices are not a good example

a few years ago i had the same problem in telegram, i had to rename all my files to .ogg instead of .opus

why do you keep posting the exact same message duplicated

Flif was just a fun side project that somehow blew up a bit

It got me interested in image compression though

wait, I thought that was something you did *because* you were interested in it

oh that's very funny because i'm not very good in english for real time speech, i use a translator and then i'll technically check the words, but, i'm use discord in browser, and you won't believe it, but if i switch tab to discord and first my action will be CTRL+V then it is duplicated, this is a very funny bug

is few weeks old

Chicken, egg, I dunno which was first

I hope I live to see the anime in 8 mb av1 which is already done in files

that's 360p

Ok wait wait, what?

Last I checked, it's the opposite.

AVIF use HEIF as a base for the container.

IIRC it's basically the same container

to the point where you can use libheif to decode avif too

I said this...

I'm not very familiar with Opus audio but this doesn't sound bad for 14 kbps. It sounds even better than MP2 192 kbps performed by local TV broadcasters. 360p is kinda low but it's sufficient for a phone, I guess. I wonder how much of AV1 video I could fit on a floppy. I might try it.

nono no no better use PAPERBACK on a 600 dpi printer to save 400kb of porn photos from the danBoru in Avif quality 360x Q 40 on an a4 list

It was fun

That's neat. Unfortunately I don't have a printer handy but I have a Windows 10 computer with an internal floppy drive, so I can play videos directly from it.

having this, I think there is nothing more useful than audiobooks in "CODEC2"

Literally speaking pages.

unfortunately I have not checked how it works in combination with the attached neural network LPCNet

but the examples sounded very, very good

for 2.4 kbit

Indeed, but this is more suitable for communication. i wouldn't like to listen to audio books in this.

BGP is and always was heavily patent encumbered, not surprising that it didn't catch on. QOI is just straight up not useful, not sure how it's an example of a good product.

BPG frames are just a alight modification of a subset of HEVC. It's not really any different from just using straight HEVC.

FLIF actually did catch on to some extent, but browsers didn't want it because of slowness

which makes sense - and also a lossless format is not that useful for browsers anyway

can decode bpg using hevc decoder...?

I do not know, but I know that the BPG spec is quite short, and seems to defer almost entirely to the HEVC spec on coding details, so at a minimum it should be pretty close. Might be close enough to straight up work in HEVC decoders, might not be.

it was possible to make less resolution and up quality of pixel, but then without neural networks or "madvr ngu" algorithms - it will be blurry pixels

in any case, Apple, and later Google, decided to use exactly "hevc compatible" algorithms, and not *work* with "some kind of noname on the Internet"

exactly HEVC compatible means you can use the same hardware to accelerate both.

this is also an argument, but implementation of the hevc key frame has a worse quality, than hevc photography algorithm, without losing Legasy, they to make compression better for "one frame only"

afaik bpg is just a compact header plus a payload that is a subset of hevc (where the hevc header is skipped since it is implied by the bpg header)

so can probably pass bpg to hardware hevc implementations, to the extent that those hardware hevc implementations actually support the hevc features that are used

e.g. most hw only supports 420 while bpg also allows 422 and 444

bpg is basically heic but done in a nice compact way

years have passed, and now it makes no sense to talk about bpg, because there is avif, it is better, it is free, it has the same problems as bpg, because it is based on a video codec

Am I wrong or is it the "lossless" mode of video codecs (AV1, AVC, HEVC) the same thing as JPEG at quality 100? There are still rounding errors due to conversion between color spaces, so it's not actually lossless.

AV1 is definitely truly lossless

(it can stick to RGB)

not sure about AVC or HEVC but I suspect they can too

JPEG at quality 100 has *more* losses than colorspace conversions AFAIU

(I'm not sure the DCT in libjpeg is truly reversible, and it certainly isn't *guaranteed* to give you the same YUV pixels back)

(FWIW, you could also do RGB JPEG, if you really wanted to ;))

Could test how lossy a q100 rgb jpeg is, I suspect a little but not much

I think all codecs since j2k can do lossless (actually jpeg also had a lossless mode but nobody implemented it and it sucks)

A pitfall though is that some implementations will not allow 444, let alone rgb, but only work for yuv420

This is almost always the case for hw implementations

All video codecs I know suffer from this: they can do lossless in theory, but if you want an interoperable bitstream that works on anything that supports the codec, you're stuck with yuv420

Sadly, yeah, especially on mobile.

On desktop, there at least exists HW support for 4:4:4, but it's still niche.

Even on my macbook I can only load 420 h264 and h265, including heic

When I export an image to heic using Preview, and I use the setting labeled "Lossless", what I get is an 8-bit yuv420 heic file

Considering AVIF, Gimp only allows to set the quality and bit depth, that's all. I couldn't find an RGB option in avifenc either.

For lossless, it is lossless, but don't bother with it.

From my understanding a q100 JPEG typically has all 1s in its quantisation matrix.

So the loss would be in rounding the fractional values.

But that should be quite small as you have 1024 levels for the DCT coefficients.

Interesting, avifenc uses RGB in the lossless mode, although I have no idea how to select RGB manually. And it is indeed lossless, however the file is bigger than the original PNG, so no gain there.

I'm surprised honestly. With separate avifenc through aomenc, I always get similar/slightly better performance than PNG through ECT.

I've tried a simple cartoon image and the original PNG was optimized using PNGOUT.

But there are the compatibility problems. In Microsoft's apps, the RGB AVIF is displayed all purple. And Gimp simply crashes.

I suppose that PNGOUT is pretty slow. The PNG compression is not very smart, so PNG optimizers have to brute force the optimal settings.

I'd open bugs 😄

also, avif lossless is OK for photographic images, but it will be utterly destroyed by PNG (not to mention i.e. webp) for nonphoto

That's right. Also for photos 4:2:0 or 4:2:2 is alright. After all, photos are always slightly soft.

the way to select RGB manually is to specify *something* as the cicp

typically 1/13/0

*clearly*

(i.e. `avifenc --cicp 1/13/0 whatever_other_options`)

This setting is not very clear to be honest.

indeed xD

Anyway, I'm not going to use AVIF myself, but I guess it might be used by HW encoders, where the use case would be mostly photos.

it won't be lossless anyway

That's right.

HW all-intra encoders for images 🤮

Get ready to see borders my friends 🙂

Not sure if JXL encoder on a mobile device would be much better with the limited amount of memory.

FWIW there's no real reason why it *has* to use that much memory

fairly sure one could cut it down by a good factor 4-6 with... some... pain

Or they could just do tiles.

still would take quite a bit of pain 🤣

Last I heard, Apple's "lossless" export option also isn't even close to a high quality setting. You get visible artefacting even if the in data was 8 bit yuv420.

I was testing HEIC a little just because it's available in Gimp, but I don't really care about HEIC. I think HEIC is a format nobody asked for and it just annoys and confuses users. Also web browsers don't seem to be interested in it.

Cameras are using it now though, so it's probably here to stay.

As far as I know, only one smartphone manufacturer uses it. But you have to always convert HEIC to something else to do anything with it.

I'm fairly sure it's more than one by now

I guess web services will support HEIC uploads but the photos will be automatically converted to something universal. IMHO reencoding photos from a phone camera is not a big loss.

Apple and Samsung both use it.

Alright. I guess they needed an image format to support those gimmicky features like HDR, but those tiny sensors will never be as good as a proper digital camera.

Even those sensors are good enough to capture more than 8 bits of dynamic range.

Both Canon and Sony are selling cameras with HEIC support.

Or you can capture 8 bits and get rid of the noise.

And yeah, if the camera can record 4K video in HEVC, the support for HEIC is a simple addition. Although I wouldn't use it.

Most android devices (in my experience) do have it as a option, but don't have it picked by default.

Having a high quality camera, I would consider using RAW and then export to 16 bits.

Phone cameras don't tend to be good enough for the image format to be the limit, but proper cameras really should use a raw/lossless format.

HEIC did cause quite some quality complaints (besides interoperability constraints) when Apple introduced it on their iPhones though.

But that's probably because they use a too low quality setting, HEIC could be better than what they do

Honestly, I tend to find that phones are better at converting raw sensor data into a nice looking jpeg than me. I reckon the same would be true with higher dynamic range content. But that requires the phone to be able to produce images in a format that can represent such things. Though ideally I'd like high quality JXL output rather than HEIC...

My suspicion is that Apple used PSNR to calibrate between HEIC and JPEG quantization settings, and hevc is a psnr optimizing beast

(but good psnr can still look like crap)

I guess you can have a blurry image and the PSNR is still good.

Can you send us the AVIF image which crashes GIMP? https://gitlab.gnome.org/GNOME/gimp/-/issues BTW. GIMP 2.99 has better AVIF export than old 2.10.x

I'm using version 2.10.30, so it's kinda old. I have to recreate the picture.

Weird, I tested two completely random RGB AVIF files, each of them crashed once, but now they don't crash anymore.

Even after reboot I can't make them crash.

Gimp 2.99 never crashed during loading AVIF.

https://css-ig.net/pingo

Seems like a cool optimizer for PNG and some other popular formats

They claim that they are fast and provide the best compression level

AVC also supports true lossless, with RGB.

I see. There's a nice table on the Wikipedia page with many features of the codec, but there's no mention about RGB, so I wasn't sure if it's supported.

Wow 7tv for twitch chat use the Animated Webp

https://cdn.7tv.app/emote/61433e7d962a60904864b0dc/4x

im create the little jpeg artefact

how did you do that? it seems not just AC corruption but something more directional.

yeah howd you do that

looks to me like the quantizer table changes each block

and the quality decreases in each direction as a function of the location in that direction

very interesting what you like.to be honest, I have a feeling that I discovered some kind of effect that no one talked about, but I also liked it

DZgas jpeg artefact effect haha

ok im just drop the Python code for this, and the essence of the effect is that I completely break the DCT grid by resize the image by 1 pixel

20 times on upscale and 20 times on downscale - I thought it was the best

deep fried effect

aka baked

only this effect uses only compression of the original image thousands of times without resizing, which means that the DCT grid remains untouched

oh no, this effect is even simpler, it just sharpens the border of the blocks

not at all what I did

mine is

Strong degradation effect with loss of definition

4x

looks like VHS degradation but for digital content

it for JPEG XL

very boring

jpeg and JXL

Can try with different epf settings...

Now I'm doing a comparison of the work of transparency and quality with AVIF and of course the result is extremely deplorable

although by choosing anime I already put jxl at a disadvantage

why does alpha with color 000000 take colors from other parts of the image, algorithm problems? I observed the same problem in WEBP

you can do --keep_invisible=1 if you don't want that

this is the original

by default when doing lossy, it doesn't care about preserving the color of invisible pixels, so it does some kind of blurring to make them compress better and to reduce edge artifacts

this removed the alpha without taking into account the actual significance

it doesn't work... i use СJXL v0.7.0 f2ea6da

that is, the function --keep_invisible=1 does not change the file in any way, it is identical in cache

<:JXL:805850130203934781>

epf 3

epf 1

epf 2 - some faster

epf 0

30x epf 0

40x jpeg

I just did this test for https://encode.su/threads/3397-JPEG-XL-vs-AVIF/page6 if this is a bug of the encoder, then I will not attach a file without transparency, maybe I think you will fix it, in general, it would be much better if it was by default, and without separate parameters, in the future I'm sure someone will bait to this, because that AVIF, even at the minimum alpha quality - does not have color artifacts of this type

well in avif you can do premultiplied alpha which just zeroes all the invisible pixels

(jxl can also do that but I don't think we have an option for it atm)

do you think it's an unreasonable assumption that when you do lossy compression, you don't care about the color values of transparent pixels?

probably for this they can stick a finger into the fact that the format is worse, although this is not so

just, if it doesn't matter, then why does AVIF avoid it? after all, the same WEBP also had extra unnecessary colors in transparency

Baked JPEG, fresh from encoder oven

completely different effect, only slightly reminiscent of

different goal, different essence and implementation

it is certainly similar, but only remotely, because Baked JPEG is sharpening and self-adding extra colors and effects

"baked" to me is all encompassing

and just means a mess

it's better to call the dementation effect

my

because the information is literally distorted and lost in multiple DCT transformations

probably because in avif, RGB and alpha are encoded in completely different av1 streams, so they probably just send the RGB to an av1 encoder, which will not know which of these pixels are transparent...

sounds like a loss of efficiency, but nonetheless

I guess when Jon complete more modular patches PR (better heuristic), probably can get better lossy result for anime content? > https://github.com/libjxl/libjxl/pull/1395

👌 well, if it's better... so far the net loss is 5 times compared to AVIF, which can be with the same poor quality as JXL but weighs 5 times less

for anime

well i'm not really interested in doing poor quality more efficiently, I'm aiming more at making d0.5 to d3 produce better and smaller results

Beating avif in the area of low-bitrate artistically smudged and smoothed versions of an image that have very low fidelity but good appeal (for their bitrate) is probably going to be hard. Not saying it cannot be done, but I just don't see the use case except pleasing those who like to compare codecs by looking at overcompressed images.