JPEG XL

Governments requiring people or companies to use Microsoft Word in order to interact with them is a similar problem imo.

Ok, that's another problematic thing. E.g. PDF 1.7 spec is freely available, but PDF 2.0 is behind ISO's paywall. Thus governments should refrain from using PDF 2.0, because it's not free and people shouldn't be reliant on proprietary software (e.g Adobe Reader) to interact with government.

At least in the case of jxl, we do have a FOSS reference implementation, which is actually a better thing than a spec, it's an executable spec. So it's not a huge problem in this case, imo, that the spec itself is paywalled (though I would still very much prefer it to be publicly available). But other ISO standards do not have such 'software' versions of them (not all ISO standards are related to software), or they only have proprietary implementations, and then a paywalled spec is a real obstacle.

https://news.ycombinator.com/item?id=26396767

In case of non-software, non-free standards they should be strictly avoided in law-making and interacting with government.

Some ISO standards are freely available at https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html – any idea how that set is determined and whether JPEG XL can be included there?

Original 1992 JPEG (ISO/IEC 10918-1:1994) isn't free, yet somehow it became de facto standard of almost all of the imagery...

If ISO doesn't want to change I'd rather not reward them with government funding. Instead I'd rather just see a migration over time from such standards organizations to others, like the IETF and WHATWG, that are better aligned with modern needs. Government funding tends to make organizations even more entrenched in their ways and less likely to adapt to future needs, which will hurt as needs continue to change.

Yep, I'd like to boycott ISO. We're already using lots of IETF RFCs, so it's already getting better than before. And government funding... Remember that government standard entities are now in ISO and pay membership fees. For me it's mind boggling that we don't have access to something out government participates in.

It is freely available via W3C and I think also via ITU. Just not via ISO.

ISO does have a somewhat unique position in that it has well-established connections to national standardization bodies (ANSI, DIN, etc etc) and all its standards are the result of a formal approval process where these national standardization bodies officially approve a standard. That gives its standards quite some extra 'weight'.

Things like AOM or even IETF and W3C are in the end just non-profit organizations that are a facade for adhoc coalitions of companies in a certain industry, which works well enough if that industry has an interest in having a common platform based on open standards (as is the case for the web), but it would probably fail just as badly as ISO if you would extend it to other industries where the business interests are different.

The ISO standardization process has many flaws but it also does kind of work. It's just silly that ISO as an organization is a private company that has to sell specs and charge people for being allowed to participate in order to stay alive.

> Part 1 can be downloaded from the W3 page and the corrigendum (which contains only patent information) from the ITU page. So unfortunately ITU didn't release it for free. But how did W3C manage to release this for free?

I think it became ad hoc standard in the internet already before it was standardized

ITU had it available for free for a long time, but ISO has been bullying ITU into no longer putting shared specs online

W3C luckily has their own copy and still has it online, that is, until ISO starts bullying them too

🇹🇼 https://ccc.technews.tw/2021/03/11/jpeg-may-be-replaced/

film blogger 🤔

But maybe it's translation inaccuracy

deepl version: > Video blogger Jon Sneyers compares a JPEG image with an AVIF image to test the before and after changes after 1,000 compressions, and the result shows that the JPEG has been completely transformed, while the AVIF is still brand new.

probably an equivalent of “youtuber” or something like that

Also a very common example of AVIF's huge gap from Jpeg is to quote a comparison from a Netflix blog that used a poor encoder for Jpeg and chose metrics such as PSNR and VMAF

> Pictures of hundreds of KB may not seem to be many, but when accumulated, the size is still very considerable. As if accumulating lots of quite verbose AVIF headers would help. <:kekw:808717074305122316>

Netflix Jpeg https://miro.medium.com/max/2400/1*rh9JLgQ25mS5vULoV4IpJw.png MozJpeg https://miro.medium.com/max/2400/1*Dx9OKXdS0e8JXDu9ukpa9w.jpeg

https://miro.medium.com/max/700/1*-_ul1ZleQu9Wko7HSRfbeg.png https://miro.medium.com/max/2400/1*rF-E4mqPLN8w07Z_JEjnCw.jpeg

I think that is partially to do with trying to make JPEG look absolutely wretched against AVIF and partial that they are willing to accept AVIF's loss of fine detail so they are trying to make the JPEG encoder loose just as much, but to do so it makes everything else looks awful - apples to oranges and an acceptance of lower fidelity.

I will die before mozjxl?

mozjxl will probably use AI to tweak coefficients, patches and all of that stuff

"Normal" algorithms are too stupid for that

Not sure there will be a need for a mozjxl besides removing metadata - granted if they find algorithms that produce better quality image at same or lower size, how is that a bad thing?

Nah, we need only some new math theorem to do perfect paches

You remember that tree patch I prepared?

We need THAT level of intelligence and we'll be able to compress pixel-art perfectly

Yes if you don't have the perfect math, thebperfect solution is always better then an ai, but we don't know it <:NotLikeThis:805132742819053610>

The strange thing is that Jpeg XL is not mentioned at all in the article (although it is even in Jon's video and is also a candidate for replacing Jpeg)

It's literally direct JPEG's replacement: JPEG XL's VardDCT is backwards compatible with JPEG's 8x8 DCT.

No other image codec enables directly copying transform coefficients

I see a few problems emerging: --> People who don't know of JPEG XL --> People who confuse the formats --> People who do know (or don't) but are gaining an Apple-like fandom to AVIF, even if they have not actually used it --> People who only accept formats that are currently supported by browsers & editors as if they are the only that exist

I wouldn't be surprised to find out that you can do that with avif, actually (not so certain because of quantization tables though)

And people who make conclusions from comparisons only on low bitrates

I think this article author don't understand jpeg xl(JXL) encoder...(chinese is my mother language) <:FeelsSadMan:808221433243107338>

But, given that some research for the article was done, judging by the content quite sufficient, it was very difficult not to know about Jpeg XL at all

I think they consider jpeg xl is a old format... in this article they compare AVIF and HEIF.<:PepeHands:808829977608323112>

The article seems to focus merely on what formats future cameras/phones will support, not the web. So it may be that they are confusing JPEG and JPEG XL and assuming they are the same. Granted, hardware can choose whatever format they want. But when the data hits the web it will need to be converted to a format that is widely supported (mostly in the case of HEIF since browsers are unlikely to support it). So the article seems less about format support on the web and more about hardware... but the web and hardware are two completely different worlds. In the short term AVIF and HEIF will likely become the major hardware formats. In the coming years I feel many will switch to JPEG XL unless AVIF's lossless and max lossy get better - especially with performance.

sorry but Jpeg XL is such a bad name

seam: old, proprietary, not innovative

pik-fuif would have been so much better, wouldn’t it

for normal images that everyone use like p+++ images

jpeg xl isn't good

unless you did like i did q 93.1 s 4 resampling 2

and you are willing to sacrifice a bit color definition and quality

or you do speed 9 for pdfs

new heuristics you still can do with fixed security commit

but don't know if jamaika has compiled it

jpeg xl need to have stronger upscaling options at lower bitrates

we spend a lot of ram for this jpeg xl codec, and we can't have moirè and color discolouration

please not use -s 4 and --use_new_heuristics

use -s 7 -d 2

and i'm not encoding any webp

so?

webp need first to be converted into png

JPEG XL isn't good the chinese is right

-s 4 and --use_new_heuristics aren't good

i encoded one month ago

with normal settings

for %i in (C:\Users\User\Documents\png3\*.png) do cjxl "%i" "%i.jxl" -s 4 -q 93.1 --resampling=2 --epf=1 --dots=0 --num_threads=2 0.3.2 commit 5175d117

this is the setting i used

that is super bad according to jon

but i didn't know how to compress the content

i don't think with new encoder it could look better

there is small improvement at low resolution

just try for %i in (C:\Users\User\Documents\png3*.png) do cjxl "%i" "%i.jxl" -s 7 -d 2

i trust quality q better

to re encode jpg quality is better

than using distance without looking at original image

d and q work the same

ok

i think with -d 2 currently it looks bad

-d 2 is heavy compression it produces like 60 kb images

with jpg you get 67 kb images

what image?

don't remember

but -d 2 is a bit of over compressed

it could work for images at good light condition

i don't think -d 2 can be worst then -s 4 -q 93.1 --resampling=2

no

that is the worst setting of 0.3.2

only dev know worse

-d 2 i don't know what q is equivalent

like you need the raw file to me but jpeg xl don't support raw

but in my opinion best way now is look at original and choose a quality or distance

or just don't compress dark images

or just use -s 6 -q 83.2 --new heuristics in 0.3.3

it should be good enough

and i think better for the type of image

obviously new heuristics cause some ringing

so i don't know better wait for newer commit

but for small images quality isn't that important

or I'M WRONG?

-s 4 -q 93.1 --resampling=2 VS -s 7 -d 4

also -d 4 is so much better then -s 4 -q 93.1 --resampling=2

But i did with 0.3.2

not with 0.3.3

so I

thanks for the comparison

jon has said is very destructive

anyway i don't think -s 6 -q 83.2 --new heuristics in 0.3.3

is destructive as that command

i don't understand the way jpeg xl overcompresses

--new heuristics is not ready, it is only worst

ok

why use -s 6? worst then s 7 same speed

but to have a jpg 67 kb and a jpeg xl 60 kb that has evident discolouration and some ringing

i'm sensitive to discolouration

is normal you cannot convert bad jpg to any format becouse new format try to encode jpg artifact

png i had

yes maybe it was a jpg 427 kb

jxl have jpg transcode for this

for normal photo actually normal heuristics is incredible

very good compression 88636 kb

also for drawings is better new vs standard

what are the settings?

and the commits?

newer?

yes but this isn't a real life scene

and also s 9 60 s 9 90 s 6 83.2

cjxl -d 4 --use_new_heuristics VS cjxl -d 4

i prefer s 6 83.2

can you do the same image

with s 6 83.2

i do not have original file

-d 1 vs -s 6 -q 90

you can't pretend a new heuristic to be good on all cases

is worst in all case

they don't work on it yet

but to me at certain quality it looks transparent

s 9 q 60 too much

s 9 90 not good

s 6 q 83.2 very good to me, but it tends to look sharper than original

like they have potential to improve

s 9 q 90 vs s 6 q90

s 9 q 90 is smaller

normal settings?

but q 90 with new heuristics means that your source file is not good

like for webp images i would not re encode even with newer versions

jpeg from mozjpeg don't look bad as you think

why? new heuristic is just bad

yes i think

because is like you re encode opus with lossywav

is something nosense

mozjpg is very good, but low size jpg not encode well in any format

ok

mozjpg is better then webp in some image

do you like webp2?

mozjpeg in jxl lossles transcode are smaller and no quality loss

you seem to like many codecs

is good but same AVIF problems

this is a jpeg xl server

Wow that is quite a big gap

Yep, that's why I once decided to make my own comparison (but, which is no longer quite relevant to the new formats) https://medium.com/@scopeburst/mozjpeg-comparison-44035c42abe8

Maybe what Netflix is doing is good as an illustrative promotion of new formats, but it's still not exactly fair

Whenever someone claims "X % better than JPEG", there are four important questions: - Which JPEG encoder? - What kind of speed does your encoder have? - What metric did you use to compute the number X? - Is this true at the entire spectrum of fidelity targets/bitrates, or only in some specific region? (e.g. the "JPEG quality 20" region)

83% of the 'percentage claims' are at least 70% bullshit

Btw, I just now noticed that Netflix has removed the VMAF metrics and graphs (but they were definitely there before)

https://miro.medium.com/max/2400/1*4GqezV9d_3Sm9QZlGFXHjg.png

At low bpp Jpeg is bad, but I think not that bad if a good encoder was being used

Netflix https://miro.medium.com/max/2400/1*yu8PI1VKHOwRAxISI3ncxg.png

MozJpeg https://miro.medium.com/max/2400/1*iXC2oD7CkXInh83QETH1AQ.jpeg

I believe a VP at Netflix did their Ph.D. about VMAF and that may be a reason why they stay connected with it

For video VMAF is not so bad, especially for the content for which it was developed, but for static images...

AOM is unfortunately focused on VMAF and PSNR (possibly on Y-SSIM, too)

they are flirting with butteraugli and recently opensourced tune=butteraugli in libaom -- I hope it takes on there

I was not very happy with the VMAF result on something like game recording/streaming, also its results are much higher with hardware video card encoding than software implementations (x264/x265), but visually it didn't quite match and even MS-SSIM was much closer to reality

Um, that's not because of VMAF being bad.

It's that Nvidia's HW encoders are doing some tricks that I would call dishonest...

This is all together, also I compared between only software or only hardware encoding and the result was about the same

But, for something like movies and maybe a bitrate typical for streaming, VMAF is not bad (not sure about anime)

For example, I've recently been testing some game footage at various bitrates, and what I've noticed is that some footage is obviously sharper than the source, which made for some odd artifacts and rather high VMAF scores. Detail retention is challenging scenes is also garbage on most HW encoders since their tuning is made for real time purposes and whatnot.

https://slow.pics/c/r6N9bXzR https://slow.pics/c/3P6ADyMD For reference, I was testing x264 slow(default) vs NVENC Turing P7(the new highest efficiency preset yet) at 6mbps CBR. The difference is very large as you can see. The x264 footage is also more temporally stable.

Yep (although videos are more difficult to compare frame by frame, because they cannot have constant quality and at some point one frame may be more compressed than the other)

Indeed. That's the same problem I got when I tested butteraugli_main on video.

It made for an... interesting experience.

I used to compare for example only B-frames (as the most compressed, but this also does not solve all problems)

jpeg xl you need to see other options

modular significantly improved

it manages better luma

we can further improve modular I believe

I never optimized its quantization decisions, they are still whatever is the initial guess

@ryomivasalama2 Are you working on others improvments already or there are others priority?

I'm doing bureaucracy work, performance evaluations, calibrations, manager promotion support statements, and DEI committee work etc. 😄

i.e., not right now

I think I'm at minimum three weeks away to get it right

Hi Jon, I heard from Prof. Jarek Duda in Poland that Microsoft is trying to patent part of ANS and that might affect JPEG XL. Are you available to respond to a few questions about this? I am hoping to file an article for The Register later today. Cheers, Thomas Claburn The Register San Francisco, USA https://www.theregister.com/

I replied:

Hi Tom, I do not have any reasons to assume that the Microsoft patent affects JPEG XL, since there has been no ISO patent declaration at all on JPEG XL by Microsoft even though they are participating in JPEG activities and are well aware of JPEG XL — e.g. Gary Sullivan of Microsoft is a long time JPEG member. The only declarations on JPEG XL that were received by ISO are from Google and Cloudinary, who have both declared they have IP related to JPEG XL and declare to make it available on a royalty-free basis. Like other modern compression codecs, JPEG XL does use a variant of ANS in its entropy coding. This is a small but very important part of the codec.

The use of ANS in JPEG XL was based on Google's PIK codec, which has been publicly available since 2017 (see https://github.com/google/pik). Obviously, things that were present in a publicly available implementation before a patent was filed, would not be valid claims. I have not read much of the claims by Microsoft (patents are very boring and hard to read) so I do not know to what extent they are related to the use of ANS in JPEG XL. Like I said, I do not have any reasons to believe they would be related. That said, I do know that Jarek, the inventor of ANS, explicitly desires his invention to be not patent encumbered, which I think is very noble of him, and it would be a sign of intellectual integrity to not attempt to sabotage that by patenting what appear at a first glance to be straightforward and not particularly innovative variations on his invention, although it is of course up to the courts to decide on the presence or absence of novel inventions or prior art.

Finally, I personally am of the opinion that software patents, at least the way the current system works, do not have a particularly beneficial overall impact on innovation. It is more of an obstacle than an incentive to innovation. This is made worse by the relative ease of getting bogus patents granted, the legal costs and barriers to get bogus patents invalidated, and the common practice by patent trolls to threaten smaller companies with litigation and getting settlements even when the patents are clearly bogus or do not apply, just because settling is cheaper than fighting them. Best regards, -Jon.

<@794205442175402004> Is there any good article explaining exactly who is trying to patent what?

not afaik. I've only seen this post by Jarek: https://encode.su/threads/2648-Published-rANS-patent-by-Storeleap?p=68928&viewfull=1#post68928 and a reddit discussion around it (https://www.reddit.com/r/programming/comments/lzi2vt/after_being_defended_from_google_now_microsoft/)

I wonder why Microsoft is patenting something that seems to be about efficient hardware implementation of rANS

https://www.reddit.com/r/raspberry_pi/comments/kkzpuk/i_created_a_floppy_disk_vcr_that_plays_full/?utm_source=amp&utm_medium=&utm_content=post_title

Only x265?

For audio + video in what, 1.44MB, that's really good

It looks like they reduced the colors severely, dithered, and reduced the framerate by a ton so maybe not that great

But he says custom so something must have needed tweaking

I can really hear that low bitrate aac too lol

just getting the audio of a full length movie on a floppy disk seems crazy

2 kbit/s if it was just audio

Wait

Yeah that is insane

But you can do a lot of magic with dithering and color reduction + frame reduction

The video is 4 fps, 120x96. The audio must be extremely compressed too

I had .3gp shrek 15 fps in 16MB on my phone more then ten years ago. 1.44MB is ten time less <:megapog:816773962884972565>

He could have used extra density floppies, those were 2.88MB

Those were relatively common / easy to get

https://en.m.wikipedia.org/wiki/List_of_floppy_disk_formats

There's also triple density of almost 10 MB but I don't think I've ever used those

5 1/4 inch floppies were actual floppies, in the sense that they didn't have a rigid plastic case like the 3 1/2 inch ones

When I first saw a 3 1/2 floppy, I remember thinking "ah, so this is what a HARD DISK looks like"

I was 8 years old or so and still had a lot to learn 😂

(I remember heated playground discussions about this. "What? That's a 'floppy' too? IMPOSSIBLE! It doesn't bend at all!")

https://www.theregister.com/2021/03/13/microsoft_ans_patent/

Should have gone with Zip drive

that thumbnail is so cringe. https://www.youtube.com/watch?v=lFb7BOI_QFc

Seems they misspelled your name.

They did, but they fixed it

https://petapixel.com/2021/03/13/adobe-photoshops-super-resolution-made-my-jaw-hit-the-floor/

But, personally, I am not very happy about the popularity of ML upscalers and when people distribute and save an enlarged image, even though there seems to be an increase in detail and quality, in reality the original will still contain more real detail and information (not to mention the fact that the upscaling algorithms improve over time) However, it would be nice but computationally expensive to do this on the decoder side without affecting the original image

Good example of appeal (as opposed to fidelity)

AI upscaling gets amazing results, but in the end all those new pixels are biased by the training corpus. It's a form of hallucination, not actual reconstruction (which is impossible).

It's great if you don't care about fidelity and you're going to photoshop the image anyway: move a jawline here, smooth some skin imperfections there, increase the cup size somewhat. Then whatever the AI is doing is not going to make the difference.

Hmm, how do you define fidelity if the input and output don't have the same resolution?

If a downscale of the output matches the input well, could you define that as high fidelity?

fidelity w.r.t. reality, I suppose

Suppose you would have taken the photo with a higher res camera, ...

It's easy to make training sets for superresolution, you just need good high res photos and scale them down

Fidelity would be high res original vs ai-upscaled from downscaled image

Right, if you treat reality as the input for defining fidelity.

For the images similar to what they trained on, it will work quite well

Just don't try to get more resolution on images from the Mars rover with it

Or any 'atypical' photo

The main problem I have with such approaches is the deceptive result (especially if you do large upscaling, not just 2x). It often looks great and authentic, but it can be relatively far from reality.

And bias in training sets is a real issue

Remember this?

AI's version of Obama...

That sort of thing does happen

Wait, is that actually a thing?!?

It can happen easily. A neural net can only get as good as the data you put in it...

There's a difference between stuff like that and 2x res though :p

To be honest, I kinda like upscaling when done properly since it tends to look real and doesn't have that much made up stuff (and the vast majority of people won't even know it's upscaled anyways and will be like "wow, that image has such a high quality")

I think the 1st step towards better fidelity would be to adopt compression schemes which aren't absolute garbage.

And for example someone retouches a photo, then encodes it with a codec that applies heavy filtering with noticeable detail loss, then someone else finds that image on the web, upscales it, when new details are added (often nonexistent before) and the image gets further and further away from the original each time (but looks good as a quality image) And sources are often deleted or lost And this is the part that worries me the most, for example, no matter how encoded or "improved" movies on pirate sites that are widely available on other media in at least BD quality, but some content does not exist or is difficult to find in its original untouched quality (especially images)

> You can see both the original and the Enhanced images below. There is no way to actually convey the 100% image size here as I have no control over the viewer’s screen resolution but regardless, they both look wicked sharp. could have upsampled the original with a good non-AI algorithm

my experience of neural upscaling algorithms is that they help more with jpeg than with avif or jpeg xl

In this case it's for camera raw so it doesn't have to combine inventing pixels with trying to get rid of compression artifacts...

I consider that proper debayering is an unsolved problem -- only heuristic tricks have been used so far

ideally cameras would do similar things like the human eye there

occlusion is a common and universal thing in physical light propagation, the atoms creating occlusions are often clumped together by the electromagnetic force, i.e., there is proximity, etc. --- this has implications on what kind of interpretations are more likely

with a neural upscaler it would look better than the original?

more seriously, browsers should look more into upscaling -- I think there is an opportunity to improve quality right there

Yes. They usually have to downscale, where there's also room for improvement (like doing it in linear color). But on high dpr devices, upscaling is becoming more important...

when/where was that?

https://youtu.be/qDox5IVw74E?t=648

However, AVIF also fits (after adding YCgCo-R)

haha yes

though not sure if you can say AVIF is "optimized for web environments"

it doesn't have progressive decode, and the header overhead is kind of large

```$ hd transparent.png 00000000 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 |.PNG........IHDR| 00000010 00 00 00 01 00 00 00 01 08 04 00 00 00 b5 1c 0c |................| 00000020 02 00 00 00 0b 49 44 41 54 08 1d 63 60 60 00 00 |.....IDAT..c``..| 00000030 00 03 00 01 4f 48 0a af 00 00 00 00 49 45 4e 44 |....OH......IEND| 00000040 ae 42 60 82 |.B`.| ```

```$ hd transparent.png.jxl 00000000 ff 0a 00 10 b0 28 6e 04 08 10 10 00 1c 00 4b 12 |.....(n.......K.| 00000010 c5 82 85 24 0c |...$.| ```

```$ hd transparent.png.avif 00000000 00 00 00 20 66 74 79 70 61 76 69 66 00 00 00 00 |... ftypavif....| 00000010 61 76 69 66 6d 69 66 31 6d 69 61 66 4d 41 31 41 |avifmif1miafMA1A| 00000020 00 00 01 a1 6d 65 74 61 00 00 00 00 00 00 00 28 |....meta.......(| 00000030 68 64 6c 72 00 00 00 00 00 00 00 00 70 69 63 74 |hdlr........pict| 00000040 00 00 00 00 00 00 00 00 00 00 00 00 6c 69 62 61 |............liba| 00000050 76 69 66 00 00 00 00 0e 70 69 74 6d 00 00 00 00 |vif.....pitm....| 00000060 00 01 00 00 00 2c 69 6c 6f 63 00 00 00 00 44 00 |.....,iloc....D.| 00000070 00 02 00 01 00 00 00 01 00 00 01 db 00 00 00 19 |................| 00000080 00 02 00 00 00 01 00 00 01 c9 00 00 00 12 00 00 |................| 00000090 00 42 69 69 6e 66 00 00 00 00 00 02 00 00 00 1a |.Biinf..........| 000000a0 69 6e 66 65 02 00 00 00 00 01 00 00 61 76 30 31 |infe........av01| 000000b0 43 6f 6c 6f 72 00 00 00 00 1a 69 6e 66 65 02 00 |Color.....infe..| 000000c0 00 00 00 02 00 00 61 76 30 31 41 6c 70 68 61 00 |......av01Alpha.| 000000d0 00 00 00 1a 69 72 65 66 00 00 00 00 00 00 00 0e |....iref........| 000000e0 61 75 78 6c 00 02 00 01 00 01 00 00 00 d7 69 70 |auxl..........ip| 000000f0 72 70 00 00 00 b1 69 70 63 6f 00 00 00 14 69 73 |rp....ipco....is| 00000100 70 65 00 00 00 00 00 00 00 01 00 00 00 01 00 00 |pe..............| ```

```00000110 00 10 70 69 78 69 00 00 00 00 03 08 08 08 00 00 |..pixi..........| 00000120 00 0c 61 76 31 43 81 20 00 00 00 00 00 13 63 6f |..av1C. ......co| 00000130 6c 72 6e 63 6c 78 00 01 00 0d 00 06 80 00 00 00 |lrnclx..........| 00000140 14 69 73 70 65 00 00 00 00 00 00 00 01 00 00 00 |.ispe...........| 00000150 01 00 00 00 0e 70 69 78 69 00 00 00 00 01 08 00 |.....pixi.......| 00000160 00 00 0c 61 76 31 43 81 00 1c 00 00 00 00 38 61 |...av1C.......8a| 00000170 75 78 43 00 00 00 00 75 72 6e 3a 6d 70 65 67 3a |uxC....urn:mpeg:| 00000180 6d 70 65 67 42 3a 63 69 63 70 3a 73 79 73 74 65 |mpegB:cicp:syste| 00000190 6d 73 3a 61 75 78 69 6c 69 61 72 79 3a 61 6c 70 |ms:auxiliary:alp| 000001a0 68 61 00 00 00 00 1e 69 70 6d 61 00 00 00 00 00 |ha.....ipma.....| 000001b0 00 00 02 00 01 04 01 02 83 04 00 02 04 05 06 87 |................| 000001c0 08 00 00 00 33 6d 64 61 74 12 00 0a 04 18 00 06 |....3mdat.......| 000001d0 95 32 08 10 00 00 18 e1 42 72 10 12 00 0a 07 38 |.2......Br.....8| 000001e0 00 06 90 10 d0 69 32 0c 16 00 00 00 48 00 00 00 |.....i2.....H...| 000001f0 79 4c d2 02 |yL..| ```

I wouldn't say the AVIF container was designed with web optimization in mind. That's 457 bytes just to say "Hi, I am an AVIF file with alpha!" (and then 25 bytes for the 1 pixel RGB payload and 18 for the 1 pixel Alpha payload)

They could have literally used the ascii string "`Hi, I am an AVIF file with alpha!`" as a header and it would be 33 bytes, which is still 424 bytes less verbose than what they decided to do.

(sorry for the rant but for someone who is into compression, that container is kind of infuriatingly verbose)

I wonder if AVIF can be used without a container, because Dav1d can decode such files (although this is not standard, but it's still changing) <:Thonk:805904896879493180> Also sad that people know about AVIF but nobody knows about Jpeg XL <:PepeSad:815718285877444619>

Adobe Sensei's Enhance Details can do better job than usual demosaicing algorithms 😃 https://blog.adobe.com/en/publish/2019/02/12/enhance-details.html

Kornel has been trying to convince people at Chrome and Firefox to allow that (or even to keep the container and just drop some unnecessary stuff from it that decoders aren't even looking at), but without success so far afaik.

why?

I suppose because the spec is the spec and they want to follow the spec

which makes sense too, I suppose

I still think AVIF was created in a rush and not completely developed and I've also often seen in developer messages that certain things should be left until AV2/AVIF(2?), which also hints that the first version of AVIF is planned to be replaced after a certain time and will not last long

moving-target evolving specs and av2/avif2 are OK for applications where you control both endpoints (server and client, like Netflix or YouTube), but it's not so great if you want to have a stable web platform that is an actual platform and not just a single-vendor playground, let alone if you want to make a format that has wide support in a big range of applications

we have 0.3.4 but no quality improvements that I know of

My interpretation too. AV1 is a great video format, but AVIF is only a good image format.

The leaders of AV1 effort invited me to collaborate with AVIF development before AV1 was frozen

back then I considered that the development processes were too expensive for me, so I declined and continued researching 'pik'

I gave them feedback of the design, and they considered two changes: adding XYB and adding per channel quantization matrices

for first it was a 'no' and for the second it was a 'yes' -- so pik/guetzli experience did have some influence on AV1/AVIF design

But why 'no' for XYB tho?

XYB is crackpot science

no publication about it, no disciplined approach to derive it from electrophysiological experiments, it is just something I found by looking at what works

I studied the other alternatives in AV1 and the BBC engineers helped me to understand Dolby's ICtCp

I considered that it is 'close enough' and gave up trying to convince them about XYB

the culture in video coding outsources the color transforms as 'someone else's problem', they measure success without going all the way to color

so they didn't care much about it

I consider it dishonest in its culture since the heuristics will need to make compromises between chromacity and intensity channels and just not knowing what is being transposted there will lead to inefficient compromises

not to mention that the culture of "color is someone else's problem" tends to propagate all the way to the end-user

agreed

it is a decision with courage and new thinking that JPEG XL is with absolute color

it caused waves in the JPEG committee, too

At least JPEG already considered YCbCr a coding tool. In the MPEG world, even that is "someone else's problem"

ｔｈｅ

ｗｈａｔ

That's some proper ignorance out there

And that's from MPEG, people that are supposed to know that sort of stuff

it's not a matter of knowing stuff. It's a matter of how you define the scope of an image/video codec. If you see it as just a black box that compresses a 2D array of values, then you look at metrics like PSNR that tell you something about how close you were, and the problem gets a relatively narrow scope and from an engineering point of view, you get a nice goal to optimize for (PSNR) and you don't need to know what those values actually represent (are they pixels of an image that is shown? is it something completely different? no need to care!)

For me it's still ignorance not coming back and redefining the problem.

Apparently they still think of it as "2D array" you've just mentioned and not the image that's shown to human eyes.

That view also has the 'advantage' that hardware implementation only needs to do that black box thing, and things like doing proper color management are "someone else's problem" (so you can do stuff like just sending the YCbCr to the GPU and if it doesn't look quite right then surely the user can compensate by just turning the brightness and contrast knobs of his television, right?)

It is a culture. For example, chess players may see themselves as people who play chess well. Or they can see themselves as entertainment professionals. The latter is more useful and wider scope that can allow more business opportunities and may create more value.

decomposition of problems into sub problems is a core element in engineering

It is, but in this case they decomposed a problem into subproblems that aren't actually independent

People who come up with containers think that there is a hygiene reason to use the container and the data inside is dirty and shouldn't be passed around without the container

The hygiene argument is a nice one

I believe people in the video world also think that 444 vs 420 is "someone else's problem"

And some other people think that it's still not enough and put that container into another container

Rinse, repeat. At some point you'll get a matryoshka.

mkv?

I meant a more literal matryoshka...

https://upload.wikimedia.org/wikipedia/commons/7/71/Russian-Matroshka.jpg

I think that's also what the mkv container name is referring to 🙂

I know 😉

-q 42 i 3.7 - p 8 -s 9

best quality ever

the image can be enhanced before doing this

Yes. Also, selecting suitable quantization is "someone else's problem"

why bother

jpeg xl is still too new to understand

you understand only d 1 q 90

and things like -j

if you need to encode a jpg lossy with a version older than 0.3.4

I think options should be optional

ok

and defaults should make sense

in fact squoosh supports only lossy vardct

https://bitmovin.com/vvc-quality-comparison-hevc/

I'm seeing that video

it's really a vvc decoder

what is the bitrate and the codec whom was re encoded?

libjpeg-turbo's `cjpeg` for example does not really make sense: it doesn't even optimize Huffman tables by default. The default is non-progressive, non-optimized, low quality 4:2:0. That's not a good default, that's a default that just does the fastest possible (and rather crappy) thing, ruining your images just to look fast.

Defaults should instead have a good balance between speed, quality, density, and err on the safe side when you are trusting it with your images.

mozjpeg has way better defaults and I want it to fully replace libjpeg-turbo EVERYWHERE.

Mozjpeg's defaults make much more sense indeed (though I wish it had a simple speed setting, it's kind of slow by default and not so easy to figure out how best to make it faster)

I was testing mozjpeg on anime, seem more flat quantitation is better, i recal avif have more flat quantization then jxl true?

VVC will probably also have 50% more patents than its predecessor HEVC.

I don't know about avif/av1, but in jxl the quant tables can be customized so it's more of an encoder thing than a bitstream thing

<@!532010383041363969> said this if I remember

Still wonder where all those "50%" claims come from every new video codec generation

why jpeg xl images encoded at -q 42 i 3.7 - p 8 -s 9

doesn't look like vvc

if the quality is the same

Like, would be nice if you could just reduce the bitrate with 50% and actually get similar results, but the result tends to be much lower quality

can jpeg xl have enhancent tools

https://tenor.com/view/bunnies-what-confused-meh-gif-13712192

yes webp2 they want lower

than vvc

i'm not an expert can you ask the dev

they come from looking at PSNR

Hm, guess that's fair since it usually doesn't really seem to be 50% since at 50% it tends to look (slightly) worse <a:sadd:818856865231405117>

psychologically, it’s very tempting to compute stuff just to have a number, without reflecting on what that number really means

Nah, it's at higher resolutions where the gains are actually close to 50%.

what h265 encoder are they comparing to what h266 encoder?

VTM vs HM for VVC vs HEVC.

ok so both are the terribly slow one

Indeed. They also don't give encoder settings, which as always, seems rather odd.

I heard new VVenC got faster and beter

I mean, comparing PSNR is kinda the best you can do if you just have the viewpoint that you're compressing numbers, and who cares what those numbers are

I guess. I would also care about max error, not just mse

But doing lossy without caring what it is you're losing does not really make sense to me.

https://twitter.com/richgel999/status/1372029402033324036

But isn't stb_image slower than lodepng? spng may be faster, although I don't know how correctly it decodes most PNGs

https://github.com/libvips/libvips/issues/1403#issuecomment-632141336

> So, on this benchmark, libspng built with zlib-ng is about ±58% faster than libpng with vanilla zlib and ±32% faster when libpng is built with zlib-ng as well. 🤔

I've never ever heard of such a thing as "PNG bugs".

unfortunately, I have xD

are there no certainties in life?

I'm not sure 😛

Not in the current political systems… 😋

Also Zlib-ng 2.0 Released As More Performant + Modern Zlib Fork https://www.phoronix.com/scan.php?page=news_item&px=zlib-ng-2.0

https://github.com/zlib-ng/zlib-ng/releases/tag/2.0.0

There were several interestingly failing decoders -- including IE6 and some early mobile phones.

there still are

it's not uncommon that they expect 8-bit RGB or RGBA and go nuts when it's something else like 4-bit grayscale with alpha or whatever other weird things you can do in png

-q 72.9 -s 9

Funny, but you can't do 4-bit with alpha in PNG. 😜

maybe is better than using q 83.2 -s 6 new heuristics

Fabian, where you find this numbers?

random numbers

with 0.3.2 you can still do modular postprocessing

modular postprocessing?

like enhancing moire with old version

how?

for %i in (D:\Images\JXL\PNG\*.png) do cjxl2 "%i" "%i.jxl" -j -P 5 --palette=0 -I 5 -s 3 -m --mquality=94 --num_threads=2

with 0.3.0

35ad23dd ·

it will greatly enhance moire of the original

but the moire will get re encoded at -q 72.9 -s 9 with 0.3.4

it makes no sense

like we probably have lower bitrate jpeg xl

more efficiency in next encoders

in varDCT

how a lossy encoding "enhance" the original??

moirè means the image will looks like is duplicated

so worst artifacts

you're not supposed to use image compression as a photoshop filter 🙂

It's a next-gen art

lo-fi trend

https://core.trac.wordpress.org/ticket/52788 Add JPEG XL support. > Milestone changed from Awaiting Review to Future Release > Owner set to adamsilverstein > Status changed from new to assigned

results with my encoding

a bit ugly

maybe i'm overcompressing

wb

this saved many images would degradate or not?

are these encodings supposed to share?

with 0.3.3 i didn't notice those artifacts

at least with that decoder it looks sharper

if this is the original you can't do any better

for low quality original jpg lossless trascode is best option

-s 3 --lossy-palette=0 -q 62 -P 17

trying

no option can create new details if there are not in the original

-s 3 --palette=0 --lossy-palette -q 62 -P 17 --num_threads=2

ah

bad

i don't want images in the web looking like this

get a better original

Yeah, doesn't mater what image format you use, it will not produce a file better than the quality of the original.

why not add p 17

jon is there an encoder where i can have P17?

i need p17

in a one encoding

from a png/jpg

what is P 17?

predictor 17

does it exist in one of encoder commits?

-P K, --predictor=K [modular encoding] predictor(s) to use: 0=zero, 1=left, 2=top, 3=avg0, 4=select, 5=gradient, 6=weighted, 7=topright, 8=topleft, 9=leftleft, 10=avg1, 11=avg2, 12=avg3, 13=toptop predictive average 14=mix 5 and 6, 15=mix everything. Default 14, at slowest speed default 15

P 15 litteraly use all, what P 17 even mean

https://tenor.com/view/this-is-spinal-tap-this-goes-to11-sure-gif-11671428

you want the knob to go to 17 ?

no i'm asking if there is any encoder

https://tenor.com/view/spinal-tap-numbers-go-to11-gif-4660832

even old

not afaik

even from1 year ago

that we cant' read

on the web

we only added predictors, in older ones you can find 7 as the maximum iirc

If it could go to 31, that'd be great. https://discord.com/channels/794206087879852103/805176455658733570/821428407240753182

31 also for me

or 42

https://tenor.com/view/star-wars-palpatine-unlimitedpower-power-gif-20519259

If possible, add colored cjxl terminal output?

https://c.tenor.com/JFIE_HiM5ogAAAAM/rainbow-pride.gif

What colors? Red on error, green if OK or something like that?

For Encoding time (seconds) and image size

we could print the bitrate in red if it’s a very low value like 0.15 bpp

from 0.260 bpp is good

or 0.310 bpp

And beep PC speaker

Is blinking text still a thing you can do nowadays?

Maybe we can output unicode emojis to indicate our opinion of the distance target you chose, and to test if your terminal actually supports that

at least on some terminals yes xD

(gnome-terminal is one such terminal)

windows 7 don't support it

it is degenerate quickly

What about a smooth progress bar using unicode block characters?

Fancy

what's wrong with printing progress and ETA as just some fraction or percentage?

Nothing, a bar is just fancier

No need for bars if the encoder is so fast it doesn't need it. 🧠

We don't have a galaxy brain emote in this server?

I prefer minimalism and neutrality, colors and active text elements complicate scripting and logging output, I think this is a job for the GUI or other third party apps

Is it too early to write SIMD PRs? (And is the codebase particularly amenable to SIMDization? Haven't started looking at it yet.)

There's already a lot of x86_64 SIMD. If you want, you can write the SIMD for resampling since it currently doesn't have it and it is quite slow... <:FeelsReadingMan:808827102278451241> Or more ARM SIMD.

I only really work with x86 and ARM's SIMD documentation is so bad that I don't see that changing any time soon :P

Progress bar is useful when encoding 100mp image and slower speeds.

I'll look at resampling!

pip uses such progress bars

try `pip install --user [something big]` (nothing comes to mind immediately)

there is this python module for producing them: https://github.com/tqdm/tqdm

might be what pip uses, I don’t remember

It can be done as in WebP2 with an optional key like `-progress` ```Usage: cwp2 [options] in_file [-o out_file] Options: -progress .............. display encoding progression```

veluca is the main guy working on it, so you could probably get some help from him. It's also currently single threaded IIRC.

not anymore 😛

still not SIMDfied though

we use https://github.com/google/highway for SIMD

(at least mostly)

the ARM NEON documentation isn't too bad, come on 😄

Yeah. Enable progress with flag or enable automatically when s>8.

Now we do <:galaxybrain:821831336372338729>

but who does the updating of the wikjipedia for patented codecs container

for example heic

to be honest, we didn't yet really figure out the CLA situation for this kind of contributions, so I'm not sure if it would be possible for you to help at this stage 😦

are paid people for every nation by mpeg