JPEG XL

libjxl will coalesce by default, since image viewers don't have layer views or blending themselves. Likely something to do with alpha and them not setting it to output layers

Tried Krita?

krita is no good, it's color management pipeline is practically non existent

good enough for painting but for photo editing and stuff like that, no good

So I should just add another layer containing everything?

https://cdn.discordapp.com/attachments/719811866959806514/1216585057112821851/image.png?ex=67d98de0&is=67d83c60&hm=e5f2696ec763c4a817d792e91ba774e28fd6b85ffe73da7f409860aefa690bfb& for example I still can never get this to look right

always have somekind of non linear processing

Funny thing is, they use that same example of red and cyan

https://docs.krita.org/en/general_concepts/colors/linear_and_gamma.html

if they understand the issue, fix it by default https://cdn.discordapp.com/emojis/939666933119324222?size=64

>ICCs

oh so it's a hack

also would need to support color management for incomming photos, dunno if that works

I hope this is not common with 200+ layers... 🫠

my exif overhaul for FFmpeg is coming along nicely

https://github.com/Traneptora/FFmpeg/commits/exif-overhaul-2/

I didn't even kmow ffmpeg touches it

it barely touches it

for a small number of specific decoders it grabs the orientation data and that's it

ahhh

also for those decoders it does parse it and add it to AVFrame->metadata

only for jpeg and not in a way that's easily modifiable or transferable

my overhaul adds a separate struct to contain the parsed data which makes adding and modifying it much easier

also adds public APIs to parse buffers of EXIF data and write the struct into a buffer. useful for encoders too to be able to take the sidedata and write it

it also includes compat with things like, zeroing out out the orientation

are the commits in question just the ones with today's commit date or are there more burried in history?

it's the ones authored by me at the top of the history

for example, if you attack the sidedata as displaymatrix, and then a filter, say, applies the sidedata and removes the displaymatrix, you end up with exif orientation that is incorrect, so if I'm attaching a displaymatrix I always zero out the orientation after attaching it

and have a corresponding function to re-parse the orientation and add it back

I wish github made it easier to code compare commits instead of just manually typing it into url, xD either way nice work, I wonder if this could be used to make dng stuff less painful, iirc it can use exif for a few things

DNG is basically just TIFF

I don't know

I haven't touched the TIFF code tbh

I dont blame anyone fornot wanting to touch tiff code lol

TIFF itself is not that horrible, just a little annoying that you have to handle both little-endian and big-endian for everything, even header syntax.

Exif is also TIFF btw

Baseline TIFF is not too hard to implement. But a complete TIFF decoder including all extensions, that's almost impossible.

Yea, my parser uses some of the Tiff code but not a ton of it

I wrote a simple tiff decoder a few years ago, was just 400 lines of code or so. We needed that because libtiff returns full images which was too memory-heavy..

indeed but when you write a tiff decoder, who knows if it will work or not with your image lol

the issue with EXIF is the corner cases

like you can't just take IFD0 and take it out of a tiff file cause it'll be corrupted

cause the offsets are relaltive to the start of the file

likewise the same is true about MakerNote which is by spec a binary blob, but in practice is often an IFD

GStreamer 1.26 adds support for H.266 and JPEG XS

oh, interesting, also HDR support through Blackmagic Design’s “DeckLink” PCIe card

and “Apple AAC audio encoder and multi-channel support for the Apple audio decoders”

yay it finally has proper decklink? nice

hi, once again with some general compression questions. Do you know about any reference in context splitting for coding wavelet transform coefficients? Best entropy I'm getting is by using only one context on coefficients that span the whole image. I thought could do better by dividing into 3 contexts: haar wavelet tree nodes, the second most deep layer and the rest of the tree, but got worse results than with 1 ANS context

I thought splitting it will help, because when I plot these separate layer coefficients I'm getting several Laplace looking distributions for histograms

<@226977230121598977> is the idea with the your audio spectrogram images to turn them back into sound so you can 'hear' the ways different lossy image formats sound with how the music is distorted? or just seeing how well they compress

I wonder if you could meaningfully distinguish different lossy compression schemes by how they sound, like "ah this sounds like webp vaseline" or "pretty clear jpeg macroblocking and ringing on this one". I do know with certain things, turning visual data into sound data gives us an oddly better ability to detect patterns

https://discord.com/channels/794206087879852103/806898911091753051/1266183715118383136

oh!

thanks

no, it is not feasible from of wave physics, or rather the discrete Fourier transform DFT (not DCT) falls under the limitation of the physical law of the uncertainty principle. The images created are only an approximate representation of the fact that somewhere there is some sound of some wave of such and such strength. And it cannot be presented back. Although I have already done this, I will send the results of the work now

the main problem is that the wave is an extremely complex thing that has a point of phase, signal strength, point of frequency and point of time. And if you just generate a spectrogram. It will be 3 indicators, time, frequency, signal strength. There is no phase. For this track, I choose a random signal phase, it turns out zero hormonic, zero.

interesting

> or rather the discrete Fourier transform DFT (not DCT) falls under the limitation of the physical law of the uncertainty principle is fft actually not perfectly reversible? is it only reversible when the wave happens to be a sum of exactly the frequencies you sample for the fft, or not even then?

maybe i'm misunderstanding

another problem is low frequencies, they cannot be adequately represented, there is not enough information. The uncertainty principle works like this - you have 4 wave points. Can you say what power they are? Can you say at what frequency? Can you say anything? No. This would violate the physical laws of our world. Spectrum analysis occurs in a window size, for example a window of 500 points. The spectrogram drawn is the central point in these 500 wave points.

https://en.wikipedia.org/wiki/Uncertainty_principle

high frequencies may be reversible enough to be audible. But full reversibility is not possible at any frequency

if calculate the phase based on all wave, you can write a table of the beginning of the phase for each frequency, for example, here I did it, it sounds better NUMNER / 100 * 2 * 3.141 93 43 49 74 27 98 98 86 82 56 85 21 18 92 16 76 03 05 88 27 95 83 28 91 44 38 12 95 13 85 42 73 12 64 25 15 49 74 41 83 52 76 14 15 48 67 05 47 74 93 13 98 68 15 03 29 90 55 19 53 71 00 75 88 47 55 36 04 76 99 88 49 24 82 33 99 61 19 76 81 64 54 76 81 56 91 23 97 73 73 98 04 58 58 13 86 43 87 71 80 20 17 07 96 13 68 75 28 56 02 50 03 51 80 88 33 16 62 89 52 30 92 69 14 78 17 31 86 04 84 13 94 88 13 70 98 78 92 88 66 27 07 09 33 97 56 77 46 98 59 85 07 90 75 59 75 79 59 31 45 54 54 56 92 75 11 10 15 89 99 91 30 24 11 17 26 43 46 73 54 43 59 76 71 30 80 51 78 97 36 74 56 79 66 02 15 86 88 37 49 66 03 96 64 77 27 69 18 04 90 79 64 77 15 33 33 54 89 64 28 28 36 87 09 07 39 61 89 80 97 34 31 93 68 29 35 92 85 10 55

but this still won't solve the low frequency problem.

I didn't even consider how the phase might fuck with the fft

This picture is a lie. Don't believe it.

<:This:805404376658739230> lie

I should watch veritasium's video on the fourier transform again

this is interesting

I haven't watched it, but knowing this channel, it will most likely be very superficial

probably, but I know next to nothing about math, am dyslectic, and attention deficit, so I take what I can get xD

I am disappointed in spectrograms. But nothing prevents you from recording sound using "film" technology

like you would not believe how long it took me to read a few paragraphs from the jpeg xl paper that I was interested in because they related to something else I was working on

the paper

my paper

I've done it before, you can do 2d DCT transform not for 8x8 block, but for the whole image, or for any other data like sound. then do it back. AND compressed.... The result there was generally complete crap that's not even worth attention.

It's much easier to do this - take the wav data, convert it to 8-bit wave. Write each sample to a brightness 0-255 image file like bmp/png. And compress it. Then you can decompress it. It will all sound extremely bad, because compression without psychoacoustic principles is blood in the ears.

I found, literally that's what I did, wav to jpeg Music passed through a classic DCT, which is why MDCT is used for music original / compressed

attention ears

what's interesting is that a lot of the noise sounds high frequency, even though that's specifically the data JPEG removes

That's the whole point, what it deletes. And what is written instead of the deleted data? That's right. Quantization noise

goddamn right

oh, I guess high frequency sound doesn't mean they correspond to high frequency components in the image, I was thinking about it wrong. in a spectogram higher frequencies are just higher up, and that information isn't treated differently by jpeg compression of course

yeah I have a visceral reaction to artifacts like these <:KekDog:805390049033191445>

(Btw swallow chewing gum was my alt for a little)

Is there a "butterohrli distance" for audio? Like a metric that can reliably determine "audibly lossless compression" when blind testing on high end equipment with the typical audiophile?

I want an opusenc.exe with "d=1" option haha

I guess I should ask this in the opus discord

vbr modes are prety much that. opus' is much better than mp3's at all bitrates since it doesnt filter out as much inaudible frequencies as mp3

IIRC <@532010383041363969> was involved in the project with such goal. I'm also waiting that one day opus will be able to do real vbr instead of current abr

https://github.com/google/zimtohrli

there is an opus discord?

Sorry I just assumed but I didn't find one

Thanks I guess that's exactly what I was looking for

I've used it a lot, so feel free to ask questions

man we need more jxl apps for android ``` find . -type f -printf "%f %s\n" | awk '{ PARTSCOUNT=split( $1, FILEPARTS, "." ); EXTENSION=PARTSCOUNT == 1 ? "NULL" : FILEPARTS[PARTSCOUNT]; FILETYPE_MAP[EXTENSION]+=$2 } END { for( FILETYPE in FILETYPE_MAP ) { print FILETYPE_MAP[FILETYPE], FILETYPE; } }' | sort -n | numfmt --field=1 --to=iec-i --format "%8f" 0 NULL 0 nomedia 36 database_uuid 1.5Ki lua 31Ki heic 103Ki avif 128Ki webp 2.9Mi 1 18Mi jpeg 40Mi mov 314Mi webm 518Mi jpg 553Mi gif 1.6Gi png 4.1Gi mp4 12Gi jxl ```

weird formating issues

More jxl than videos <:Stonks:806137886726553651>

MJXL

cant believe even /r/Datahoarder messes conversions from JPG. Lossless transcoding too needs more awareness amongst public and utilities still doing lossy full reencodes

https://www.reddit.com/r/DataHoarder/comments/1ji1x4w/some_recentish_informal_tests_of_avif_jpegxl_webp/

there's a point where these posts' methodology should stop being called "informal" and start being called "harmful"

nothing conclusive can be derived from these observations

other than "higher efforts result in slower encodes"

it seems lossless jpeg reencoding is actually included (`JXL-l1-q__-e_`)

but yeah, not sure what the point of the rest is

“there existed a quality setting that produced this size”

> In general JPEG-XL is not that competitive in either speed or size, and the competition is between WepP and AVIF AOM. yeah, you can’t conclude that

Benchmarking lossy compression without considering quality at all, that's like judging cars based on how fast their windscreen wipers can move back and forth.

to be fair, there is _some_ slight consideration of quality > Examining fine details of some sample photos at 4x I could not detect significant (or any) quality differences, except that WebP seemed a bit "softer" than the others.

but they apparently didn’t really try to see whether that was also true of lower quality settings

I missed that paragraph but it doesn't really mean much at all if you only look at one quality point. WebP at default quality is going to produce smaller files than jxl at default quality because cwebp just has a lower quality default. Cwebp defaults to q75 on a scale where q75 corresponds to a lower quality than e.g. typical jpeg encoders at q75, and much lower quality than cjxl q75. So this is a bit like comparing libjpeg-turbo q60:420 to libjpeg-turbo q55:444 and to libjpeg-turbo q90:444, saying "I could not detect significant quality differences" and concluding that q90 is not that competitive in either speed or size and the competition is between q55:444 and q60:420. Also why is someone still testing libjxl 0.7? That version is 2.5 years old. If speed is a concern, using a more recent version can make a difference...

libaom is also super out of date in that test, and so is likely libsvtav1

the more time you spend reading the post, the fewer and fewer things make sense

When someone uses "JPEG-XL" in benchmarks, I can presume they're not serious

He is comparing libaom on its fastest and second fastest setting to libjxl on its fourth fastest setting and saying libjxl is too slow? Whut?

And he doesn't upload any crops of the resulting images so we can see what they look like after

Why old versions? Ask debian (or ubuntu or whatev)

He's using ubuntu lts. Don't blame him for using old stuff, blame him for using debian and blame debian for being utterly awful

"cant see a difference" should shown the images. the filesize number mean nothing if the output was actually of a visual quality noone wouldve used even with jpg

not falling for table numbers ever again after a jxl dev showed in the past that some low filesizes were unusable trash noone uses in real scenarios. always focus on compression efficiency, preserving visual quality at all targets instead of *discarding* even more detail to hit an arbitrary filesize target

When uploading them they will get destroyed by reddit probably. He should have shown some cropped PNG of the result so we can see what it actually looks like.

Sounds like they were really large photographic images. Usually those are very blurry to start with.

To be fair libjxl is not optimized well for those types of images. Even worse at low effort mode.

I don't think libjxl is clever enough to look at the spectral energy and recognize when an image is just really blurry and grainy like an oversized blurry photo.

time for a comment lol

If it was smarter it would remove & replace the grain, recognize the photo is blurry as hell and compress at a much lower bitrate compared to a photo that's packed with small details.

I never made an account on le reddit, the idea is too gross for me

Like auto applying 2x resampling?

Possibly. That seems kinda risky but yeah. Or do something equivalent that saves the same amount of bits.

Ig just setting hf Coeffs to 0

jxl already compresses smooth images pretty well

But it's not smart enough to remove and replace grain/noise

Not even enough to measure how much grain was naturally lost as a side effect after encoding, so it can signal to replace it

There *is* `--noise` which was meant to learn the noise inside the image and reconstruct it, but it either broke over the years or never worked at all

understandable lol

At the bare minimum the encoder should be able to signal how much noise was lost after encoding compared to the original so it can be replaced by the decoder

Since a lot of different observers have remarked on how libjxl compression noticeably removes grain enough for people to point it out in videos on youtube for example, and it might give people a bad first impression of the format itself

People don't realize that deficiencies of libjxl are not inherent to the format itself

That would probably be the simplest and easiest way to implement an "automatic grain synthesis" feature. Simply measure how much grain was lost compared to the original AFTER encoding so there's not even a need to change the encoding process itself at all.

You could even apply it to existing files

IIRC when using photon noise, it takes it into account to lower quality in covered regions

By comparing a lossy file with the original, you can measure how much noise was removed and then just adjust the metadata to add the missing noise to the existing lossy file without reencoding

It can "fix" existing lossy files by adding back the removed noise

If so, that's smart. You can know for sure though if the file size goes down when telling the encoder to increase the photon noise

I was reading the JXL paper, got to the mention of the Move-To-Front Transform and implemented it myself out of curiosity. I found that it can perform quite a bit better if you create a more optimal state array trained on your type of data to begin with. I tried two variants: one where the bytes are sorted by their frequency in the data, and one where the state is the state after applying the transform on the reversed data. With the first approach, the more common a byte is, the closer its first representation will be to 0. The second approach is nice because the first few bytes will be close to zero (and the first is always zero), which is good because usually the first handful of bytes are the ones that are encoded as themselves since they're only changed to something better *after* they've been seen once. The downside is of course that if you want to tailor it to the specific data, you need to signal it, and naturally this would mean that instead of`data: [221, 35, 62, 45]` you transmit `state: [221, 35, 62, 45]; data: [0, 1, 2, 3]` so you don't gain much if anything. but if the encoder and decoder agree on a state beforehand, you don't need to signal anything and you can get values you expect closer to the start of the array so they are encoded as indices closer to 0. But if the data you're encoding starts around 0 and stays close to it, you still don't gain much. This appears to be the case for JXL if this example is representative of the real data: > For example, consider the context map corresponding to > the following list of 48 indices mapping 48 pre-clustering > contexts to 16 post-clustering contexts: 0, 1, 2, 2, 2, 2, 3, > 4, 5, 6, 7, 7, 7, 7, 8, 9, 10, 11, 12, 13, 14, 15, 15, 15, 15, > 0, 0, 15, 0, 1, 0, 0, 0, 0, 14, 15, 15, 15, 15, 14, 13, 12, > 11, 10, 15, 13, 9, 8. Not some incredible revelation but a fun detour nonetheless

So this didn't change the algorithm, just the initial state. I wonder if you could improve the algorithm by not just moving every seen value to the front, but moving it to a position depending on its frequency as well. Probably still move it to the front regardless so you can encode repeating values as a string of 0, but instead of shifting back the array's values to account for that, place the old value at index 0 at a position that reflects how likely you think you are to see it again

Hi! Given that JPEG XL saves histograms to the header I'm trying to figure out how the context modeling works. I assume that we have one MANIAC tree for each channel. Then the amount of leaf nodes would be the total amount of different contexts. Now does JPEG XL store a data histogram for each leaf node ctx?

From what I understand, each leaf node can define which context it uses, with each context having a histogram and ans state and stuff. This is so multiple leaf nodes can share the same context if they are similar

You just have one MA tree, it can branch per channel but doesn't have to. Leaf nodes have a predictor choice and a context (histogram); contexts can be shared between leaves, the number of different contexts is actually limited to 255 iirc.

See also: https://discord.com/channels/794206087879852103/1347775789139230780/1347834222047662184

Microsoft are using a GIF for their end of support popup...

remember this is the same company that uses ezgif for shipping products

I swear to God we will never let go of GIF...

Well, yeah. No one ever tried to make a better GIF

Aside from Jyrki

His lossless webp encoder is better.

Any other image format's animation can be better than animated GIF

and all major browsers have been supporting APNG and animated WebP for years

But no one tried porting gifski or whatever to jxl

Or even apng

The author of Gifski, who's also the creator of ImageOptim, hates APNG as well as WebP

Whut? Why hate apng? It's just png.

Never heard of people "hating" png before

It's made by the same guy who made pngquant... so how could he like 8 bit png but prefer gif?

We can ask <@826537092669767691> directly too

> I don't plan to. I think Animated PNG is obsolete, and an evolutionary dead-end. I don't think anybody should be using it. https://github.com/ImageOptim/ImageOptim/issues/398 Oh he just said he would revisit the idea of optimising WebP

He thinks PNG is a dead end but that doesn't stop him from optimizing GIF...

That's illogical.

> In 24-bit mode it has worse compression than GIF. In 8-bit mode it has worse quality than GIF.

Why is he optimizing gif then??

Huh? Worse quality? But they're lossless?

I don't understand what he means

If you attempt to optimise APNG with ImageOptim, the tool will remove all frames except the first one

No notice or warning about that

How is 8 bit gif better than 8 bit png...

He meant 8-bit animated GIF to 8-bit APNG

Why would it have worse quality if they are lossless?

I mean I find it funny that seemingly everyone who attempted to write a PNG codec has concluded that PNG is utterly and irredeemably awful as a format. But why is GIF better? And can't they be converted to lossless webp or jxl?

Gif is the dead end

exactly the same if you use `ect` without `--reuse`

ect works fine on APNG for me

Correction, it works fine on already-optimized files

Seems like it skips APNG chunks entirely, but removes Alpha when the first frame is solid, causing decode errors on the other frames

if it does not change the filter yeah

but the author does not want to add support for APNG https://github.com/fhanau/Efficient-Compression-Tool/issues/130

surely quality for size target

Does that mean there's something inherently more efficient with the GIF encoding than what's possible in PNG?

I thought GIF uses an older and less efficient compression algorithm.

GIF is less efficient PNG, lossy GIF means more than just a reduction in color. There is lossy LZW compression, and in Gifski's case temporal dithering via per-frame palettes.

> In 24-bit mode it has worse compression than GIF. In 8-bit mode it has worse quality than GIF. I think why Kornel doesn't like APNG is because it can't do temporal dithering due to the fact that it can't have per-frame palettes. Forcing APNG to use 24 bit color, making it a tiny bit bigger than GIF. Even so, APNG doesn't need temporal dithering to fake more colors because it can actually display all of the colors you need. So regardless it's still better than GIF. Not to mention APNG can use the Average filter in a lossy manner which blows GIF out of the water.

In the end, I think Kornel just likes the challenge of compressing GIFs as much as possible, despite the fact that it is the most "dead-end" image format to exist in todays internet landscape.

No per frame palettes? So gif is actually more flexible here? Well how common is that in gif anyways, pretty uncommon I thought. I heard you can even have full color, still image gif by dividing the image into 16x16 squares?

Do you know of an encoder/optimiser that uses the lossy average filter?

pingo

Ah, didn't know it does APNG

I just remember telling an artist that it was lossy... And now they use quality 100 JPEG for some reason

tell them to use JXL 😄

I got them to use Lossless WebP in the end, since it was the newest format supported by their platforms. For the ones that don't, q100 JPEG

GIF is technically more flexible only in the realm of 8-bit color due to per-frame palettes. And you are right, most GIFs in the wild don't use this feature, afaik Gifski is the only encoder that uses this feature to it's fullest potential. Full color Gifs are possible using this technique, but it's so horribly inefficient you would be better off using literally anything else.

any idea how I should go about hasing an encoded jxl comparing it to a gif? magick can give wildly different results since it seems to do it as a per frame thing without taking previous frames into account

doing `ffmpeg -i $FILE -c:v rawvideo -f hash -` gives different results too but im not sure if this is an ffmpeg limitation or if the encode is bad

needs to be scriptable https://cdn.discordapp.com/emojis/1113499891314991275?size=64

only way I know would be converting to a mediary format with `-coalesce`, not exactly straightforward

try this `ffmpeg -i input.gif -pix_fmt pal8 -c:v rawvideo -f hash -`

I got the same hash with gif and jxl

hmm, doesn't handle gifs with alpha well

yeah I dunno, maybe manually converting it to an rgba8

its kinda annoying that magick fails tho

ssimulacra2 sadly only does the first frame IIRC

I guess I could try ssimu2bin but I think only in video mode does it do multiple frames

and that requires VS which I am NOT installing on a phone lol

Shouldn't be too hard to let ssimulacra2 handle multi-frame somewhat more correctly, feel free to open a GitHub issue about it to remind me

"Tiny bit bigger" 24-bit PNG is 2-3x larger compared to 8-bit. Lossy averaging or paeth can help, but then you lose quality too, still end up with file size in the same ballpark as GIF, but don't get the benefit of universal compatibility. I work on fixing GIF because it's used so widely, and I don't like seeing badly dithered GIFs. GIF is used so widely not because of its technical merits, but because it works everywhere. APNG has most of the downsides of GIF, without the only feature that makes it worth tolerating the downsides. I don't work on APNG, because it's a complete dead-end. AWebP has got the same or better level of support now. It does everything that APNG can, but better. The lobotomized WebM leftover in AWebP is a disappointment from perspective of a codec, but still beats all the lossy averaging tricks by far. You can still mix it with WebPL and any number of colors you want. I haven't created gifski like tool for AWebP mostly because it doesn't need an intervention.

Sorry I should have been more specific, I was talking about a GIFs with per-frame palettes being converted to 24-bit APNGs is like only 10 - 20% bigger. From a video source of course 24-bit is going to be much bigger than 8-bit. But then you lose quality with GIFs as well, so I don't understand that argument. I doubt lossy filters are being used to its fullest potential, nevertheless I agree with it being a dead end since animated WebP/AVIF/JXL exists. I also agree that everybody should be using animated WebPs. Very few people are aware of its existence. Ever since discord added Animated WebP support, I stopped using Gifski entirely, it's a really cool piece of software though. <:PepeOK:805388754545934396>

I'm slowly getting people to use WebP now that Discord supports it. Namely when I notice my client visibly lag, only to open the network inspector and see a 15 MB GIF downloading

Still using GIF in 2025 <:PepeSad:815718285877444619>

We got to educate people that other animated formats exist

A lot of software also show just the first frame of GIF images, animated GIFs are not that universally supported. For example. neither Windows Photo Viewer nor Google Picasa on my machine support it, I have to use a browser to watch them animated.

A lot of websites (e.g. old-school forums) where you can upload/embed images still don't accept WebP, they accept the classic trio of JPG, PNG, and GIF. APNG is the best option for animations in this case. In most of cases, it just works (if the website does not try to recompress all the images; but if it's the case, gifs usually also lose animation).

Some popular websites also use APNG already since it supported by all modern browsers and became part of the PNG spec. For example, Steam: https://store.steampowered.com/points/shop/ - all of those animations are APNG and could in theory benefit from improved optimization 🙂

Oxipng and ApngOptim already do most of the work though

Browsers should just support any video format they support also in an img tag, with implicit muting. It is silly to allow images to move but not to allow using video codecs in that case.

(in Safari you can put MP4 in an img tag and it works, but not in Chrome; in Chrome you can put an arbitrary AV1 in an AVIF and it works, but not if you put the AV1 in an actual video file format which is the more convenient thing to do in terms of tooling and broader support)

Have you read the Luca argentero article? Is related to appeal vs fidelity and also with mdpi assessment imaging probably even with svt vp9 should make less blur at 480 kbps

And improve perceived noise aggregated sharpness in JPEG xl making the codec look better for autistic like when it was 0.2.3

While change lossless like

I readed 10 times to see if my Finzi someonez also did agree on

Which things could help

This is a video i sent many times to their server

It has unoroved quite well for 5000 views

Oh, Fab is back

I'm doing like a bot compression isn't my job

Images that got worse

Images that got better

Not sure of what I did i i did a full reset

I got suggested after working a bit a developer had to denonstrate that b. Has to stay not moving in his product VV ideogsmes

I used the cookies of that site probably Jon Sneyers is tired of paying the cdn so i'll stop because i have no innovation but i have time

I resetted the cookie for three video on youtube and deleted a lot of cookies. Seem all too disappear. Video doesnt look too mellow as it looked one month ago. Quality still has to be measured by experts but hw hackernews rss has contributed to it, and i thabk every comment in reddit, even the critiwue one i got today about AV2 and cnn not rredh and out

Fab, your prose is incomprehensible to us mere mortals. Your previous account got banned because it all became too spammy. Please make an effort at making sense, or just remain quiet.

DeepSeek seems to be able to understand what they are saying. I think they probably don't have English as their first language and are having trouble typing their thoughts. Their first block of messages (potentially) mean: Have you read Luca Argentero's article? It discusses the balance between visual appeal vs. fidelity, MDPI imaging assessments, and how SVT-AV1/VP9 might produce less blur at 480 kbps. This could help improve perceived noise and sharpness in JPEG XL, making the codec perform better for detail-sensitive use cases (like in version 0.2.3). I’ve also been looking into lossless compression tweaks. I’ve reviewed the material 10 times to see if my findings align with others’ work (maybe Finzi et al.?). What improvements do you think would help? I’ve shared this video multiple times on the server—it’s gained 5,000 views and seems to demonstrate progress.

we need a deepseek bot with a /translatefab command

not very faithful

Glad you're working on this. Is a regression that carries since 0.2.3

I don't know if is related to display because i'm not rich

Jon i restored facebook. But for the damage i caused to quality vs appeal page i do not what to do

the legend

Is the Squeeze/Haar transform technically a form of DWT?

No one on reddit seems to know that jxl actually does have a wavelet transform

Idk how similar it is to the one in j2k though

Probably very similar

J2k is actually a great format, idk why there's all the hate.

I think just the entropy coder was slow and bad

And it has a dumb name. Anything "2000" is terribly named

And I don’t think there was a good open source implementation

Haar is technically a wavelet but it's the simplest kind of wavelet and probably the hardcore wavelet folks will not consider it a 'real' wavelet. Squeeze is a modified Haar transform with the addition of a tendency term that mitigates the blocking you'd get with just Haar, with a nonlinearity that mitigates the ringing you'd otherwise get. With these modifications it's something that is quite different from the usual DWT. Though of course the general idea is the same as in all frequency transforms (DCT, DWT, DFT, Walsh-Hadamard, whatever): you get coefficients/residuals corresponding to different frequencies of the signal, so you can quantize the high freq stuff more aggressively than the low freq stuff.

Yeah that sounds awesome and I wonder why macroblocking transforms are even used at all then when that's available

Does the same thing but without the weird 8x8 pattern macroblocks? What's the downside exactly?

hardware implementation of discrete blocks are cheaper afaik wavelets and DCT exhibit different visual degredation when bit starved

Haar is a 2x2 DCT essentially

<@794205442175402004> is the squeeze transform patented?

It probably is covered by one of the defensive patents we made with Cloudinary. Royalty-free, with the defensive clause that revokes the license to those who want to patent troll against jxl.

ok, thank you

Well, it wouldn't have the trademark DCT block boundary artifacts we all know and love. But it would still have noise and ringing.

Wavelet based codecs are known to scale much better at lower bitrates.

They both could have mosquito noise and ringing.

I just don't see what the downside is.

If they're so conceptually similar what's the disadvantage exactly...?

Is DCT just significantly faster? Is that the whole reason?

<@1028567873007927297> i put a comment in that reddit thread you linked

Nice. I guess Squeeze is not very well known about. I can't find any papers on it, or the patent

haar wavelet smoothing has existed since at least the early 90s

the squeeze transform is a take on the same concept

regarding Squeeze, when you are trying to get local properties for a wavelet tree of level X with the residualas do you traverse the tree up and down to locate the adjacent already coded sample values? From the paper I see that for each coded C component you need to locate 7 values

+ when encoding the wavelet residuals do you calculate MA properties based on those residuals or do you with each level of residuals get the current downscaled version and then obtain properties of residuals based on their corresponding real image values

I hope this question makes sense

the MA properties are based on the residuals, not on the unsqueezed image

you cannot unsqueeze while decoding anyway, there are data dependencies on not-yet-decoded residuals

ok got it, so for each residual channel we scan and get the properties of the residuals themselves. The unclear part for me was my mindbias with LOCO-I where contexts are derived from the defacto pixel - predicted values

Is there a list somewhere of some of the known defensive patents on jxl?

I would like to read more about squeeze...

https://discord.com/channels/794206087879852103/1021189485960114198/1256224842894540831 H.6.2 <https://cloudinary.com/blog/jpeg-xls-modular-mode-explained#squeeze> <https://drive.google.com/file/d/19pjtxUgChAOmy5mi4sQBite4xgGa4iaA/view> Page 30 - 5.1.3

This is the main one from Cloudinary, I don't recommend reading it though since it is basically a description I wrote that then went through a patent lawyer to turn it into unreadable legalese: https://patents.justia.com/patent/11064219

I dunno which ones of Google are applicable. Doesn't really matter that much, it's basically just a deterrent against patent trolls: if patent troll X claims people have to pay them to use jxl and litigates, then Cloudinary and Google can say X can no longer use jxl themselves and litigate back against X. That's a hypothetical scenario that is not supposed to happen, it's just a precaution/deterrent to help maintain the royalty-free status of jxl.

(here X is a variable, not twitter)

JPEG XL but L stand for Legal

L stands for 50

L stands for Luca

X stands for crunchy Xen crystals

JPEG claimed L as a numeral so the superbowl had to use 50

So Jon was the main brain behind Squeeze then it seems like. But it's just a specific and simple implementation of a Haar wavelet it looks like.

I think this is the new record ~~for any program that I have ever run~~

Perl, gnu parallel, zsh, all calling each other?

parallel is written in perl

and I guess it may spawn shell instances to pass them command lines

An example of tile compression of an image based on a full analysis of the entire image for the correspondence and uniqueness of each block The method shows rather not the advantages of this method, but a more fundamental thing, the reason why compression using Neural Networks can theoretically be better (but at the moment it is still too expensive to implement)

What is different to av2 mscnn

https://www.mdpi.com/2079-9292/13/5/953

Also I did ai measurements of yt compression

technological progress is dead

<:SadCheems:890866831047417898> no vmaf for vp8

even though the ENA bbq game used the simplest vp8 codec to encode cutscenes, in 1080p. Even so, there were so many complaints about performance issues that devs had to make a downscale version of the video as a settings option

how can think about developing technologies of such a high level as VVC and AV2 when the power limit is a device that lies in your pocket and must work for half a day or more.

H.267 when

Wow not even VP9? I've seen reports saying that VP9 can decode faster than h264 in some cases. Is it not using hardware decoding?

Reminds me of some Ren'Py games that still use VP8.

vp9 is very fast to decode, that’s correct

svt av1 with FD2 used can also decode quickly, with preset 9 being faster than vp9

<https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2376>

what's FD2?

--fast-decode=2 ?

Creating an image (on the right) by generating pseudo-random numbers, by exhaustive search. 65535 search gen for 4x4 blocks. Which means that the image size will be 2 bytes per block, total 480 bytes for 64x64. On the left is an image size 459 bytes

fast decode 2, new feature to lower decoding complexity without impacting quality too much

ah, I see

--fast-encode when

Somehow that gave me an idea. Lossless AVIF vs PPM with filesystem compression

https://github.com/qarmin/czkawka/pull/1474/files

czkawka supports eyra, which uses jxl-oxide, so I guess jxl-oxide is compatible with eyra

for context, eyra is a replacement for libc kinda

https://github.com/sunfishcode/eyra

nuh uh. On such a small amount of information, my previous full-RLE algorithm (https://encode.su/threads/4316-NewEra-RLE-1-bit-image-for-manual-human-decoding) is still more efficient than "new" block tile compression (exhaustive search of all possible values ​​to select the top 10), and with the same RLE. Lossless is more efficient than lossy, funny, funny... I still couldn't compress 2 bytes into 1 byte. This is a dead end

Curious if people can test this and post their results https://github.com/telegramdesktop/tdesktop/issues/29219

Some Non XYB JPEG colors are also incorrect for me on telegram

How much of this bug is because of jpegli foolishly using chroma subsampling by default in an RGB JPEG (and failing to properly signal it's an RGB JPEG in the header)

Would these bugs go away if jpegli actually did things the right way (no chroma subsampling, correct app14 header present)

For the record, libjpeg automatically writes an app14 tag when necessary

>>> By default, the IJG compression library will write a JFIF APP0 marker if the selected JPEG colorspace is grayscale or YCbCr, or an Adobe APP14 marker if the selected colorspace is RGB, CMYK, or YCCK. You can disable this, but we don't recommend it. The decompression library will recognize JFIF and Adobe markers and will set the JPEG colorspace properly when one is found.

None. I added the APP14 tag and used 4:4:4

Ok, good, that's an important detail. It's a telegram bug then...

But the issue page does not say that there's no chroma subsampling or that the jpeg headers were corrected

Because they're irrelevant, they don't do anything

No, it's pretty important to know that the bug is present in normal, valid RGB JPEGs with color profiles, not just malformed and weird JPEG

hey, you all use <https://github.com/google/highway> -- any idea if there is a #define or something that will turn off all its runtime warnings (`HWY_WARN`)?

jpegli doesnt do this anymore fwiw

It defaults to 444 and if you use --xyb iirc it refuses to use 420

Definitely doesn't do weird stuff like B-only-subsampling anymore

theoretically they should only fire on debug builds, not release, righy?

no they run in release, unless we've misconfigured highway

but there doesn't seem to be anything checked before defining hwy_warn: <https://github.com/google/highway/blob/400fbf20f2e40b984be129b88f83d4748cfc26a0/hwy/base.h#L335-L336> and hwy::Warn: <https://github.com/google/highway/blob/400fbf20f2e40b984be129b88f83d4748cfc26a0/hwy/base.h#L268-L277>

so for context we're seeing a warning because someone runs in a VM that doesn't advertise sse4.2 support (as claimed by cpuid) but actually does support the instructions. and we've built highway with a `-march` that has sse4.2, so highway is basically warning that sse4.2 is not available because we didn't tell it to support anything older

so we may instead be able to avoid the warning by setting a lower `-march`

although theoretically that would add a bit of code size for extensions we don't actually care about supporting

Maybe the library, but cjpegli definitely still does. I forked it to make it 444 by default, and I'll probably make a PR later on with some more tweaks

Slightly jank, but working on it https://github.com/jonnyawsom3/jpegli/tree/jpegliSubsampling

looks like not, best you got is the runtime Hwy::SetWarnFunc

set it to a function that doesn't do anything

I'm using jpegli from the libjxl repo, and it doesn't do weird-b-only-subsampling

yeah i'm thinking about whether it's best to do that, or to set -march for highway so that it supports everything

the reason it doesn't is they're not recompressesable with jxl

it used to, but I pointed this out, and they changed it

for exactly that reason

It was originally a fork of the libjxl repo, but we switched to the google repo because it had a few missed commits that hadn't been merged to libjxl

lemme pull up the issue tracker

Just downloaded from libjxl

oh I'm referring to the weird B-only

yeah, that is B only, but any subsampling for XYB breaks transcoding too

Single channel subsampling is so exotic, all tools only report 4:2:0, not that it's a single channel

Also added the APP14 marker, since it's RGB JPEG internally

> We did put limitations on what kinds of JPEGs can be represented in JXL to hit a good trade-off: we did not want to complicate the jxl spec too much, especially the core codestream, while we did want to be able to recompress most JPEGs "found in the wild". For example, 4:2:0 and 4:4:4 jpegs are very common, 4:2:2 also occurs in the wild but more rarely, and any other kind of subsampling is very rare. So we did add chroma subsampling to the jxl codestream, but only for YCbCr, and only for up to 2x, to keep things as simple as possible. > > Basically the goal was to be able to recompress 99.9% of the JPEGs you would encounter in practice on the web, and I think we succeeded. > > Now if jpegli is going to produce a new kind of exotic JPEG that we cannot recompress in JXL, then I think we are shooting ourselves in the foot. -Jon https://github.com/libjxl/libjxl/issues/2284

Yeah, I know the issue, but it either got reverted or was never actually fixed

us yuv422 lovers destroyed T.T

yuv422 is transcodable

guys

subsampled RGB JPEGs (which XYB JPEGs end up as by default) are not transcodable

i was talking about rare specifically. tho I wish yuv410 was more common, I watched batman as yuv410... it worked out well...

why PackJPG from 200x, compress better than JPEGXL?

> You will get an error message if you try to decompress PJG > files with a different version than the one used for compression dunno but it's worthless to me, seems like they are making some very unacceptable compromises if you want an actual replacement to jpeg

Since subsampling XYB JPEGs breaks transcoding anyway, I was going to try 4:1:0 and see what it's like

Last I checked (a few years ago), everything could go denser than JXL, but JXL is designed for practical real-time image decode and others may not prioritize that. https://discord.com/channels/794206087879852103/803645746661425173/937627806408523777

PackJPG and Dropbox's lepton are archival tools first and foremost, not really meant to be an image format per se. JPEG XL transcoding was meant to be viewed and decoded progressively in a browser or image viewer.

but packjpg x2-3 faster...

faster + 5% lower

are they progressive?

idk

Lepton infamously has a hard time compressing progressive jpegs

https://github.com/packjpg/packJPG/releases/tag/2.5k

Lepton predicts DC from AC so in terms of data dependencies it is anti-progressive by design.

Lepton?

Well the JXL certainly is progressive

and why packjpg effective?

It doesn't need to be decoded during download, and can't be viewed while compressed, so it can use methods too slow to decompress or that require the entire file to be loaded first

old compressor still beat new jpeg-xl

Ok, but can you directly open the compressed JPGs? If not, this point is kinda mute

JPEG XL is much faster and useable than packJPG. As I said, packJPG is just an archiver, not an image format.``` ENCODE TIME packJPG - 20.83 sec JPEG XL - 3.74 sec DECODE TIME packJPG - 19.72 sec JPEG XL - 1.77 sec ```

where you get it

0.45

faster than jpeg-xl

I'm using a very large image, 11656 x 8742, 100 MP

Let me test on a smaller image

And JPEG XL is multithreaded, so it should be much faster

Okay 1500 x 1137 image, packJPG 0.15 sec. JXL 0.08 sec. Twice as fast

add in the mandatory decompression time

And the JXL being of slightly higher quality, with improvements possible in future

how log jpeg-xl speed

for* jpg transcoding don't

Don't what, multithread?

It seems to multithread for large images

100 MP image again``` cjxl --num_threads 0 -- 8.35 secs cjxl --num_threads 12 - 3.13 secs ```

-_-

this is like comparing ZPAQ to ZSTD, and saying "why is ZPAQ so much better (because it is denser)?" when that isn't really the main allure of ZSTD in the first place

0.45 seconds × 2844 bytes per second means it compressed 1280 bytes (1.28 kB), is that right? (or is that meant to be 2844 kbytes per second, i.e. 1.28MB?)

avrg. KBYTE per s

zpaq better

right, it says that in the left column, but then bytes in the right column, so it wasn’t really clear which one was authoritative

kbyte

this feels like trolling to me

i use zpaq for most packages

Maximal compression is not the ultimate goal for me (and for most people). Usability, versatility, and reliability are important.

> Compressed PJG files are not compatible between different packJPG versions. That alone is a good enough reason to not use packJPG for many people. Imagine if every version of 7-zip produced incompatible files?

Not even Lepton (another jpeg archiver) has this problem. As far as I know, it's files are compatible across multiple versions and it typically compresses better than packJPG.

Just wait until they learn about our faster decoding work... Sacrificing density for multiple times the speed? Blasphemy

🥺

Packjpg doesn't update

And what if it does? That's a poor argument

packJPG isn't even good as an archiver, it's more like a toy format, a proof of concept

It's not even the best at compression, that title belongs to Dropbox's Lepton

It's still being actively developed, is multithreaded, and it __**doesn't break backwards compatibility**__. It's good at what it does and to rub salt on the wound, it compresses better than packJPG.

can this gap be overcome by an improved jxl encoder?

Most likely not overcome, but the gap could be closer.

For example Jon is working on improving JPEG transcoding as we speak https://github.com/libjxl/libjxl/pull/4202

<@794205442175402004> another Cloudinary question – what metrics do you guys use for images, or what metrics would you say are important to you? I know AIMOS exists, but I'm guessing you also consider SSIMU2 & Butteraugli? Maybe just SSIMU2?

Or do you average butter & ssimu2 somehow maybe? not sure

Currently I think CVVDP, IW-SSIM, Butteraugli p-norm and ssimulacra2 are the most reliable metrics. But we just started JPEG AIC-4 with the goal of finding/making better metrics...

It s hard to read pytorch implem

gotcha – CVVDP in particular is very interesting

Just use MSE lol

/s

huh, interesting

Do we still have to do some system files editing to set jxl files as wallpaper in KDE plasma?

no

works OOTB

I don't get set as wallpaper for jxl file.

Ahh, using the context menu you mean. I have never tried that, I set up a wallpaper folder and just put JXLs in there

Which works without problems

hmm. I think it still needs to edit some files to get wallpaper option in context menu.

opensuse leap 16's beta still carries libjxl 0.8 - concerned this will keep performance degraded for gnome, kde and gimp for years if not updated before july's stable (many complaints about slow jxl seemed to cover ancient lib versions)

Is the API stable? If so can’t they all just share 1 SO?

There was a change in 0.10 that requires some tweaks IIRC

Huh, maybe not. I can't see anything in the changelogs

0.9.0 definitely made breaking API changes. I haven't noticed any since then.

Ah yeah, that'd do it > encoder and decoder API: all deprecated functions were removed:

Hello

anyone knows the best way to test out MozJPEG - I don't think it really is..... but I am testing stuff for my webpage.

Overall program I have with JXL is the combability as it goes for now.

Although I think AVIF actually looks better in lower file storrage or higher incoding. But overall... They seem close together.

Seems to be somewhat better details in AVIF while JXL smudge it out in lower with low files - JXL seems to be better with resaving over and over again compared to AVIF.

Sadly.... Browser had not made support for it, I know a lot of people would like that and yet.....

And hard to test JXL on my website when the browser does not support it.

comparing against the other 2.

something nice about JXL is you can see the image before it's finished downloading while with AVIF you won't see a single pixel untill 100% of the file is downloaded

I have been thinking of MoxJPEG but not figured out something to make the files yet.... kinda a lot of stuff to know to do things apparently.

Yea, but I am not sure that really does anything on my webpage with the Picture app I have as it kinda loads before showing anyway. But would be nice to test things of cause.

I have this auto gallery thing.

I'll fix a web url brb

https://jesusgod-pope666.info/images.php

I have 80.000 files, and around 40 GB.... I am looking to make them smaller and upload them to the website.

and some very slow computers here working with it.

I heard that MozJPEG is the best for the old JPEG file format, so I would like to try that as well and compare that.

By the way, a great image app for webpages.

the very best that I know, but it does cost money.

Actually jpegli is now the best jpeg encoder on the market right now

These may be worth looking into https://github.com/niutech/jxl.js for JXL and https://opensource.googleblog.com/2024/04/introducing-jpegli-new-jpeg-coding-library.html for JPEG

okay....... And what supports that?

Anything that supports normal JPEGs

It's a mozjpeg replacement, essentially

Well what app can I use to batch some files in that incoder.

ahhh okay.

does Gimp 3 have it?

I have just installed Gimp 3 on an old slim device running Windows 11, took what seemed half an hour.

I also installed a batch plugin to it.

On the moxjpeg replacement, comes from Google? Do we kinda trust Google....

It was made as a side project to JXL, using some of the same ideas

More dense: Jpegli compresses images more efficiently than traditional JPEG codecs, which can save bandwidth and storage space, and speed up web pages. How Jpegli works Jpegli works by using a number of new techniques to reduce noise and improve image quality; mainly adaptive quantization heuristics from the JPEG XL reference implementation, improved quantization matrix selection, calculating intermediate results precisely, and having the possibility to use a more advanced colorspace. All the new methods have been carefully crafted to use the traditional 8-bit JPEG formalism, so newly compressed images are compatible with existing JPEG viewers such as browsers, image processing software, and others.

It sounds good but.... I kinda have my trust issues with Google.

Same company, different department. Most here are from Google Research, working on JXL and jpegli

Well you guys are the experts, although of cause there is always a lot of oppinions out there on the internet.

Aha, I though JXL was made by someone else then Google.

Still kinda trying to figure out what to use and such for my webpage.

Like 40GB is just way to much, I tried some of the other formats and it cuts a lot of it off.

it was made by people from Google and also people not from Google

I think I can get the images down to maybe 4 GB.

I will have to test the image gallery as it load 200 files at a time.

I have 600 files being made into AVIF at the moment, will take some 3-5 hours until finish on my slim client.

talk about slow slow slow.

but that is what I have to deal with.