JPEG XL

True. The max pixel resolution for AV1 is 35MP. I had also forgotten about that.

About 4: I have looked at AVIF results with libaom, rav1e, SVT, and at Cloudinary we use Aurora because it's currently the best one available.

The 10-bit limit I assumed was intentional. WebP2 also has that limit, for example. If you're aiming for the web delivery use case, it seems unlikely that more than 10-bit will be needed anytime soon.

I knew that tools can handle 12-bit, but I assumed that's just because they simply call the av1 decoder and have no reason to actually check if the profile actually matches the one specified at the container level.

Dav1d is indeed fast enough in practice for still images, I think. Still, in single-core decode speed, I think at least on x86, jxl is about twice as fast.

damn proprietary

yes, I really hope at some point the best AVIF encoder will be a FOSS one again

netflix need put money

Who funds AOM development?

is it AOmedia or just developers hired by various companies

Members of AOMedia mainly, so Google, Ittiam, Intel, and some others at various times.

I'm suprised google hosts them

I thought with Microsoft in AOM GitHub would have been a more attractive option

https://aomedia.googlesource.com/aom/ https://github.com/AOMediaCodec https://gitlab.com/AOMediaCodec

They're everywhere

https://tenor.com/view/starship-troopers-traitor-of-mars-starship-troopers-gifs-they-are-everywhere-everywhere-gif-9385373

<https://github.com/mozilla/mozjpeg/commit/9f01177f72ad55acf98c0160a9ddbe67ea3271ff> > Default to single-scan DC > People don't like green faces <https://github.com/mozilla/mozjpeg/releases> `mozjpeg-v4.0.3`

"People don't like green faces"

suit yourself

https://cloudinary.com/blog/progressive_jpegs_and_green_martians

ISO/IEC AWI 19566-8 Information technologies — JPEG systems — Part 8: JPEG Snack What I think of:

https://tenor.com/view/chips-and-dip-salsa-chips-chip-and-dip-day-happy-chip-and-dip-day-gif-16658338

Does it support encryption with Salsa20?

I didn't go to the meetings about it, they were usually at ungodly hours when both the US and Asia are awake.

So the majority of the world 🙂

Yes but not me

4 am meetings about JPEG Snack, no thanks

But I hear their food its 👌

Back when we did physical meetings, there was sometimes food during coffee breaks

Maybe that were the JPEG snacks

4 hour meetings to decide the first post-corona break snacks

An international standard on ISO committee meeting refreshments? <:kekw:808717074305122316>

You overestimate the efficiency of a committee - they could never decide such a pressing matter in a mere 4 hours

aye

4 hour meetings plural

Ah yes

That sounds more like it

in that amount of time they would designate subcommittees to explore their options

Just deciding the name of the explorative project that will come up with the study text of the draft proposal for a new work item is probably something that could take several meeting cycles.

anyway, this is what the Snack in JPEG Snack refers to: https://en.wikipedia.org/wiki/Snack_culture

I suppose it's mostly a Korean thing, I dunno

I think it's a domain specific codec for images of food

To go with JPEG Cat, and JPEG meme

By optimizing our codecs for the some of the most popular uses on the internet, we expect efficientcy improvements of up to 50%

Just save the most popular memes directly in the decoder and if someone tries to encode it, just send its byte identifier to the decoder and output it directly. That thing would not only compress majority of memes to just a few bytes, but also be *completely* generation loss-resilient! 😉

<@!794205442175402004> where Aurora AV1 encoder really shines?

Well we mostly care about relatively fast encoding, otherwise latency of first request becomes too much of an issue. Libaom and rav1e are too slow for us atm. SVT gets close, but uses a lot of memory, which is also a problem when you want to do things at scale. Aurora is about twice as fast as SVT for a result that is a few percent better, with a much better memory footprint.

https://github.com/AOMediaCodec/libavif/pull/526

https://youtu.be/z6stCw1g3BE

Looks like someone remixed my generation loss comparisons

4chan ||https://boards.4channel.org/g/thread/80409625||

> 4chan

DON'T. Lmao

Sometimes there are much worse comments and understanding on reddit than 4chan (also the dumbest posts on 4chan are mostly trolling)

Have to love that mix of trollish rudeness, strong opinions based on very poor understanding, and the occasional brave knowledgeable person trying to educate the masses.

Reddit tends to have the same kind of mix, just more politely phrased.

And HN is that plus silicon valley smugness.

After some more YouTube re-uploads it will become a video generation loss comparison

I get a video description that looks automatically translated to French

<https://forum.doom9.org/showthread.php?p=1936981#post1936981> https://i.imgur.com/FljFaaR.png

https://www.meetup.com/JAMstack-Toronto/events/275601729/

https://github.com/facebook/zstd/releases/tag/v1.4.9

Whats the word on getting this in the linux kernel?

I hope they update it's implementation at some point

<@!794205442175402004> Rav1e adaptive quantization pull request

https://github.com/xiph/rav1e/pull/2682#issuecomment-793602488

https://www.reddit.com/r/AV1/comments/m15fu3/avif_decoding_support_merged_into_apples_webkit/

Always a surprise when something happens in webkit

It's good that AVIF gets close to universal support now (in the near future). I just hope it will not be a reason to not support JXL too.

https://youtu.be/MZhZ5OHpg74

> The debug images from the **SSIMULACRA** metric are displayed with SSIM heatmap on the left and edge differences on the right. SSIMULACRA and Butteraugli are increasingly being used for video 🤔

Ah, you found his video. 😛

🆒

🥶

<https://encode.su/threads/3589-GDCC-port-mortem>

> **mpais** > I started with LEA for the Balanced image compression test, a poorly hacked together entry. It's just about 700 LOC, and that includes an LZW compression engine for non-image content, since I thought the rule about being able to compress all datasets meant I couldn't just store them. > It should honestly be at least 3x faster, but it got the job done > > For the HCR image compression test, the approach used in LEA doesn't really scale well to really high compression ratios, so I used a plain old boring context-mixer and reused the name EMMA. > Again, it's fairly poor code, unnecessarily slow, but honestly the prize money didn't justify spending much time on each entry.

https://www.reddit.com/r/AV1/comments/m3dt54/avif_hits_6282_on_caniuse/

https://chromium.googlesource.com/codecs/libwebp2/+/4f423d5e2f11924bab6683c112a0d6b17e943f38

> av1enc: add -tune {vmaf, bufferaugli} to aom encoding > > since it's experimental and not always included in local aom.h, > we drop the typed enum for 'tuning' and use 'int' instead, relying > on aom_codec_control(). > > tune butteraugli only works with YUV420 for some reason, so one need to > use '-420' option

https://libspng.org/

Butteraugli don't like YUV 420, I think use YUV 420 on Butteraugli isn't a good idea.

Yes, it is strange why only YUV420, but apparently it is the initial implementation

And Libspng is also interesting, libvips uses it currently (but which does not yet support Jpeg XL https://github.com/libvips/libvips/discussions/2055 )

https://twitter.com/parker_gibbons/status/1301310949073121281?s=19

> telling people to use something other than jpeg 🙂 > it's png 🙁

i was gonna go off about jpeg xl but then noticed it's from september

didn't want to bump such an old post

and iirc jxl wasn't frozen then

It was unofficially frozen in Dec 2020 and officially in Jan 2021

we did have webp and avif at that point tho

and iirc animated pngs aren't supported everywhere

https://caniuse.com/apng

Only GIF actually works everywhere though

APNG will often be first-frame-only, AWebP will often not work at all

It's kind of annoying from an application point of view when you make something that is intended for still images, and then it turns out you need to support animation too

yeah hopefully no one ships partial jxl support

would fuck up the ecosystem real quick

It will probably be kind of inevitable that some applications will mess things up

Like when you make a word processor which is meant mostly to produce documents that you can print

Would you implement animation support in that?

It's likely not to happen

Quick, someone invent digital paper that can change what is displayed.

I think it exist

https://c.tenor.com/1OjK5twN340AAAAM/ahh-screaming.gif

https://syncedreview.com/2021/03/12/stanford-novel-image-compression-method-coin-better-than-jpeg-at-low-bitrates/

This is good but is it useful

Like surely from a research standpoint

But not practically

It's certainly interesting

I just don't see the need for a neural network when the only range of usage is from 0 to 0.3 bpp

That's probably also the worst possible jpeg, not mozjpeg or some other good jpeg encoder.

Also PSNR is not a very good metric

<:AV1stonks:781612882176507915>

Disappointed, you didn't use one of the best jpg encoders >:(

Maybe we need to make jxl t-shirts too 🤔

<:JXL:805850130203934781>

Yes

<a:CatYes:806636752952754186>

Make one and I will probably order one. <:megapog:816773962884972565>

A shirt that has jpeg, gif, png, webp, and avif crossed out and circles jxl

Nah, no need to diss the shoulders of the giants we're standing on

I got my AV1 t-shirt for free from Nathan. It was 2.5 years ago. The shirt has mozilla stuff on the back.

Maybe I can get Cloudinary to make <:JXL:805850130203934781> tshirts that I can give to people for free, that would be cool

How would those be given away?

Just hope they don't say <:JPEG_XL:805860709039865937> only

Gimme dem <a:ajxl:806626687130533959> shirts <a:dogeevil:749457940041302078>

No idea, normally that would be at conferences and events and stuff, but with covid that's of course not happening anymore.

Any day now!

Anyway, make a TShirt design with JPEG-XL and I will buy it. 💸

<:WhiteFoxMoney:785018275762405387>

Is this real)?

What is real? How do you define real?

no sorry weve all been living in the matrix

we're like 3 nested matrixes deep in fact

bold of you to assume it's a finite number

it's matrices all the way down

This is photo that he take or this is "photoshop"

thats why better jpeg compression is so important actually. because it gets applied over and over again for each layer

so we're pushing the infinity down to a smaller infinity. much more manageable

i guess it's real

👍

i was going to say that that violates information theory but then again, maybe the same rules of physics don't apply to the outer layers

Not photoshopped

https://tenor.com/view/star-wars-you-were-the-chosen-one-scream-gif-16055856

<https://github.com/AOMediaCodec/libavif/commit/d2340b4e8bff90a72fcb6f2c303ee6f66b5e9fa7> > // a 12 hour AVIF image sequence, running at 60 fps (a basic sanity check as this is quite ridiculous) 🤔

can we use the animated logo? 😄

https://tenor.com/view/wow-spin-shake-human-hamsterwheel-gif-3957046

sure, just wear it and then do <:This:805404376658739230>

trying to make the smallest possible single-pixel image in AVIF, for 1 white pixel, 1 black pixel, 1 transparent pixel, and 1 arbitrary-RGBA color

turns out lossy compression of pure white (#FFFFFF) decodes to #FEFEFE

so weird to see "file format" be translated xD

These are unique fonts from Fabian

can you do with the new version <@!111445179587624960>

The new AV1 t-shirt design is ready

thanks

you're a genius

LMFAO

really? that's a sick name 😛

#badpuns

in github i'm called fabiorug

raffreddore is called the repository

So if anyone wants to know how to make an animated AVIF sequence (aka AV1 in an AVIF container): `MP4Box -add inputAV1.mp4 -ab avis -ab msf1 -ab miaf -ab MA1B -rb mif1 -brand avis -new animated.avif` MP4Box is part of GPAC and the result can currently be viewed with Opera 71+, Chrome 85+ (and mobile works since version 81 according to <@!172952901075992586>).

Some examples:

Apple Preview is not capable of converting a 1x1 white pixel image to HEIC. Interesting...

oh, it's because it's a 1-bit grayscale PNG, looks like they did not cover that case

But I did 😉

JPEG XL and AV1 (AVIF) should cooperate, AV1 for videos, AVIF for extremely low bitrate photos (quite niche, but still, at least until JPEG XL doesn't get better) and JPEG XL for images.

I'd like to see a JPEG encoder that'd guess the original coefficients (assuming that the photo wasn't edited or non-boundary cropped).

The big question is -- why? Animations should not work in Chrome. So is it a bug that some seem to work and others don't?

Who says animations should not work in Chrome?

Google, though Can I Use is the only place it seems to show up anymore. I remember when it came out it was announced lacking animation support. Since then, I've heard no official announcement for animations being added. https://caniuse.com/?search=avif

trying HEIC to compress this gmail icon

the image on the right is what I get if I open that PNG in Apple Preview and do Export as HEIC with the quality slider set to "lossless"

guess they mean "lossless modulo subsampling chroma and alpha and messing up the colors"

f*** alpha subsapling sound stupid

not sure if that's what's happening but how else could you get that result?

calling this "lossless" is really a big stretch

What if you convert the HEIC to other formats? Does it stay like that?

As far as I know Apple lossless is just "high quality"

yes, it does

ah no not really

the one on the right is the heic exported back to png

the colors are back

the ugly diagonal stays though

Ah, so a bit of both then... The transparency is not likely to be a bug in the preview app, it's actually destroying the image. 🙁 But the colors might be a bug in the display... or in the HEIC spec.

the original is a 150 byte PNG file

the 'lossless' HEIC is 1435 bytes

at least AVIF can actually do it losslessly, it's 639 bytes so a lot better than HEIC <:kekw:808717074305122316>

And if use libheif https://github.com/strukturag/libheif ?

```Note: to get lossless encoding, you need this set of options: -L switch encoder to lossless mode -p chroma=444 switch off color subsampling --matrix_coefficients=0 encode in RGB color-space```

The other question is... if you are using Apple, and you take a photo and it saves as "lossless HEIC"... is it actually lossless or are you losing data? 👀

that is what I get after doing `heif-enc -L -p chroma=444 --matrix_coefficients=0` and `heif-convert` back to PNG

maybe I need to try a more recent libheif, this one is whatever Debian-unstable gave me

ok looks like libheif does not like palette PNGs as input

if I first convert it to a non-palette PNG, it does work

not fully lossless, there are off-by-ones in the RGB values even with -L -p chroma=444 --matrix_coefficients=0

but at least it looks identical and it's only off-by-ones

heic file is 1811 bytes

I guess animated AVIFs need the `avis` branding and probably also the other ab and rb metadata to be working files. It looks like Chrome has support since 85 and Opera since version 71. Also, just putting them inside a video tag should work on every browser supporting AV1.

https://github.com/AOMediaCodec/av1-avif/compare/d6630a044a...7536f4bccd

`NOTE: [[!AV1]] supports 3 bit depths: 8, 10 and 12 bits, and the maximum dimensions of a coded image is 65536x65536, when coded with level 31.` 🤔 I thought the max for an AV1 frame was 35MP, not 4000MP. Wait, is that including the external tiles during encoding?

I think so

uh

level 31??

"Level 7 has not been defined yet."

but level 31 has been defined?

I have the impression the Wikipedia article hasn't been updated in a while...

ah

level 7.x has not been defined yet

but I guess the NOTE refers to the seq_level_idx 31, which is defined, and is just "no limits"

it seems not very wise to promote the creation of "no profile" avif files

because that means you're also promoting the creation of decoders that try to decode those files, even if they have no clue if they actually can

Chagall: `level index of 31 is unconstrained, rav1e always uses it for still_image` <:monkaMega:809252622900789269> `libaom just tries to estimate the level based on some input parameters but gets it wrong pretty often`

Why do you define profiles and levels then?

It's mainly for HW decoding of videos, not AVIF images.

<:JXL:805850130203934781>

Woah, you can just rename animated .avif to .mp4 and upload it to Cloudinary: https://res.cloudinary.com/mattgore/video/upload/harvey.mp4 Browsers will open the file as video but putting it inside an img tag still works for Chrome (and probably Opera). If you don't have an account already, you can create one for free here: https://cloudinary.com/invites/lpov9zyyucivvxsnalc5/zijlpiu73n5ff0rhloih

<@!794205442175402004> We are allowed to advertise Cloudinary, right? <:ugly:805106754668068868>

Sure, I guess 😃

I would assume the server would be looking at the file headers and/or mime and converting it. It shouldn't care about the extension.

Does libjxs have an unofficial logo? Or are they open for submissions? 😁

I don't think they have one

XS is a patent-encumbered codec though... They're aiming for a rather specific niche / application domain too...

do you know webp2

cwp2 -effort 5 -diffusion 48.8 -q 72 -pm 1 -sns 52.06 C:\Users\User\Desktop\2938137252.jpg -o C:\Users\User\Desktop\a.wp2

is it a right command?

it did

i downloaded this from doom9

https://www.sendspace.com/file/imvjom

95.6 -s 2 webp2 jpeg xl 0.3.4 80.4 -s 8

in this way you'll get the image encoded with good efficiency

just decode to png the images

if the detail is missing webp2 can give the impression of detail

would be interested to try lossless palette 9

I'm trying out JPEG XT 🤪

https://github.com/thorfdbg/libjpeg

This is the original PNG:

https://upload.wikimedia.org/wikipedia/commons/4/47/PNG_transparency_demonstration_1.png

JPEG XL `-q 30` after decoding to PNG; it's doing quite well...

...compared to JPEG XT with matched filesize 🤮

how to compile

And this is original JPEG XT file, if anyone's curious (yes, you can actually decode this thing if you've got a decoder, Discord doesn't strip JPEG XT metadata)

i'm on windows 7

do you can share builds?

Bad news for you, you need Linux or Windows 10 with WSL2

Why don't you use linux inside a VM?

i don't know how to compile

i can't run makefiles

Setting up a virtual machine doesn't require compiling at all

like i saw jamaika using a GUIs

for compiling codecs and specifying compiling parameters

but i don't know how to open the GUI

if there is some requirement like powershell

or windows 10

because some version of c require new system

at least for compiling

It's much easier to compile software on Linux

First try to learn using ubuntu or someother distros. You don't need to understand about compiling code.

It depends on the software, but that JPEG XT that I linked above just needs `./configure` and `make` if you used Linux

yes i tried on vm

<@!416586441058025472> and I don't have to encode that photo you gave me, JPEG XT is an extension of the original JPEG, it's not really a new format.

You'd need it only if you needed high dynamic range (HDR), high bit depth or alpha channel (transparency).

In case of most photos you don't need that.

<@456226577798135808> could you link me the jpeg xt encoder source code?

NVM. I got it.

Okay, now you've got something interesting: HDR imagery (I mean *actual* HDR, not tone-mapped to SDR) comparison. Original vs JPEG XT vs JPEG XL, all imported to GIMP's XCF file so you can edit it as float (`Exposure` works properly with HDR, `Curves` don't). Here's the file reuploaded to Discord by <@!219525188818042881> (big thanks!):

JPEG XT original command: `./jpeg -v -h -N -g 0 -rqt 3 -oz -dr -qt 3 -r12 -q 50 -Q 60 Apartment_float_o15C.pfm Apartment_float_o15C.jpg; ./jpeg Apartment_float_o15C.jpg Apartment_float_o15C.jpg.pfm`

JPEG XL original command: `.\cjxl .\Apartment_float_o15C.pfm .\Apartment_float_o15C.jxl --target_size=577100 --intensity_target=4000 --noise=1 --dots=0 --patches=0 --epf=-1 --gaborish=1; .\djxl .\Apartment_float_o15C.jxl .\Apartment_float_o15C.jxl.pfm` _(**note**: I used 577100 target size despite JPEG XT file being 577572 because `cjxl` was somehow constantly overshooting the target)_

Hey, I've got a question regarding modern image codecs in general... It seems common to use the same file extension for lossy, lossless and animated lossy/lossless variants of the same codec these days, but why?

Personally I find different file extensions beneficial for easily and quickly distinguishing these variants as well as making it easy for your average joe to understand. You get sent a FLAC or a PNG and be reasonably sure it's lossless, but you get a WavPack or WebP and there's no clear indication what it's going to be.

We had that discussion already, <@!794205442175402004> should probably add something regarding .jxl to <#822120855449894942>.

https://www.reddit.com/r/jpegxl/comments/maabyj/newbie_question_regarding_jpeg_xl_file_extension/

Interesting... I'm still a bit confused however. Will JXL have just one official mime-type also?

One is all you need!

`image/jxl` and **nothing else**.

I really mean no offense, I'm really impressed with the work so far dating back to the FLIF days of having a responsive image codec for handling multiple sizes from a single file, but I honestly feel like there's some more subtle details being overlooked by having a single file and mime type.

Extensions may be whatever you want, it's just a matter of convention you can easily change by just renaming your files. Mimetype is something a bit different, it's for machines. All of the files that fall under current `image/jxl` use the exact same decoder, so no need to differentiate them for machines.

The point is that the losslessness isn't a property of the file format. It's the setting chosen in the encoder. If you want to convey to the (human) receiver the file is lossless, maybe use "file.lossless.jxl" or so?

With the same file extension and not caring about file extensions from a decoder level: - You can't filter image search results by static/probably animated and lossy/probably lossless on web search engines nor Windows file search - There's uncertainty about what variant it's likely to be - Easier for generation loss to occur as a result of people or services unknowingly re-encoding lossless files as lossy ones (you share a png and even after a lot of iterations it doesn't suffer from significant generation loss even with lossy "png optimiser" tools as even those still aim to be near-lossless) - No clear way of knowing if the JXL file produced by your camera earlier is lossy or lossless (for editing) without getting a hex viewer out and checking for a specific magic number, which is beyond a lot of people's abilities - Web devs cannot white/blacklist image codecs by variant - An advertising firm may want to block animated image banners without needing custom code to detect the magic numbers. - HTML doesn't allow filtering file uploads by magic numbers - only mime types and file extensions. Of course you should validate both sides but having it done natively by the browser in your client-side implementation is much easier Lastly, the general public tend to understand things by their file extensions. A GIF? Oh that's an animated image. A PNG? That's a lossless file that can be transparent. An MP3? Music. FLAC? Lossless, high quality music. Of course, you can maliciously change the file extension or otherwise not meet those general assumptions, but people generally stick to them.

A different media type for animated and non-animated could make sense, but then again, I don't think gif, webp, or avif have a different media type for their animated variants...

PNG can be lossy or animated and all modern formats have the one official extension, such as WebP, HEIC, AVIF (there was also Avifs, but then abandoned)

As far as I'm aware PNG is only lossless with lossy implementations making use of its interlaced feature to grab a lower quality image from it?

There are non-animated GIFs. There are animated PNGs. An mp3 can be higher fidelity than a flac (e.g. because the flac was recorded with a crappy microphone).

There are plenty of lossy PNG encoders, e.g. Photoshop and pngquant

File extensions are not a guarantee I agree, but it does give you an indiciation of intention assuming you trust the source

You get sent a PNG and you can reasonably assume that the author intended to send you a lossless image. You get sent a WebP and you don't know. While mentioning this in the filename can help, services are less likely to recognise this than a standardised file extension and may unintentionally ignore the author's desired intent and lossily re-encode the file sent over their service as a result

I don't think it's reasonable to assume that PNGs are lossless

Also I don't think it's reasonable to assume that JPEGs are lossy

Yes, the person who sent you a PNG or FLAC may have sent you a lossy file re-encoded to a lossless one. But generally speaking I think it's safe to assume that the person's *intent* was to send you a lossless file, especially if they were the original author

If your camera produces a JPEG, then that JPEG might be the most lossless version of the photo

I don't think it's a good strategy to let workflows and processes be guided by filename extension conventions

> There are non-animated GIFs. Yep, even today I saw some black and white static images in GIF format on discord

<@794205442175402004> Very random idea: would it make sense to have a standard tag in the image file format that says "lossy transformation performed by ..."?

There's a new adhoc group in JPEG that wants to standardize metadata related to content authenticity and keeping track of what happened between capture and display.

When they come up with something, it will most likely be represented in JUMBF so jxl will automatically support it :)

May I request that the reference encoder uses lossless settings by default on jxll file extensions at least and shows a decoding warning for lossy JXL files with jxll extensions? Similarly, showing a warning when encoding or decoding an jxla/ajxl file extension with only one frame?

The encoder could do that, but the decoder cannot really know what is lossy or lossless

There's no way of telling if a file was lossy or lossless encoded?

Lossy or lossless is not a property of a file, it is a property of a process

So there's absolutely no way of stopping or warning about generation loss if someone wanted to do that?

Without having the original ofc

I think it would be better to change the mindset and use in new formats without being tied to the extension, people are very used to it during the old limited formats (it's sometimes more convenient to quickly understand, but it's also not quite right)

You can make a guess, e.g. xyb vardct is likely lossy, ycbcr vardct is likely a losslessly recompressed jpeg, and modular without squeeze and delta palette is maybe lossless. But those are guesses based on what the current encoder does.

Also, while I was doing test for Emoji, many of the PNGs were actually GIFs or Jpegs, but with a PNG extension (I don't know why, apparently for easy upload to some services) Also many of the PNGs on websites now are lossless WebP with PNG extension So extension is not a guarantee of anything, it is only a very rough understanding of what the image will be with a certain chance

I'm just concerned that having everything use a single file extension by default is a barrier to adoption. I personally have avoided WebP because I don't know what my CDN will do to it and if the generation loss will kick in due to someone or something in the chain mistakenly re-encoding it to lossy. It's easy to remember a file extension, it's not so easy to know a magic number and run an algorithm to figure out the author's intent. Of course, extensions can be wrong and ideally decoders should require the right one to prevent this, but at least it makes it easy for people and machines to know the sender's intent

Many actual PNGs have been JPEGs before, or have had their colors reduced to fit in a 256-color palette. Lossless PNGs are the exception more than the rule.

There's a lot of people who don't understand codecs and do stupid stuff like that, yeah

It is not necessarily stupid

And creating different extensions for one format gives a little convenience of quick understanding, but creates other problems and increases complexity

Could you elaborate on what problems it creates?

If you want to add alpha transparency to a JPEG in a way that works on every browser reliably, and have decent compression, then making it a (lossy) PNG8 is often the best choice.

This has also been accepted for a very long time in video formats, e.g. MKV or MP4 can contain a huge number of different things inside

I've very rarely seen a music/audio file with a .mp4 file extension, it's almost always .aac or .m4a

MKV is often thought of as a container format for videos, while of course it can do other things people expect that it's a video. A file extension specific to a codec however I believe is more thought of as the codec itself than a container format

Animated vs not animated is something that might justify different extensions, since it is justifiable that some software can only deal with still images, and also for an end-user there is a clear difference between animation and still.

That is a good idea actually, although using a JPEG with a clip-path or SVG is likely more efficient with still great browser support.

Which browser supports JPEG with an 8bim clip-path?

None afaik

I meant CSS clip-path

you can also embed the jpeg inside an svg which has a similar feature or have the svg reference the jpeg file

CSS clip-path is a workaround, as soon as someone downloads the image the alpha is gone

SVG is a bloated format that increasingly nobody except browsers dare to open

But I can't tell from MKV what will be inside, it could be a lossless format, it could be hundreds of different video and audio codecs, there could be subtitles, images, covers, etc. (I can only think with a certain probability that it's a video, but the same for JXL, it's more likely to be an image)

You're right, and trying to put all those details in a file extension would be a big pain, however it's also more generalised than an image codec (an image codec doesn't have sound or subtitles etc)

It may be more useful for animation (but it was abandoned in both PNG and AVIF, APNG and AVIFS are not used)

I think it would be useful to have metadata to put some kind of fidelity claim in (lossless, encoder version + distance target used to encode, whatever), and have an easy way in applications to check that metadata. But I wouldn't overload filename extensions to not just mean "this is something that a jxl decoder can decode" but also claims about fidelity and maybe other useful workflow information

I'm only talking about 4 extensions at most, not one for every setting 😛 (jxll lossless, jxla animated, jxlla lossless animated, jxl other)

I'm generally in favour of a separate extension for animated JXL, not so much for lossless

.jxif. And then leave open for interpretation how to pronounce it

I'm all for having an easy way for people and applications to know what variant it is, be it file extensions, metadata, mime types, magic numbers or something else. As long as there's at least some way of knowing as a minimum

I'm just a fan of file extensions because it's so widely supported and understood. If decoders enforced it there wouldn't be as much confusion or deception about it either, but I understand why decoders don't care

How is an encoder supposed to know if the input you're giving it is lossless or lossy to begin with?

My opinion is that on the user side for convenience it is better to use something like lossless.jxl, animated.lossless.jxl, it does not give any guarantee, but the extension also does not give it

Is a losslessly recompressed jpeg something lossy or lossless?

You can't, but encoders/decoders can at least require the right extension

e.g. if you're encoding a jpeg don't allow the user to set the file extension as a .flac or something silly

Also can be a very wild mix of different types, also in JXL in theory can be different layers or areas encoded in lossless along with lossy

on the decoding side, you can't know for sure if the source material is lossy or not but you should be able to tell if it was lossy encoded with a lossless file extension

In that case, personally I would give it the more general file extension. If it's all lossless, it's the lossless extension. If it's got some animation in it, it's the animated extension, etc...

The encoder gets an input and it produces an output. It knows if it is doing lossless or lossy compression, but it doesn't know if the input was lossless or lossy to begin with.

What if its input is the same format as it's encoding to? E.g. JPEG to JPEG

The jxl encoder only produces jxl output

The jxl decoder can produce various output.

Are you suggesting it should not be allowed to decode to .png if it has reasons to suspect that the jxl was lossy?

Good question

I see how that could become a problem now

Because then you're basically forcing it to introduce generation loss by using a "known lossy" format like jpeg as output

Yeah

This is probably the best way to understand why you cannot really tie the property of losslessness to an extension. It is a property of a workflow, not an inherent property of a codec.

I have a silly idea, not sure how useful it would be

The different extensions appeared mostly for the different formats that were mostly used for lossless/lossy/animation, people just adjusted it to their ease of understanding Btw, GIF was originally used mostly for static images (until PNG and Jpeg became more widespread)

Some people tend to edit lossy image files and when it comes to saving them they don't know what settings they should use to keep the quality similar to the original.

Would it be a good idea for the encoder to somehow figure out the right default for you that would give a similar perceptual quality to the original file without the user manually overshooting it?

By default it is almost so, with -d 1 it is very close to the original quality (without zooming) and it's not just the quantizer value as usual with other formats and encoders

Oh, nice!

So if I have a low quality jxl and change the brightness a bit or some other minor edit and then feed it back through the encoder with default settings, the file size will stay similar?

And this is more complicated, because then it will be necessary to read and change not the pixel output, but some encoder data

Also, a low-quality image doesn't always mean good recompression or compression with a different format, because the visual losses are summarized And from the encoder side of the image it's almost equal whether it's lossless or lossy with very heavy compression, because it "doesn't know" what the original was

Generally, in an editing workflow you keep everything lossless and higher bit depth. Changing brightness after lossy compression is likely to introduce visible artifacts.

Ideally, yes it should be lossless during editing. Some source material may not have that luxury however. In this situation, do you recommend saving it as a "lossless" (lossy in a lossless format) file before editing and then saving it as lossy at the final stage?

Yes

My question is: Assuming the input codec is the same as the output, could the encoder use some metadata or psycovisual analysis of the file to determine the best defaults?

And if so, would that be a good idea?

That seems very hard, especially if the editing may have introduced material with different qualities (e.g. text added on top of a photographic image).

If you edit, it's no longer any codec but just pixels

And I'm not sure it's desirable either... you'd be encouraging generation loss again.

Hmm, that makes sense

Say if someone wanted to overlay some opaque text on top of an existing lossy image. Could the encoder do a diff with the original and avoid re-encoding the non-text parts?

Or could the editing software request only a part of an existing jxr image to be encoded with new data?

that can in theory be done with multiple layers and/or patches... not fun to do though 😄 and no encoder that does it yet

Plz don't spam <#805176455658733570> with jxl stuff 😜

Whoops, sorry!

My web design teacher had a mix of GIF 87a and 89a files created in by obscure software for MacOS classic that we used in his class, it was the first time I saw GIF 87a in the wild lmao

Btw, modern image formats would be useful for 64k browser demos: https://youtu.be/FYyL_mEQWOM?t=160

you can do a so f*** smaller jxl decoder?

https://aomedia-review.googlesource.com/c/aom/+/133961 I see that the aom people interact a lot with you here huh? 😄

This is not necessary, this is a browser demo, so that all formats are supported as in the browser

ah, ok make sense

Also 4K Executable Graphics and I think some similar things can be done with purely modern image encoders (but in different ways), such as layering an easily compressible background and a normal image https://youtu.be/E1tp1wCeVZ0?t=979

<@!461421345302118401> I do not remember about Pingo, but ECT and WebP by default remove the invisible alpha, but visually it does not make any changes and it is not needed for normal images, it is not exactly lossy (if it is not some special textures for games and other technical images, where it may be necessary) Also to optimize in combination Pingo with ECT does not require additional scripts for parallel processing (if ECT is properly compiled for that), I would recommend this combination: ```pingo -sa -strip -nocompression *.png ect -9 --reuse --mt-file *.png``` Unless `-nocompression` requires some extra free space, but with these keys optimizers will not do double work, only what they do best, `-9` can be replaced by `-30060` for some improvement in efficiency, with more time. This combination is hard to beat in terms of speed/efficiency, for efficiency records there is a mod on ECT which one image can be optimized for several months

Pingo fiddles with invisible alpha pixels AFAIK. https://discord.com/channels/794206087879852103/805007255061790730/822888805547114547

Yep, I think it will be really good for combining photographic and vector portions. A photographic background could be compressed hf lossy and text/graphics layer on top compressed modular so that the text and vector art can be crisp and clean while the background data can be somewhat lossy.

Granted, image editors would have to implement such a solution... not sure they have much interest to atm.

Pingo (-sa -strip)

Pingo+ECT

WebP

But, also WebP in one of the applications through the official Windows 10 WIC decoder

The JXL art one is better.

this kind of "optimized" invisible pixels were quite expensive to encode with vardct (such horizontal stripes are cheap for PNG but not really for a dct)

that's why we do something else instead (see https://discord.com/channels/794206087879852103/805007255061790730/822890261369716736)

<@!111445179587624960> thank you very much 🙂 I prepare use jxl on game asset(drawing content), could you teach me about this case(special textures for games and other technical images)?, I only know lossy alpha will get some issue, keep alpha lossless should be safety. look like pingo and pingo + ECT don't have any alpha issue on dice image case, but i still worry some special case. example: image.png => pingo -s0 -nosrgb -nostrip -quiet => oxipng -o3 --keep iCCP, sRGB -t 12 --quiet RGB24 or RGBA32 => jxl(vardct) => image.jxl PAL8 => jxl(lossless) => image.jxl // when png need use, decode to png image.jxl => image.png

I don't think that optimizing an invisible alpha will be a problem for images intended for viewing, for textures it is sometimes used as additional data

<@!111445179587624960> for textures content like unity3d or Unreal? I prepare use on RPG MAKER(VX ACE, MV) and renpy.

Not really, they usually use other formats, not PNG, but in some games for specific uses

If I am not mistaken Minecraft uses PNG and some Java games (but even if they use PNGs, they don't always use invisible alpha)

<@!111445179587624960> So I shouldn't worry optimize invisible alpha and bit transform(to 8bit)? I test some pingo optimize png on those engine(RPG MAKER(VX ACE, MV), renpy), that png still work fine 🙂

Yep

ok, Thank you very much for your help <@!111445179587624960> 🙂

> 3.1 MB screenshot

how to compare butteraugli and xpsnr? https://github.com/fraunhoferhhi/xpsnr

butteraugli(XYB) xpsnr(yuv)

xpsnr looks like a poor man's / easier to implement butteraugli, attempting to model contrast masking but still operating in YCbCr (which is perceptually not that good) and allowing easy backgrounds to compensate for getting hard foregrounds wrong

VVC will use xpsnr, I think AV1 use butteraugli tune is a good idea 🙂

<https://encode.su/threads/3610-Zpng-zstd-based-lossless-image-codec> <https://github.com/catid/Zpng> One of the reasons why I also added uncompressed PNG + Brotli (and this at least has some conditional support in browsers)

But, I don't see the point of improving the old formats when they won't be compatible anyway and it would be better to add a completely new format (with much more features and improvements)

that's indeed the thing: if you need to upgrade software anyway, it doesn't matter much if it's an improved old format or a completely new format

right, the advantage of upgrading old formats (e.g. JPEG XT) is usually backwards compatibility / graceful degradation

Noticed after this news that Oodle compression is being compared to FLIF as well https://www.unrealengine.com/en-US/blog/oodle-now-free-to-use-in-unreal-engine-via-github

<http://www.radgametools.com/oodlelimage.htm>

http://www.radgametools.com/images/oli_compression_large.png

`But unlike other compressors that accept a trade-off for slower speeds, Oodle Lossless Image is still super fast - its decode speed is 5-10x faster than PNG and 200-500x faster than FLIF! It's just massively faster than anything else at these compression levels.`

The question is: does it actually reduce texture VRAM sizes as well?

Oodle has separate tools for textures and they are also used in many modern games, but to reduce the VRAM use there must be hardware support and this is more for regular images, which can also be used somewhere

I see.

I just want to see what are their testing parameters.

http://cbloomrants.blogspot.com/2020/06/oodle-texture-slashes-game-sizes.html

<https://forums.warframe.com/topic/1223735-the-great-ensmallening/>

Oodle dev, They forgot compare lolz

<@!826537092669767691> `JINT_DC_SCAN_OPT_MODE` is supposed to be 0 (`One scan for all components`) by default in mozjpeg, right?

Yes, I've recently changed it

`cjpeg`'s quick help says otherwise...

``` -dc-scan-opt DC scan optimization mode - 0 One scan for all components - 1 One scan per component (default) - 2 Optimize between one scan for all components and one scan for 1st component plus one scan for remaining components```

https://chromium.googlesource.com/codecs/libwebp2/

<https://github.com/mozilla/mozjpeg/blob/master/cjpeg.c#L190>

Ugh, I need to delete `cjpeg`.

NOOOOOOOOOO

This is our only way to create highly optimized JPEGs. We'd be screwed without this tool!

hello I am having lots of trouble with colour correction in PNG but then I realized I was in a server of people that probably know more about this than I do (and I am very inactive on it) I was making an animation about PNG because circumstances, but I just can't seem to find enough information to figure out how the `cHRM` chunk works apparently decoders can find the Y value of the red, green, and blue points in the xyY colour space when you only have x and y. Doesn't say _how_ anywhere I looked though. and I sort of maybe understand the rest of the process not sure, so if somebody had an explanation it would be helpful (also ping me if you have a reply because, like I said, I am not active)

I think the Y is implicitly normalized to be 1.0, no?

<@604964375924834314> probably knows better than me

this seems to be it: https://sourceforge.net/p/dispcalgui/code/HEAD/tree/trunk/DisplayCAL/ICCProfile.py#l6379 https://sourceforge.net/p/dispcalgui/code/HEAD/tree/trunk/DisplayCAL/colormath.py#l1591

I'm testing JPEG XR, I've just compiled binaries for Windows (both 32-bit and 64-bit, `-O3` optimized). Check if they work for you.

If you don't believe me, you can download the source code yourself: https://jpeg.org/downloads/jpegxr/jpegxr-ref.zip

Download Orwell Dev-C++ (quite lightweight IDE) with TDM-GCC pre-configured: https://orwelldevcpp.blogspot.com/

and the homepage where you found this link

Load this `.dev` file into the same directory as unpacked source, open it, compile yourself and enjoy 🙂

but how to specify quantizer

Compilation instructions for Linux are much simpler, just run this code: ```bash sudo apt install bison flex make```

i don't understand anything about the parameters

For what?

jpegxr-x64 -h

jpegxr-x64

You don't need `-h`, just run it without any arguments and it will print you help

And I don't understand this either 😆

At least not yet, I have to look into this further

This tool doesn't understand PNG files, you have to use raw files, TIF, PNM or RGBE. I recommend TIF, it's the easiest to convert to on Windows.

JPEG XR is not that great

It's somewhere between old JPEG and J2K

Microsoft abandoned the project, so there is only this half-baked tooling

my limited experience with it was not encouraging at all

sadly, I think some are confusing us with it

Unfortunately I have to use it to re-create this comparison from scratch:

https://upload.wikimedia.org/wikipedia/commons/2/20/Comparison_between_JPEG%2C_JPEG_2000_and_JPEG_XR.png

Unfortunately it's GFDL'ed and I can't upload any more derivative work based on it to Commons...

So I have to grab the original source panorama:

https://upload.wikimedia.org/wikipedia/commons/archive/e/e6/20180512102522%21Paris_Night.jpg

And redo everything myself. Fortunately it's dual-licensed GFDL and CC-BY-SA, I can use the latter and upload my version under CC-BY-SA.

You can use cloudinary to produce jpeg xr

Nice, thanks!

Why support xr?

Here's what I've done so far. JPEG 2000 and JPEG XR weren't touched yet, but everything else (including the "Original" pixel-exact crop) was made from scratch by me. Texts were re-done with Arial 32 pt. and guide-aligned. I picked the very best settings for both encoding AND decoding, e.g. the MozJPEG with PSNR-HVS trellis tuning was too blocky after normal decoding, so I had to decode it with Knusperli... thanks Jyrki 😉

res.cloudinary.com/jon/image/fetch/q_70,f_wdp/[URL]

I wish Knusperli was the default decoder everywhere... I'm that type of guy that'd sacrifice speed for maximum quality possible.

res.cloudinary.com/jon/image/fetch/q_100,f_png/http://res.cloudinary.com/jon/image/fetch/q_70,f_wdp/[URL]

The JPEG XR executable above both encodes and decodes 🙂

Ah ok

I can't go below 13.2 KB and I need 9.16 KB... 🙁

This comparison image is very useful, thanks, Ziemek. Do you think it would make sense to include standard JPEG too (libJPEG?), because MozJPEG is likely so much better-looking, but not widely popular?

I'm trying to squeeze out the best of every format, both encoder- and decoder-side. For example MozJPEG is the best JPEG encoder and Knusperli is the best JPEG decoder, so I used them in tandem. JPEG 2000 is going to be crazy, because there are multiple encoders and I have to try them all to get the best encode.

Kakadu is the best one

Ok, so I'll start with that one

But I'll still try other ones, because I'm curious 😛

<@!794205442175402004> which JPEG XR encoder does Cloudinary use?

There is only one, afaik

Why so small? They all look ugly at that size and people caring about their images shouldn't use such low bpp.

Original comparison (that I'm trying to recreate) was using 9.16 KB, that's why. And such low bitrates allow us to "see" better the internal "guts" of the codecs.

That's new for mozjpg <:Thonk:805904896879493180>

```CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message): Could NOT find PNG (missing: PNG_LIBRARY) (found suitable version "1.6.37+apng", minimum required is "1.6")```

Does anyone have an idea why it doesn't want to compile even if I have the supposedly correct dependency?

that seems like a version parsing bug (with a confusing error message)

you might be able to get around it by setting PNG_LIBRARY manually in CMakeCache.txt, not sure