JPEG XL

Like when he calls new instructions from Intel useless, which then end up being used by tons and tons of software and actually very useful (like CMOV, or AVX512)

Incidentally, CHERI would allow for what Torvalds wants, without any of the issues of monolithic kernels. Different parts could still talk with each other however they want, but you'd have perfect control over which part can interact with which other parts and have this be enforced.

I would still use software even if it was written by Satan himself, as long as there's no history of sneaking malware into it.

In fairness, intel abandoned AVX512 for some kind of variable width revamp. Linus was technically right on that front because now only AMD cpus have access to its instructions, specifically, and who knows if future AMD cpus will. Abandoned instruction sets are such an awful thing

no. AVX512 is too big for small cores, so Intel is making a 256-bit version for regular consumer CPUs. But AVX512 is going strong on servers. And since AMD isn't doing anything like big.LITTLE, they don't need to care about that and can put AVX512 in everything. Intel's biggest misssteps was treating it like some special feature for servers, instead of getting it onto consumer products.

But what Linus said was that AVX512 is basically useless for anything other than benchmarks, which is trivially false regardless of whether it's worth the die area to implement it.

Ah, I wasn't aware it was still on server CPUs. How annoying

I hate big.LITTLE so much ughh

AVX10/256 and AVX10/512 will be in future products, and the latter is the same thing as AVX512 just with a bunch of the various extensions to AVX512 made into baseline defaults.

wasnt amd's avx512 also just 256 x 2

The original AVX10 spec also included AVX10/128, but they thankfully removed that 😄

Oh, I also wasn't aware AVX10 wasn't variable width. I assumed it was like ARM's vector extensions

It is, but due to weird CPU die power management shenanigans it's actually slightly faster than Intel's implementations

Intel had this nasty issue where it required underclocking the CPU every time you ran it

Part of the reason why they took it off the desktop

Zen 4 has two 256-bit FMA units, and four 256-bit non-mul ALUs

So you get 1.0 512-bit FMA ops per cycle

plus whatever other misc vector ops you may be doing

only for the first generation or so

they fixed it pretty much immediately

it just makes the newer instructions available when you use the 256-bit registers instead of the 512-bit ones.

Oh I see

I think it's very easy and it looks very bad to just randomly call some random person a fascist without providing any explanation or evidence or in a context where they can't explain themselves.

Vector formats WMF/EMF were the main formats used for cliparts in MS Office. Curiously, MS Office online doesn't seem to support WMF/EMF images.

Apparently iOS 18 encodes HEIC images in a new way, which is incompatible with libheif, so nothing outside the Apple ecosystem can decode those new images. Oops!

New exclusive picture sharing feature, update to iOS 18™️ today!

HEIC, the image format nobody asked for.

HEIC, the image format not for the rest of us

Interesting. Are they deviating from the HEIF/HEVC standards, or staying within them but just using stuff that libheif doesn't implement?

I don't know at this time, but that is what's being reported by people who are trying to iOS 18 beta

Can you find a sample file?

I asked for one, we'll see.

It seems that multiple versions of jpegtran and tools based on them produce non-compliant EXIF jpegs. jpegtran will automatically insert JFIF marker even if there's already EXIF marker present. However, both EXIF and JFIF specs require their marker being the first at the beginning of the jpeg file. So, if EXIF marker exists in the jpeg file, JFIF simply cannot be inserted, because there's no room for it.

Has anyone found any mention of JPEG XL from WWDC? This is the only one I've found so far: https://developer.apple.com/wwdc24/10177 I noticed they were doubling down on HEIC for Apple Vision Pro stereoscopic images and spatial videos are built on top of MVHEVC.

"And a spatial photo is a stereo HEIC, with two images in a stereo group, along with some spatial metadata. To understand how to read and write these files, we have two sample code projects and an article, on developer.apple.com. Now, let’s take a deeper look at the spatial metadata, common to both file formats. Spatial metadata comprises of a few things. There’s the projection. That defines the relationship between objects in the world, and pixels in the image. Spatial photos and videos always use the rectilinear projection." from here: https://developer.apple.com/wwdc24/10166

I haven't heard back yet, but I upgraded my iPad to the beta and took a photo, and it opens just fine on Linux 🤷‍♀️

Is a spatial photo still an image?

"Spatial photos and videos are stereo media with additional spatial metadata: A spatial photo is a multi-image HEIC file containing a left-eye image and a right-eye image, a stereo pair group, plus spatial metadata."

so... a 3d images

jxrlib is pretty mature, and the JPEG XR format hasn't been altered in ages.

I've heard the encoder in it is pretty mediocre

that doesn't seem right, it definitely supports writing and includes `JxrEncApp` as a command line encoder

there's random mistakes all over Wikipedia, this is probably just a case of that

I remember one time I was on a Wikipedia page/article about something related to MS Windows and the version of Windows 10 it listed something as first appearing in was just completely wrong

just fix it yourself

also looking at the history it looks like this page was destroyed

yeah, sometimes there’s just plain incorrect stuff (see e.g. antimuscarinic effects before my fix: https://en.wikipedia.org/w/index.php?title=Loratadine&oldid=1220582216#Adverse_effects after my fix: https://en.wikipedia.org/w/index.php?title=Loratadine&oldid=1223946960#Adverse_effects)

I was just on the wiki page for GIF and a lot of the descriptions say "In 2013 there are plans to release webp", definitely in need of an update

When I first heard of avif and jxl I was looking forward to both of them becoming adopted and popular. But after what Jim Bankowski did, telling Facebook and Shopify and Intel that there's not enough interest for jxl to remain in the browser, while at the same time being the same person who is responsible for breaking youtube thumbnails in firefox to force them to add support for webp, after that BS and hypocrisy I am extremely anti AVIF :(

At this point I actually want avif to go the way of j2k

AVIF isn't patent-encumbered the same way JPEG 2000 is. And the companies part of AOM have more than enough money to defend themselves.

I thought the reasons j2k failed is because it was very slow compared to existing codecs while not a significant enough jump compared to them either.

Even though it had a much more graceful quality dropoff at low bitrates compared to jpeg

I was not even aware that j2k was patented

Saying you want AVIF to fail is somewhat of a pointless gesture as AVIF is just AV1, which is here to stay. It requires even less effort to maintain than webp

It can’t really completely “fail” because of what <@334064731604385814> said but JPEG XL still has a chance to become more popular and widely used

Once web browsers and popular image editors support JPEG XL, camera manufacturers might start supporting JPEG XL. JPEG XL is way more suited than AVIF to replace JPEG throughout the entire pipeline.

That's nothing to do with the format itself, tho?

I don't think youtube thumbnails were broken in firefox, do you have more info about that? I myself thought youtube was pushing webp since its thumbnails break if you disable webp support in chrome devtools, but the thumbnails do actually work in browsers without webp support (so I guess they're just not using the proper way to detect webp support, i.e. they probably look at user agent strings instead of accept headers).

JPEG 2000 is not patent encumbered, or at least not more so than JPEG is. Even if it was, the year 2000 is more than 20 years ago so....

I think AVIF is a great GIF replacement.

It would be cleaner if Chrome would just support video containers in an <img> tag, like Safari does, instead of requiring everyone to jump through hoops and wrap their AV1 payloads in AVIF.

J2K didn't really fail, it is the main codec used in digital cinema and in medical imaging. But yes, those are niche applications, and it did fail to get the ubiquitous support that JPEG enjoys. The main reasons for that are, imo, the following: - No good FOSS implementation available. It took until 2004 until there was any FOSS implementation (JasPer), and it was a very slow implementation. It took until 2014 before there was a FOSS implementation that was both conformant and reasonably fast (OpenJPEG). When the only decent implementations are proprietary, widespread adoption is unlikely imo. - For most 'normal' use cases (like web images or consumer photography), the compression performance of JPEG 2000 is not spectacularly better than that of a good JPEG encoder. So in practice it was mostly slower but not really better — why would you bother? - JPEG 2000 has a LOT of functionality, which is nice but also makes it hard to make a full implementation.

I can imagine AVIF fans getting somewhat offended by the insinuation that this is all it can be

I think it would be an effective sentence if one wanted to do that on purpose

(I don’t think you did)

Any video codec is a great GIF replacement, really. And AVIF can be useful for still images, I suppose, but only for a fairly narrow use case imo (the lower end of the web delivery quality spectrum, mostly).

It's just a heic container with av1 payload and heic is kinda a dumb format.

Correct

https://github.com/webcompat/web-bugs/issues/13886 https://www.reddit.com/r/firefox/comments/7g0xor/firefox_has_stopped_showing_youtube_thumbnails/

The container is HEIF. HEIC is when the payload of a HEIF is HEVC (technically it has to conform to the Main profile, so 8-bit yuv420, too to be called HEIC; the 10-bit variant is called HEIX).

AVIF uses the MIAF container, which is a subset of HEIF, which is an extension of ISOBMFF.

That was one specific day where YouTube was broken, the next day it worked again. I don't think this was intentional.

And ISOBMFF is a fancy name for MP4 right?

or MOV

Well, intentional or not, YT was sending webp thumbnails to firefox for whatever reason, and I think it reoccured several times, and I think it was a big factor in them deciding to add support for webp, surprisingly even long before safari did.

For some reason sites were breaking in firefox but not in safari.

Almost like it was intentional or something.

web compatibility issues may be rare now, but in the past they certainly were not.

Yeah, basically just PNG chunks without the CRCs 🙂

I think the main factor was Chrome finally supporting APNG so Firefox could support WebP in response 😆

Using Paeth filter for the first row of pixels in PNG is an interesting choice.

Apparently it's this issue: https://github.com/strukturag/libheif/issues/1190

I'm not home at the moment, but yesterday a friend tried to use Discord's server profile feature. For some reason, the file got corrupted and resulted in a 127 byte WebP image with a grid pattern. I'll upload it here later since it's accidental WebP art haha

Looks like HEIF is becoming the new TIFF...

and not in a good way

274 bytes, but still :P

Even has alpha

Everything becomes TIFF if you look hard enough

You aren't truly TIFF unless you have really absurd flag names for various things.

Any sufficiently complicated image container format contains an ad hoc, informally-specified, bug-ridden, slow implementation of a quarter of TIFF

Ive always hated tiff stupid names for stuff, why is associated alpha's flag called `ExtraSamples`

TIFF is what happens if you define a format based on what is convenient for an encoder

Like: whatever memory layout you're using for your images, chances are you can just write some TIFF headers and dump it to a file.

I'd say there's some value in preserving many layouts

well, at least we have a real alternative now

do we?

Big endian, little endian, planar, interleaved, whole buffers or tiles or slices? 0 is black or 0 is white? RGB or BGR? Don't worry, whatever you happen to do, TIFF has you covered.

Encoder convenience comes at the cost of decoder inconvenience though.

entirely fair

at least it didn't make the mistake of limiting itself to one alpha encoding

there isn't really much we need now outside of JXL and EXR, most bases are covered

(and yes, I have tasted this myself, I wrote a (non-compliant, obviously) TIFF decoder in python (never again) for a school project a few years back and it barely worked)

the format with the pointers to the data is absolutely bonkers

I like having bitstream expressivity so you have degrees of freedom when compressing, and all functionality is covered. But I don't like having many options that are basically equivalent in terms of compression or functionality. Just pick something and make it the convention.

Blender's .blend files are basically straight dumps of Blender's in-memory data structures, and you can still open 20 year old .blend files in modern Blender.

TIFF even allows the f'ing _headers_ to be either big endian or little endian

how the fuck

MM :P

it writes out a detailed description of the structures, which Blender has a parser for. So it's the same thing, decoder has to be way more complicated.

TIFF: the image format for literally every use ever

that's smart

even geotiff

I like TIFF, but it is like, the 15 competing standards meme in an image format

alpha encoding and chroma location are examples of things you can't just fix with some simple reordering in the encoder, some things just require a lossy conversion

Though modern blender ofc won't *have* all the same structures as old blender, features have been removed. In that case, Blender can still parse that structure and see how it's linked to other stuff, just can't use it. The GUI will just be like, yeah here's a "foobar" structure with these members.

"This swiss army knife contains a pipewrench and a soldering iron"

it's a clever design, maybe a bit too clever

TIFF also went through this weird trajectory of being 'owned' (in terms of spec authority) by Adobe, then being 'released' from being a proprietary format and becoming an ISO standard, and then becoming something 'owned' by Adobe again. If I understand correctly.

i love format politics

Yeah when it makes a semantic/functional difference it makes sense to support multiple things. We also have both kinds of alpha in jxl.

But supporting both min_is_white and min_is_black, big endian and little endian, etc: that's just silly imo. Way easier for an encoder to just take what it has and write it in whatever way is the convention, than for a decoder to have to deal with all possible things.

this is a large reason why I hate cmyk lol

I agree

I actually have no clue how inkjet printers deal with this, but IMO, the amount of actual ink flowing out of the head ought to be controllable (and not abstracted over a generic color space), that would move complexity to the computer, but it would also allow for good color management (and bad color management, unfortunately)

Fundamentally I think CMYK should not be needed in image authoring. It should be the task of the printer to figure out how best to reproduce a given image, not the image author. Sure, authoring tools can help you to do things like gamut proofing, but editing directly in CMYK feels like it's too low level and trying to solve a problem at the wrong system layer.

that seems agreeable, but actually converting to the printing device's particular color space should be handled by the OS printing abstraction (and not by the printer) (yes, this means the OS needs to do color management, but desktop computers are more powerful than whatever tiny thing printers have)

If printers want to move on to 7-color CMYKOGV, just let them do that. It should be done at the level of printer drivers or even inside the printer itself, and you should be able to just send an RGB image in some gamut to a printer and it just does its best to reproduce the colors, according to the given rendering intent.

Printers have tendency to darken everything. I was using inkjet printers from two manufacturers and they both used very crude conversion formula from RGB to CMYK, like: rgb (255,255,0) becomes full density yellow ink rgb(255,0,255) becomes full density magenta ink rgb(0,255,255) becomes full density cyan ink If you colored a row of cells in Excel with rgb(0,255,0) it became dark green and the paper was wrinkling how wet it got.

Does TIFF support paletted planar format used in EGA and VGA? PCX does 🙂 This format uses four bit planes, each of them is 1 bit monochrome. With the default palette, the planes correspond to blue channel, green channel, red channel and intensity The latter chooses between darker and lighter version of the color.

I think it does, at least it does support 4-bit palettes.

So that's just interpreting RGB with 0-is-black as CMY with 0-is-full-ink. That's a very poor way of doing it, not even trying to use the K and avoiding to use more ink than the paper can handle. Let alone taking into account that the RGB primaries are not at all identical to (M+Y), (C+Y), (C+M), and that inks combine in much more complicated ways than light does.

I didn't see anything that would suggest 4bit planar in TIFF. 4bit chunky is nothing unusual. 4bit planar is closely related to EGA/VGA hardware so it was commonly used by programs and games in DOS, but it is only useful if the software interacts with hardware directly. CGA format is also interesting. It is 2bit chunky, paletted, but it is interlaced so odd and even lines are stored separately. Anyway. couldn't libtiff be used to decode any compliant TIFF image?

I know, right? Black ink seems to be used only for full black or for grayscale. And there is no doubt that inks printed on paper have completely different response curves than electronic displays.

Baseline TIFF is one thing, there are also lots of extensions and I dunno how well libtiff covers those, but definitely not everything.

Oh, 4 bit planar with the 1 bit for intensity would indeed not be supported by TIFF, I think. I think you can do planar 1-bit RGB, and I suppose you could have a 1-bit extra sample, but to make it be interpreted as an intensity modifier, I don't think you can do that — but maybe it is possible, e.g. interpreting it as alpha with an unusual range so 0 means 0.5 and 1 means 1, or something.

(and then having an implicit black background somehow)

In practice, the RGBI scheme is the default palette but if using a custom palette, the four bits become an index to the palette.

Also the default VGA palette is not strictly RGBI.

How weird to use planar bitplanes for palette indices. I wonder why EGA/VGA did that, it seems rather inpractical

It was done because in 16bit systems, the memory could be accessed only inside 64kB segments. The video memory was mapped to the CPU address space as well. 640x480 4bit does not fit in 64kB so it had to be split somehow. The solution was to split it to four bit planes that overlap inside the same address space. Access to the individual bit planes can be tuned on or off in the control register, so one or more bit planes can be written at once. That was useful for rendering text on screen in graphics modes, for example.

One would just set the bitplaness according to the desired color and render the characters.

Also, I suppose, splitting pixels into bit planes simplified the circuity pushing the pixels to the monitor. Early graphics adapters were implemented entirely in logic.

wat

Meanwhile, AVIF decoding in Windows 11 is still broken.

MS Edge seems to be OK, but MS Paint and Photo App show incorrect colors.

considering the hatred that webp is getting, I think jxl will never take off

google tried to make it a thing, and in the eyes of many, still failed

WebP has it's reputation because of it's slow adoption, JXL is already in most major places (bar Chrome) with Windows hinting at adding it soon too

webp has its reputation because most implantations were massively buggy and some still are

I still to this day occasionally find webp images that render incorrectly depending on the app

I mostly see/saw people complaining about not being able to open ones in e.g. photoshop, but perhaps jxl will fare better

well I would say it already has comparable adoption in terms of applications lol

Yeah, Adobe are some of the people pushing for it, even if they're a bit misguided in their implementations *ahem DNG*, but it's also in multiple image libaries which immediately expands support to any application using them

Well, there are still websites focused on hosting images that don't allow uploads in WebP.

https://www.threads.net/@stopsatgreen/post/C8MyOUDI6F6

oof

I was quite surprised when I found out that WebP uses RIFF file structure established and used by Microsoft.

i guess it's a simple TLV-based container

so it's a reasonable choice

licensing shouldn't be a problem for such an old/simple format

also i think all patents would have expired

it would be way weirder if they used ASF for it

Licences wouldn't be a problem, RIFF is based on IFF format from Amiga.

Using RIFF header seems kinda unnecessary as WebP doesn't utilize any RIFF features like LIST for grouping subchunks or INFO for metadata.

There are now three RIFF based formats for motion pictures - AVI, ANI and WebP.

I was checking some release notes for Unreal Engine 5.4, then I noticed some dithering in one of their videos... Lo and behold, the entire thing is using 5fps GIFs limited to 3 seconds because of filesize. With some juicy metadata too https://dev.epicgames.com/documentation/en-us/unreal-engine/unreal-engine-5.4-release-notes#clonersandeffectors https://d1iv7db44yhgxn.cloudfront.net/documentation/images/fc598aec-4852-47e5-86a0-de15406860d2/image_2.gif

Nothing quite says 'The future of graphics' like that

> "Hey guys, look at the next generation of graphics" *Shows new features using an image format from 1987*

GZDoom recently added support for graphics in WebP and QOI formats.

<@365045091951312897> added them about a year ago along with JXL support https://github.com/ZDoom/gzdoom/pull/2131 https://github.com/ZDoom/gzdoom/pull/2124 https://github.com/ZDoom/gzdoom/pull/2133

But JXL was pulled due to broken vcpkg files https://github.com/ZDoom/gzdoom/commit/53d8a5bb2cb3b4f5576d9286731ad5a4bd972949

iirc JXL support was also dropped since it was considered a little bit too early too add/keep it plus the binary size being a bit too large for libjxl

I think the vcpkg stuff ended up getting fixed at some point, forgot if it was on libjxl's side or vcpkg's side but I remember fixes being proposed for both sides

Interesting. I wonder if decode only version of libjxl can be compiled and if so, how much lighter the binary is.

Or perhaps some independent decoding library might be a better solution.

There is a libjxl_dec compile option that does that. I think that one is about 200k on Android, iirc.

I suppose 2 bpp pngs are pretty rare.

you mean 2-bit grayscale? Yeah I suppose that must be one of the rarest kinds of pngs

though 2-bit palette images might be a bit more common, like for CGA screenshots or something

CGA screenshots could be 2 bit palette as long as they are optimized.

AFAIK there are not many programs that can write 2 bit PNGs by themselves.

I guess most wouldn't bother to implement that specific bit packing, no.

It is an emulator, the pixels in CGA framebuffer are already conveniently packed.

There was a discussion about emulators using JXL patches to essentially re-render game frames using the sprites, but no one's taken up the challenge yet

CGA doen't have sprites but patches could be used to render text modes.

The heat must be getting to me, for some reason I was interpreting CGA as Color Gameboy Advance... Whatever that would mean... Nevermind

No problem, patches would be useful for good old MS-DOS as well.

Regarding grayscale PNGs, these must be very rare in general as grayscale images are often encoded as paletted.

That's it, paletted images where the palette is 256 steps from rgb(0,0,0) to rgb(255,255,255).

I guess one reason could be that GIF and BMP don't support grayscale at all.

Jesus christ. That page loaded 113 MB of images in total.

Someone forgot to tell them what an mp4 is?

epic serves its web content like its running on intranet

I was going to say they didn't even try to optimize the gifs but these can't be optimized. Lossy LZW decreased the file size significantly, though. With such distracting dithering, a little bit more noise won't hurt.

Running that GIF through this reveals it even has Adobe edit history metadata too, so not only did they not bother optimising, but it's actually even worse than just a plain GIF https://compress-or-die.com/analyze

Form 2953991 bytes to 1905150 bytes using `gifsicle -b -O3 --lossy image_2.gif`

gifsicle removed the XMP tag automatically

Could save even more by trying different values for lossy.

Most modern programs always write GIF89a even if GIF87a would do. Ancient software often supports only GIF87a as it doesn't understand transparency and animation. Luckily, gifsicle automatically converts non-transparent, non-animated GIFs to GIF87a.

why would someone ever use GIF for such images in the first place?

As I said, ancient software. It's fun playing with historic computer stuff.

ECT for some reason likes using PNG filters Up and Paeth on the first scanline.

<@219525188818042881> gonna move here to not pollute <#1256302117379903498> <:KekDog:805390049033191445> 200 bytes smaller than befoer

Nice. Gotta make it even smaller™️

This toolset for APNG doesn't seem to be able to produce pngs under 8 bpp. https://apngasm.sourceforge.net/

I was testing this on black and white 1 bit pixel art and the best it could do was 8 bpp palette. Too bad ECT doesn't support APNG.

Oxipng does to a limited extent

pingo does as well

oxipng only compresses the first frame and the rest is just copied. pingo still produces just 8 bit palette.

APNG has a serious flaw. It doesn't support local palettes. GIF using local palettes needs to be converted to 24 bpp APNG and the file size of the resulting APNG is about the size of the original GIF.

It's a shame Mozilla didn't think local palettes were a good feature to keep. It kind of invalidates the point of apng replacing gif.

They thought it's not necessary because anybody can just use 24 ppp or 32 bpp.

same for `ect --reuse`

well the "only 1st frame compression"

I'd expect at least zopflify all deflate streams in the file.

yeah, but unfortunately ECT's dev don't want APNG support https://github.com/fhanau/Efficient-Compression-Tool/issues/130

<:FeelsSadMan:808221433243107338>

ECT is using zopflipng internally so I suppose as long as zopflipng doesn't support apng, ECT will not as well.

Has anybody any idea which compression library pingo uses? The source code doesn't seem to be available. The fact that there are several different projects called pingo doesn't help.

I've seen on encode.su forums that a image optimizer was stealing code from others and just do small changes but can't remember if it was pingo 🤔

APNG tools are not that great in general. The available tools will encode animations like this using 8 bit palette.

makes me think of flipnote studio <:KekDog:805390049033191445>

wait, it is from flipnote studio x)

Interesting, I didn't know the app. I think i found the gif on some forum years ago.

Dumb idea I've had What if there was a codec that just had a byte to identify if image was 24 or 32 bit, then just the colors for every pixel in hexadecimal with no spacing or anything. It would use the information from the first byte to identify where each pixel begins and ends. And then it's compressed with something, 7z or whatever would work the best in this case

You also need to specify the image dimensions.

Oh yeah, I should've thought about that

PAM format is probably the closest to this idea. It has a simple text header followed by raw bytes of pixel data.

bmp with bitmap

tiff

TIFF can be very complex. There are just too many options how pixels can be encoded.

BMP can be tricky as well, if you consider the full spec and not just the version from Windows 3.x

And the simple BMP doesn't support alpha.

🍕

<:KekDog:805390049033191445>

I wonder why, do they think that it's not popular enough? 🤔

It's actually used in some popular places. For example, Steam uses it for all animations here https://store.steampowered.com/points/shop/

I would tell that I see it more often than animated WebP

I t would be too much work because the underlying zopflipng doesn't support APNG. Perhaps this will change as APNG is becoming part of the official spec.

That is what we call an "uncompressed image buffer" 🙂

so just ```cpp fwrite(image.buffer, image.width*image.height*image.bpp/8, 1, output_file); ```?

Some header for width/height/bitdepth/nbchans and then that, yes

Title screens in DOS games were often made as raw pixel arrays that were simply copied into video memory. The images were often stored uncompressed in the game files. The fancier ones used RLE compression.

JXL supports the appropriate bit depths for old PC graphics. 2 bpc for CGA/EGA and 6 bpc for VGA/MCGA

2 bpp for CGA, 4 bpp for EGA, 8 bpp for VGA, iirc?

That's correct. These are all paletted. In EGA and VGA, the palette can be freely changed. For JXL, the color indexes are expanded to RGB pixels according to the palette. The size of VGA palette entry is 18 bits, 6 bits per channel. The size of EGA palette entry is 6 bits, 2 bits per channel. CGA can actually do 16 colors in text mode, so the video hardware is 4 bpp. The default 16 color palettes in both EGA and VGA are equivalent to the CGA 16 colors.

animated webp does a proper 1-bit encode btw, the resulting file is much smaller

<:KittyPizza:1147750033018605680>

Is the site available anywhere

```format error: incorrect number of xref entries in trailer, repairing warning: trying to repair broken xref warning: repairing PDF document```but I checked and yeah it's lossless <:FeelsSadMan:808221433243107338>

This is not problem with APNG, it's a problem with tools. I know WebP is much better than APNG but sometimes I can't use WebP.

That's annoying, `apngopt` is splitting IDAT and fdAT chunks into several smaller chunks.

yeah, since APNG was not part of the spec for many years, there was no desire to really implement quality tools

I couldn't even find any tool that would do a very simple task. Split APNG to individual frames and combine frames to APNG, without touching the compressed data.

This tool is very useful for hacking PNGs https://entropymine.com/jason/tweakpng/

Only way I can think of would be using tweakPNG or something to manually replace and merge the IDAT chunks

Okay I should've scrolled down an inch more....

That's what I'm doing now. Additionally I have to add/remove chunk numbers. APNG chunks are numbered. So yeah, TweakPNG and HxD are the tools for managing APNGs.

Anyway, `apngopt` does inter-frame optimizatios, which is good, but doesn't do the extra step to reduce bit depth in very low color animations. So the solution would be extract the frames and use dedicated PNG optimizer. Doing manual extraction is time consuming.

Also `pngout` has a very useful feature which I didn't see in other PNG optimizers. It can select a specific color type and bit depth and it will use it as long as it's lossless. This is especially handy for making sure all frames in APNG will be compatible.

I wonder how JXL in DNG with bayer encoding works...

I'll let you know in a week when I get the conversion tool to actually give an output

Here’s what I have

https://discord.com/channels/794206087879852103/1255149718078619662/1255150125559320727

<@238552565619359744>

Oh nvm you’re the one with me in that thread

lol

https://dolphin-emu.org/blog/2024/07/02/dolphin-releases-announcement/

Ironically an emulator website has the best practices, a looping av1 video

<@1072709049310785637> maybe look at this idk

lately, I find myself removing JPG artifacts from PNG in a weird way Let's say someone converts an ugly JPG to PNG (using djpeg-like), and sends only the PNG. There are noticeable artifacts near sharp edges/borders/etc, and to remove them I'm currently encoding the PNG to JPG (using `cjpegli -d 1`), then `jpeg2png` This works really well as I don't see anymore tha JPG compression artifacts (the quality can only be better, tested on dozen files), but that way of doing feels weird, no?

Hmm I've never really bothered to try it, but what about waifu2x (one of the many websites that offer it for free), no upscaling, and just JPEG noise reduction

Well, if you can match the quality, and the encoder, then re-encoding jpeg artefacts should incurr no loss, and then jpeg2png would work 'perfectly', so you're essentially cheating that system a bit

Most common situation is right click copy turning jpegs into bitmaps which are then pasted as PNG

wow, this works pretty well indeed But seems to be for anime content only 🤔

It comes with a few different models ranging from photos to art

<:FeelsReadingMan:808827102278451241>

This is interesting. I was trying to just use `cjpegli` for artwork but it seems to be blurring chroma too much. Isn't it a problem in this process?

in my samples at least I don't see any problem

and I zoomed quite a lot to perfectly compare source and "cjpegli→jpeg2png" image

Maybe give your sample? Mines are digital cover arts (anime-like)

It's doing similar desaturation effect like chroma subsampling around black lines but that also depends on the particular color.

Is lossless jpeg and Jpeg Ls different?

Jpeg-LL is the original lossless jpeg, Jpeg-LS was a later replacement for it, as far as I can find

Yes, lossless jpeg is basically the same as the DC coding of lossy jpeg. Not great in terms of compression. JPEG LS performs better — similar to lossless J2K: sometimes a little better, sometimes a little worse, in general quite good for photographic images (better than PNG) and bad for non-photo (worse than PNG).

I'm digging into the files right now... And somehow it seems worse than I expected...

I think they're storing the raw bayer grid as 16bit grayscale tiles, then re-assigning the color on decode

Scratch that, yet again I have no idea what they're doing

Here's the first tile from both bayer lossy and standard lossy DNGs Bayer ```[SubIFD] ImageWidth : 4032 [SubIFD] ImageHeight : 3008 [SubIFD] BitsPerSample : 16 [SubIFD] Compression : JPEG XL [SubIFD] PhotometricInterpretation : Color Filter Array [SubIFD] SamplesPerPixel : 1 [SubIFD] PlanarConfiguration : Chunky [SubIFD] TileWidth : 672 [SubIFD] TileLength : 752 [SubIFD] JXLDistance : 0.200000002980232 [SubIFD] JXLEffort : 7 [SubIFD] JXLDecodeSpeed : 4``` Standard ```[SubIFD] ImageWidth : 3952 [SubIFD] ImageHeight : 2960 [SubIFD] BitsPerSample : 16 16 16 [SubIFD] Compression : JPEG XL [SubIFD] PhotometricInterpretation : Linear Raw [SubIFD] SamplesPerPixel : 3 [SubIFD] PlanarConfiguration : Chunky [SubIFD] TileWidth : 400 [SubIFD] TileLength : 432 [SubIFD] JXLDistance : 0.5 [SubIFD] JXLEffort : 7 [SubIFD] JXLDecodeSpeed : 4```

Interesting that the Bayer has a very slightly off Distance value... Makes me wonder where they get it from

Although, that low distance value actually makes it even larger than JXL lossless :P

```[SubIFD] ImageWidth : 3968 [SubIFD] ImageHeight : 2976 [SubIFD] BitsPerSample : 16 [SubIFD] Compression : JPEG XL [SubIFD] PhotometricInterpretation : Color Filter Array [SubIFD] SamplesPerPixel : 1 [SubIFD] PlanarConfiguration : Chunky [SubIFD] TileWidth : 672 [SubIFD] TileLength : 752 [SubIFD] JXLDistance : 0 [SubIFD] JXLEffort : 7 [SubIFD] JXLDecodeSpeed : 4```

Lossless: 5.25 MB Lossy: 3.16 MB Bayer Lossy: 5.76 MB

Does make you wonder if they ever actually tested it, as opposed to just plugging it in instead of the Jpeg encoder

then jxl is better im guessing?

That's just floating point encoding to decimal conversion

0.5 perfectly translates to decimal but 0.2 does not

Ah

more like 0.5 translates to binary perfectly but 0.2 doesn't

Yeah. That's a better and more accurate way of saying it

When it's translated back to decimal again, it's revealed to be an approximation due to the limitations of binary float encoding

Decimal has the same limitations too of course

Some values can't be expressed in decimal perfectly like 0.333333

notably though, all values that can be expressed exactly in binary can be expressed exactly in decimal

I find sad that the decimal fraction notation is not used, and never used in any programming language. Like when 0.3 with the 3 overlined means 0.3 with an infinitely repeating 3, which is a perfect representation of 1/3 https://en.m.wikipedia.org/wiki/Repeating_decimal

not quite the same thing, but python has this https://docs.python.org/3/library/fractions.html

In APNG, frame delays are represented as fractions, so animation with perfect 60fps can be created.

indeed, but not repeating decimal notation (yet ?)

Instead of repeating decimal how about we get continued fractions?

repeating decimals can be represented as a fraction

you just have something like 123/999 instead of 0.123123...

it can get a bit annoying with preceding digits, though, e.g. 0.471[32] is 0.471 + 32/99000 = 46661 / 99000

hm, continued fraction [0; 2, 8, 4, 1, 1, 2, 3, 1, 1, 1, 9, 2]

Yes, both for photo and nonphoto, jxl is better than older jpeg codecs. For nonphoto by a lot.

GIF can do anything from 2bpp to 8bpp. 1bpp is actually encoded as 2bpp. It's quite flexible, frames inside animation can use different number of bpp. I have a GIF, where some frames are 7bbp and the others are 8bpp.

So it looks like the AVIF support in Android 12 is not very complete, and only in Android 14+ it works properly. Does someone happen to know what exactly the limitations are of the initial Android AVIF support? As far as I understand: no alpha, only 4:2:0, only 8-bit. But there seem to be more limitations than only those (there are avif files with those properties that still don't decode in Android 12 even though they decode just fine with more recent avif decoders).

resource limitations

it uses gav1 for decoding which quite unoptimized to say the least, so heavier files will get android to kill the process

Does AVIF have reference encoder and decoder? Several implementations being so bad and unreliable really limit the usability of the format.

libaom is the reference implementation afaiu

I have here a 600x600 8-bit yuv420 image without alpha or anything special, and it does not decode on Android 12...

well thats odd, if you can share it I can give it a test, I still have the dev stuff enabled on my device

hm, its working on A13 for me, Ill spin up a VM to test a12 specifically

``` 07-10 14:11:31.239 3475 3985 W DocumentsContract: Failed to load thumbnail for content://com.android.externalstorage.documents/document/primary%3Awb.avif: android.graphics.ImageDecoder$DecodeException: Failed to create image decoder with message 'invalid input'Input contained an error. 07-10 14:11:31.251 3475 3985 W DocumentsContract: Failed to load thumbnail for content://com.android.externalstorage.documents/document/primary%3Awb.avif: android.graphics.ImageDecoder$DecodeException: Failed to create image decoder with message 'invalid input'Input contained an error. ``` well this is a totally useful error

ah looks like the decoder is actually just outright crashing with this

This is interesting. Windows decodes this AVIF file correctly. Windows AVIF decoder has problems with images created by Gimp, it decodes them with incorrect colors.

interestingly, the android build im using has a gallery app that tries to fall back to FFMpeg which also reports an issue

also decodes fine on MacOS

yeah I think this is a issue specific to the versions of the encoder being shipped, in theory google could push an update for them using project mainline for A13 at least

I think a12 can too? cant confirm though

Kind of funny that the format they love so much is broken on their own operating system

Or at least was

android never really cared about avif or av1 to be fair

It's a bit of a practical problem for android app developers: they assume Android 12+ supports AVIF, but some of the AVIF files produced by current versions of libavif/libaom don't decode on Android 12. So for interoperability it would be good to know what exactly is causing the problem. I would like to understand if it is something that can be circumvented by using specific bug-avoiding encode options, or if we should be advising android app devs that they shouldn't assume system-level AVIF support on Android 12 (and fall back to webp or jpeg on Android 12 or ship their own decoder or whatever).

uhh, I might be able to look a bit more indepth later to see if I can get a backtrace, but honestly, even if the issue is found, the chances that an update gets pushed is low since the decoders clearly havent been updated anyways, so advising that system level AVIF support is bad on A12 is necessary regardless. enabling and disabling encoding options only sometimes works with av1 encoders in a lot of cases I find. I can probably find the decoder versions in A12 though

It's kind of disappointing that the same annoying thing happened as what happened when WebP was added to Android: it was rushed, done at a time when the file format spec was not even fully frozen yet, and support was announced but the actual implementation was buggy and only had partial support for some kind of MVP subset of the format. Both for WebP and AVIF, it looks like the initial Android version that 'supports' the format, has no support for alpha and does not decode at least some valid files. That kind of thing is pretty annoying: it causes apps that work fine on Android 14 to have broken or wrong images on Android 12. It sometimes feels like the proponents of WebP and AVIF don't really understand the basic principles of standardization and interoperability, that is, concepts like freezing a bitstream specification and decoder conformance.

The end result is that there is not really a single AVIF image format, but there is some variant that corresponds to what Android 12 can decode, another variant that corresponds to what works on Windows, etc. That is exactly the opposite of how interoperable, standardized formats are supposed to work.

in theory, Android 13 at the very least should be able to be upgraded to a newer libavif+dav1d. android 12 is a tossup. custom roms could potentially push fixed for them since iirc A12 is still in update range

actually, I wonder if this is just in general a libgav1 issue, I suppose bisecting via libavif could find that out

I guess that Android AVIF support was made by re-using existing HEIF parser. It supported only most common HEIC files, only some of the HEIF features worked. So the limitations of previous HEIF implementation were copied to AVIF parser too. On the other hand, different implementations are good thing for new formats. Its true that interoperability suffers in the beginning but it is easier to see differences between implementations and to observe problems.

ISO 23001-17 <:Thonk:805904896879493180> ```support ISO 23001-17 version 1 uncC minimized headers support ISO 23001-17 images with 'deflate', 'zlib' and Brotli compression``` https://github.com/strukturag/libheif/releases/tag/v1.18.0

Couldn't HEIF carry anything that MP4 can? Including MPEG1, MPEG2, DivX/XviD, h263, h264 and even JPEG?

Some AVIF decoders ignore color matrix metadata, and always default to BT.601.

those also always decode as full-range usually, regardless of metadata

Gimp is using full range of course, and by default it also writes sRGB ICC profile to the file. That should be enough to correctly decode an image in sRGB color space.

A few months ago there was an issue open for [adding AVIF support](<https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/880>) to a game, I had made an issue [requesting JXL](<https://github.com/Yellow-Dog-Man/Resonite-Issues/issues/1562>) too, but both were put on hold unless they changed image library from FreeImage I check again just now and suddenly they're halfway done implementing AVIF

FFmpeg doesn't seem to understand animated WebP, it does understand APNG though.

That's weird. ffmpeg can write animated webp but can't read them.

ffmpeg has a lot of issues like that

There is an old bug report regarding that and no progress to it

https://trac.ffmpeg.org/ticket/4907

It's funny that ffmpeg can't even read files produced by ffmpeg itself.

indeed

also annoying for players which use ffmpeg in the backend such as mpv

It shouldn't be that hard. libwebp even has an example program for decoding animation frames. libwebp does pretty much all the work.

Do you think HEICv2 with VVC instead of HEVC will ever become a thing ?

I hope not, AVIF and JXL don’t need more competition

It's not competition I'm worried about. It's more like we don't need *another* video codec mangled into a subpar image format again...

Is JXL going to improve its lossless compression ratio? Looks like AVIF (`libvips`) currently still beats JPEG XL...

can you provide a test image?

this is not something i've been able to replicate off hand, can you provide a test image where this is the case, and the resulting encoded images? I don't personally use libvips, but I would assume that it doing something strange or you have an outlier image

it might be doing near lossless for avif. ffmpeg lossless avif was quite bloated last time I tested

I used libvips for AVIF codec

yeah, so libvips might be doing something different

https://github.com/PoneyClairDeLune/derpi-image-corpus/ Here is the whole corpus

https://le-m.ltgc.cc/derpi-image-corpus/data/derpi.lossless.size.tsv The last test run. There's a new run currently going on.

JXL: `cjxl --num_threads -1 -j 0 -d 0 -e 7 "$file" "test.${id}.d0.jxl" 2> /dev/null` AVIF: `vips copy "${file}" "test.${id}.d0.avif[compression=av1,lossless=true]"`

darn it, can't find the lossless test results... gotta wait until the new run's finished

and JPEG XL progressive's larger than non-progressive, while also taking longer to encode... somehow?

uh, I would highly reccomend verifying that libvips is *actually* lossless

``` ➜ test ffmpeg -hide_banner -loglevel error -i 2877671.png -c:v ppm -f image2pipe - | b3sum 2981e5e7390773871d8c8ab09f1c20d059951c64f6e299073b56c5d4990ee8ae - ➜ test ffmpeg -hide_banner -loglevel error -i sample.jxl -c:v ppm -f image2pipe - | b3sum 2981e5e7390773871d8c8ab09f1c20d059951c64f6e299073b56c5d4990ee8ae - ➜ test ffmpeg -hide_banner -loglevel error -i testout.avif -c:v ppm -f image2pipe - | b3sum 130df0235c005ffdd8a997b43284c19745b8d941acd309ddb60996387ea6a17a - ```

I would verify first that it is using aomenc since svtav1 cant actually do lossless

the result of the command you provided is a yuv420p file

maybe it's a bug in libvips and the SSIM CLI util I'm using, but the SSIM indexes of the results I got from the libvips command provided were all 1, so I just assumed it was lossless

if you want to verify true losslessness, you should always decode and hash

how should I encode the lossless AVIF files then? cavif-rs doesn't support lossless encoding

avifenc directly I guess

avifenc has some really dumb defaults sometimes, but `avifenc 2877671.png -q 100 --lossless out-avifenc.avif` ```ps ➜ test l Permissions Size User Date Modified Name .rw-r--r-- 2.3M quack 18 Jul 04:07 2877671.png .rw-r--r-- 1.8M quack 18 Jul 04:15 out-avifenc.avif .rw-r--r-- 1.6M quack 18 Jul 04:07 sample.jxl ```

q 100 isnt needed, it was just a left over

yeah even `"testout.avif[compression=av1,lossless=true,encoder=aom,subsample_mode=off]"` is not true lossless with vips, so im assuming this is 100% a bug in libvips, though this could be an issue with their RGB -> YUV pipeline

the bugged-out results here for archival

and may I ask about the cause behind the bloated size when JPEG XL lossless has progressive enabled? does progressive encoding breaks something in the encoding pipeline of the non-progressive JXL lossless?

I couldn't say, I never use it since jxl is capable of the old school "dumb" progressive regardless (though for some reason libjxl *sometimes* doesn't work unless you add --progressive_dc=1, this doesn't add much if any data size so I just always do it in lossless mod)

libvips still needs to save with `matrix_coefficients=0` for true lossless, see: <https://github.com/libvips/libvips/blob/93088ba9f054b222d47d10b3ef626db0baea997f/test/test-suite/test_foreign.py#L1442-L1444> In the meantime, the `heif-enc` tool could help here, e.g. `heif-enc -L x.png -o x.avif`.

that;s fairly annoying

Indeed, I'll have a look at fixing that today.

currently libjxl isn't the *best* at progressive decoding files I find, jxl-oxide takes the crown for that I do have better videos then this to showcase it, but this is jxl-oxide vs libjxl

oh, these videos are yuv444p so firefox will break with them incase you use ff as a discord client xD

I'm on Vesktop XD, though Firefox is the main browser I use

but sometimes libjxl will outright fail to decode an image progressively unless it;s been encoded with progressive_dc

https://discord.com/channels/794206087879852103/1065165415598272582/1257212537859084318

this is an example, progressive_dc=1 is normally within a hair in cjxl so I just always use it

here is a back to back picture comparing the two, nodc completely fails to load progressively at all, but with dc libjxl can start decoding with 1% of the file downloaded

should progressive_ac also be enabled?

I don't personally touch progressive_ac so I can't comment, but last time I did try it, it ballooned images

the only other things I really touch regardless of lossy or lossless are `-d 0 -e 10 --brotli_effort=[0..11] -x strip=all -I [0..100] -g NUM -E NUM --faster_decoding=[0..4]` of special note faster_decoding 1 and 2 are borked on lossless, so if you wanna use it, use 3 or 4, not sure there is an actuall difference between 1 and 2, or a difference between 3 or 4 though, none that I have noticed

I've just tried `avifenc`. The encoded AVIF is significantly larger than the source PNG, that's not a good start. However, programs I tested were able to decode the image losslessly.

Is faster_decoding enabling progressive ?

Testing another image with `avifenc`. This time the file size of the encoded AVIF is slightly smaller than the source PNG. Still not great, lossless WebP smashes it. Lossless decoding seems to be working OK, at least.

It's an improvement. When I was testing lossless AVIF last time. Lossless decoding was very unreliable.

AVIF can do lossless but it's more like a "feature box checked" thing than something actually useful. No real improvement vs PNG (your mileage might vary depending on image content).

How exactly does it work? Is it just lossy AVIF with residuals, or is it its own seperate spec like WebP?

As far as I understand it's just lossy AVIF using only the subset of transforms that is reversible. Similar to how JPEG 2000 does it, basically.

And im guessing no quantisation

Yes. It works, for some image content it even works well, but it's not great. At least JPEG 2000 put some more thought into it and also defined a reversible color transform; in AVIF they forgot about that until it was too late.

BTW, I just found out the hard way (customer complaining about images looking wrong) that the system AVIF support in Android 12 and 13 is making the hardcoded assumption that the YCbCr is tv-range, regardless of what is signalled. So if the AVIF uses full range (which is the sensible thing to do, and the default of current avifenc), the image will look somewhat contrast-stretched (dark gray becomes black, light gray becomes white) and oversaturated.

I wouldn't be surprised if they just thought "nice, the image looks better in AVIF!" and called it a day

Anyway it means basically you cannot use AVIF on Android < 14 in mobile app frameworks that rely on system libraries.

I'm not sure if AVIF can be used for anything at this point. Lossless is underwhelming and lossy is too unpredictable.

And let’s not forget about encoding speed shenanigans

Well AVIF lossy has some advantanges at least. If the source image has flatter colours, AVIF lossy is going to have less observable artifacts. The observable artifacts are somewhat more apparent in JPEG XL lossy.

Though for anything photographic or relatively detailed... AVIF is going to be beaten by JPEG XL.

And AVIF encoding speed is *abysmal*

AVIF may have less visible artifact but the color reproduction is likely to be messed up. Different decoders will decode the same image with visibly different colors.

Generally modular mode can be better for that, or just lossless

Those are just decoder bugs then, no? AVIF is supposed to be fully specified (as is usual for video codecs), so there is no decoder freedom at all.

But I have noticed that default avifenc does seem to be relatively sloppy on the chroma, even at quite high quality settings I tend to see substantial tone shifts and chroma macroblocking

where could it be turned on? and how does that affect the overall filesize?

-m 1 when using cjxl

Modular is what's used in Lossless, but it can do lossy too with different artifacts than VarDCT which is default

~~Turns out the decoder came with NixOS cannot decode modularized JXL~~ Edit: Looks like some weird bugs that's only present in terminal

Another interesting observation is that modularized JPEG XL takes less space than VarDCT, at the same distance value and effort level

Generally it's worse quality or larger than VarDCT due to not being tuned, but for non-photo images it can look better

Just tested, seems like it's not the case... The file size is smaller, yes, but for non-photo images it's more miss than hit. I think I'll stick with VarDCT.

lossy modular is quite inconsistent in quality

`-m 0 -d 1 -e 7`

`-m 1 -d 1 -e 7` Noticeably more spots of discolouration

Yes, this is true, but there are decoders that would use incorrect range or incorrect conversion matrix and that is the problem.

Comparison between several lossless codecs.

I've had major issues viewing AVIF on Android. It used to not open at all & crash the viewer as recently as Android 13

Yes, basically only on Android 14+, the system library version of avif is not buggy

As far as I can tell, in Android 12 and 13, there are various issues, including: - no alpha support - only 8-bit 4:2:0 support - only tv-range YCbCr (full-range will be misinterpreted)

wtf, full-range 4:4:4 is avifenc default...

I don't understand why tv-range is still a thing. I would just ditch this nonsense.

old legacy nonsense 🤷‍♂️

But computer images have nothing to do with analog video so why anybody sane would use it? JPEG doesn't even support tv-range.

because AV1 is a video codec, the AVIF decoder was probably just using a video av1 decoder that only supports what's used in video

Today's video is produced digitally so video should also default to full range.

Even analog video could be sampled in 12 bits with current technology. So no need for tv range anymore.

Lossy webp has forced 8-bit tv-range YCbCr 4:2:0. I would assume that the initial Android AVIF integration was done by the same team and they reused some existing code.

That team should know better.

it's the google codec team 🤷‍♂️

analog video could overshoot due to processing; that was the purpose of the limited range AFAIU

> (*) BTB and WTW in 16-235 video shouldn't contain picture content on properly mastered material - but they should ideally be preserved to allow overshoot and undershoot on sharp transitions (particularly in analogue sourced content) to be preserved without clipping to avoid ringing.

it's not even gone for hdr, even though it was the best moment to change that <https://forum.doom9.org/showthread.php?p=1945682#post1945682>

So sample the video with overshoots and then do the clipping in software and convert it to full range. Clipping in software is being done all the time without issues. I don't think video codecs are the right tool for preserving exactly analog signal, you could as well preserve contents during blanking intervals, exact timing of sync pulses, the modulated color signal etc.

As I said, because most video production is being done digitally, full range should be the default.

I don’t disagree with “default”

but I would be careful with “not needed”

There is really no need for limited range in modern codecs because these are intended for playback on digital devices and have to be converted to full range during playback anyway. Also analog video is being processed even further like deinterlacing of upscaling, to better fit modern displays, so conversion to full range can be done at the same time. If somebody really really needs to preserve video as close to analog as possible, they should use some different type of signal processing. For example, I've seen people archiving laserdisks capturing the raw modulated signal from the laser pickup and sampling it with much higher bitrate than any video codec could, getting as much information from the disk surface as possible. The captured signal can be later decoded to video and audio using software.

If someone figures out an algorithm to subtract splines from an image, and adds it to libjxl, it will finally blow avif out of the water...

along with actually tuning it for low quality images of course

Better to lower the bitrate without lowering the quality :)

better to have pixels with information <:JXL:805850130203934781>

Better to just use PPM for everything

💀 💀 💀 💀

nice parallelization great low ram usage

and brotli better for text and lzma2 better for not text

hopefully it will land sooner too, though spline extraction may be quite expensive in terms of computation?

p*n*e*Wf

So is avif encoding 😂

I know AVIF is expensive, but JXL encoding shouldn't be more expensive than that, just saying

Not sure if I did something wrong, but AVIF (libvips) at quality 90 has a higher [SSIMULACRA 2](https://github.com/cloudinary/ssimulacra2) score than JPEG XL d 1.0 (effort 7, progressive, VarDCT) while being smaller... Should the effort value be turned up?

can you share the pic ?

https://github.com/PoneyClairDeLune/derpi-image-corpus/ If you're up to downloading 106 images all at once, sure \;)

thats not too uncommon, it can for sure start to trade blows depending on the image

Though I guess I need to split the metric into categories to see the specifics... ~~That's being done in the meanwhile~~

libaom has gotten a lot better at preserving texture recently. libjxl still has a lot of blur and smudge. Also libjxl has some really severe color desaturation problems, but in the past libjxl used to be better than libaom at preserving texture and details...

if that is an average, you should for sure be trying to find the best and the worst of the images either way to compare against them manually as that can really show which types of images are favoured by which encoder

Idk how that translates to metrics though. (But frankly, I don't care, and metrics don't matter. What matters is your eyes can clearly see a lot more detail and texture and color in libaom now than libjxl)

libaom improved a lot

when ?

(i'll pull the last version)

yup the data is publically available with categorization already done, I just need to import it to graphs and find out how the extreme cases affected the whole thing

https://discord.com/channels/794206087879852103/803645746661425173/1263025254339580027

Not sure when exactly, but I remember older comparisons showed libaom having serious problems with blurring/smoothing. Now libjxl is the worst offender at blurring/smoothing.

though JXL d 2.0 being far smaller than mozJPEG q95 while still having a better objective score...

Mozjpeg is not tuned for q95

I think older blog posts comparing AVIF with JPEG XL between 2021 and 2023 all shared the same findings

if that's the case, I'm seriously questioning JPEG being one of the most widely used lossy formats in the wild

it is mainly donkey focused ! and mainly drawings or 3d, no photos ?

no the corpus mainly focuses on non-photographic content

though devided into several subcategories already

the results from `3d` and `cshd` could be higher

and here we see a bias toward photography in the optimization of the jxl encoder... but cjxl have room for improvement ! 🙂

nonetheless it's an amazing job you did here 🙂 where can I find the meaning of **nl** ? like in nl.jxl ?

near lossless for WebP it's `-near_lossless 60 -m 6`, for JPEG XL it's `-m 1 -d 0.1 -e 7`

also JPEG XL with those params are smaller than WebP near lossless, just saying

I only use webp never [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&quality=lossless&name=av1_dogelol)

sometimes I will use lossless when I need support for something old

yep, for lossy, given the fact the distance setting can be very precise with cjxl, it is sometimes good to try to match the size before doing a ssimulacra

mozjpeg is tuned for lower fidelity, q95 is too high and jpegturbo is better at that setting

I'll try that later then

it's better to not trust computer scores at all...

in local.lossy.ssim.tsv can you add a column for the resulting size ?

(and which effort did you used ? sometime higher efforts are detrimental)

the goal of near lossless isn't to have a better quality at smaller sizes (though won't complain if that's the case), but to shave off some space before visible artifacts that could be observed with bare eyes when zoommed in appears