JPEG XL

I remember when imgur wasn't evil

Imgur doesn't make a statement about this

do they block traffic from mainland china?

or does Chinese GFW block imgur?

Of course that GFW blocks Imgur

There are a lot of things there that are "export-only" and not allowed for their own subjects

Idk if imgur is owned by the CCP but I wouldn't be surprised...

Seems the entire world is these days.

Simply overused by services in Taiwan as they all directly display images from Imgur

i remember when i was like 10 years old

i was on a website

and tried to upload an image

the extension was *.jpeg

but they only accepted *.jpg

so my dumb ass at the time

looked up a web based converter

This still happens nowadays

cause i didn't know i coyld just change the extension

The system may warn you

How does anyone use HDR-VDP-2 like its used [here](https://cloudinary.com/labs/aic-3-and-hdr) if its written in Matlab?

It runs in octave too, that's what I used

meanwile I thought image formats were all the same because a website accepted a PNG after I changed extension to .jpg 😆

Many a year I spent renaming extensions thinking I had converted them

https://www.rachelplusplus.me.uk/blog/2025/06/evaluating-image-compression-tools/

Interesting comparison between codecs

it's AVIF-centric, but it has <:JXL:805850130203934781> tested as well!

it also has a section for multi-resolution encoding

how's performance (in rough terms) btw?

e.g. 1 MP/s, 0.1 MP/s, 0.01 MP/s...

I haven't measured, I think pretty slow but fast enough to compute it for something like a dataset of subjective results in a reasonable time. Probably too slow to use it inside an encoder or something though.

> there's just no way to get lossless 4:2:0 format images This hurts slightly to read xD > Ideally the command-line tools for JPEGli/JPEG-XL would add support for a lossless 4:2:0 format like YUV4MPEG2, as that would allow a fully fair comparison. Makes sense when you're using video input, to give 4:2:0 to the encoder, but generally subsampling shouldn't be used at all above quality 80~ so you're shooting yourself in the foot. Could probably be done *relatively* easily though, given all the piping for JPEG input and JPEG Transcoding is already there for jpegli and JPEG XL

Interesting results though, and the multires testing makes me think my horrible `2:2:0` subsampling idea might not actually be that horrible....

Assuming any decoder would even decode it

like, luma being shrunk horizontally by half?

Pretty much yeah. Ideally the entire image being halved, but via subsampling in the decoder so that the result is the same size for compatibility The same as my libjxl PR, at distance 10 the resolution is halved internally

yeah, I can see how doing that could work

at least at quality levels in between a 1x and a full 2x downscale

I think every JXL file is suspicious...

filescan.io is usually amazing, I guess it hasn't quite been updated to support JXL properly yet... this must be some generic logic then, and I wonder why it's wrong about it? like the extension and mimetype are literally the same

Approved by the Chrome team

*Renames my_photo.jxl to my_photo.image/jxl*

nah we just need to convince IANA that jxl should become a top-level mimetype, not something under `image/`

great, just the thing to upload a single 1280x picture to telegram

SVD Vt+U DHT PCA+PCA-matrix

drunk

looks like you got yourself some DC offset

yes, I experimented with WAV saving to jpeg image. but, in this case I experiment not with the actual signal, but with the difference of the signal at each sample, it turns out to be much more resistant to interference, much stronger than all other algorithms, but it turns out to be such a shift along the entire length of the signal. But it sounds great

Unfortunately, ADPCM turned out to be extremely unsuitable for image noise of this type, when all data coefficients change, although it is technically more efficient, and the freed-up piece of free data should in theory be used for data recovery. But it's all too complicated. not for me.

all these algorithms also give too much noise or distortion at the wav output if the images are compressed into jpeg

I'm starting to understand why everyone uses DCT, it's really simple and just works

but I can't understand why in Wikipedia in the article about DCT they didn't even mention DHT. and in the article about DHT they didn't mention DCT. And why do they have different names at all, although in essence they are identical algorithms, one of which has only COS and the second COS+SIN. it seems that these are not connected in any way, although this is not so. Strange.

Haar wavelet does a great job of this, much better than other algorithms, including Lifting-Scheme DWT

Haar wavelet (DWT) Lifting-Scheme (DWT) FWHT (Hadamard transform) difference between wav samples (with logarithmic normalization) raw wav samples

jxlatex jank https://github.com/varikvalefor/drawingstuff/blob/702ba3c2c5915c592fca9bac09c7c5b646fb1482/zbas

An inside joke? 😂

A british one more like, though I'm not sure why

has anyone thought about picking this up? https://github.com/colour-science/colour/issues/1118

1GP/s SSIMU2 throughput is real 👀

Only about 360MP/s for butter though (Single high end consumer computer)

Random thought, we could make a JXL server tag that Discord added recently

Nevermind, it's paywalled as usual

Don't we have a discord dev here somewhere? Maybe they can arrange us some free Nitro or whatever the DiscordCoin is called

Scott kidder, but i dont think an arrangement would be possible

I'm still curious about the empty EXIF tags https://discord.com/channels/794206087879852103/805176455658733570/1385721153116569850

just turn on the server tag feature flag (TM)

https://tenor.com/blflC.gif

but I must say, having a server tag is definitely worth it for discoverability purposes

Think it costs 3 server boosts <:KekDog:884736660376535040>

Wanted to suggest the same thing, but then saw it isn't free and don't think there will suddenly be people who will want to boost the server since I've been the only person doing so for a pretty long time

I just don't want to give Discord any money °-°

I think the problem is, it goes from 2 boosts to 7 for level 2. So as long as 1 person is, another is pointless, and then you need a 3rd and half of a 4th for any benefit

If the tags were 2 boosts instead of 3, I'd almost say it's worth it to get the tag instead of level 1, since we don't really make use of it anyway

past the minimum for server tags, theres no point giving discord any more money. give devs and projects like xl converter and thorium your loose change or regular 1$/month, they need it more

while a mere 100 dollar bounty would get jxl adopted inside software with actual users

peanuts for guaranteed results compared to potential visibility increase with no guaranteed uptake

Discord's Nitro is less useful comparing to Telegram Premium

<:Ashley_WHAAAAA:800762210833006622>

using custom emoji from other servers is so worth it

Vesktop

https://github.com/Vencord/Vesktop

and it's more minimal, private and secure compared to std discord client

especially better on Linux

Posting that in the channel with Discord staff is a bold move...

im sure they know about it. its not like we created it

people have actively pinged him with images and questions about stuff like this lol

This honestly seems too excess to post here.

sometimes I play (in my mind) with the idea of a JPEG XL vinyl. A JPEG XL image where the audio would be stored as a spiral circling (in a square way) towards the center, and the absolute center would have the label

huh

it is not entirely clear how you can twist the spiral squarely, because at 90 degree bends the signal will be completely ruined

one sample per pixel of course

the usual disk plays 77 rpm, i.e., 37000 pixels per round (for 48 kHz sampling), a 10k x 10k image could operate roughly 77 rpm at 48 kHz

if jpeg xl can generate pixel dots in a given shift algorithm, why not, it would be an effective recording of a sound wave, and if the image is of a known size and has a pre-known generation frame, it will be possible to decode it normally as wav

33 rpm would need more than twice as big of an image

I don't think it makes sense to talk about revolutions per, it's not appropriate, the JXL disk is not physical. You can read as many pixels as you want

a disk without sound pressure changes would be fully gray (32768 is a 0 pressure), each pixel is a sample from the 48 kHz wav file

well, revolutions per second will relate to how the final disc looks like

will it look similar to a traditional disk or not

Y channel would contain the R+L signal and the X could contain the R-L

4 bits, or 16 amplitude samples, is enough for a wave. But for each sample count, 1 pixel is needed. So, the main problem is that the image will be about 5000x or more, only for mono at 32000 Hz

no, we need 16 bits of course (the same as CD) and 44.1 and 48 kHz, to losslessly store cd-quality

I understand what you mean

exactly, there will be somewhat random correlations that will be visible

to make the correlations happen most consistently, the "rpm" should be ideally constant -- but that of course makes the resampling "interesting"

the big problem here is how to generate it natively in jpeg xl. I don't know anything about it

the problem with reading the wave is secondary, it is unimportant, if the sample misses it will not be noticeable, because it is a world of waves

you just create it in a simple lossless format like PNG or PPM https://en.wikipedia.org/wiki/Netpbm

if you rely on uncompressed stereo wav with 16-bit per sample (or 32 bit float perhaps more common nowadays), the IO there is rather easy, too

to make revolutions per second is a complication, from the physical world, as I said, there is no need for this. You are not making vinyl, but a CD wav disk. because there is no problem in reducing the rotation speed as the file is read, because all the variables are known in advance

yes, it is just that then correlations radially will not be related to time

it will be another "hash function" that will destroy any visual patterns that would possibly emerge otherwise

think of a beat in a song, if they align radially, they will form a pattern

but if the radial speed changes, that pattern will continue to be skewed as the song proceeds

(it might not matter much)

probably better to start without it

Well, let's say I already did this, literally the day before yesterday, only using an 8-bit channel more natively I also used the alternative wave difference method on the second image. It worked perfectly when I did tests after compressing it to jpeg.

nice

another possible (and efficient) encoding would be to use 64 sample DCT, store the coefficients into the 8x8 block

ringli is not far from that

https://github.com/google/ringli/

shorter DCT than traditional in audio works better for higher quality audio -- and no need for the "MDCT", that just messes things up

This is acceptable only for the method when I encode the difference of the wave. Since I have tested dozens of all possible types of transformations invented by mankind, just to test the compression tolerance. Simply direct recording of the wave shows itself poorly. But the difference of the wave is excellent. And also haar wavelet by the way.

what is a difference of the wave?

difference between consequence samples?

no builds, no links, nothing. Looks like an abandoned internal project developed by a couple of people just like that... looks bad... Even Meta Encodec look better. And I want to note that in extreme compression Encodec demonstrates excellent sound quality at 12 kbps

seems to be correct. Only ADPCM turned out to be too digital and became completely unreadable when compressed in DCT. I had to write my own algorithm that took 16 levels of the wave with scaling by logarithm, and each reading made a comparison with which wave would be closer to the original. That is, the information says - how much the amplitude needs to be shifted in the next reading, up or down

after compression in jpeg the error accumulated, but the sound sounded fine

after compression to jpeg

the main problem, as I said - for each count you need pixels, for music, and even more so stereo, and even more so 40,000 hertz. you need a lot of pixels, so many that it is better not to consider the option with 44 or 48

even if pixels have excellent 32 bit float quality

or just 16 shades in 4 bits. pixels amount will not decrease

mono 24000 hertz is cool, retro is in fashion these days

this is 10500 hz

to upload exactly in 1280x1280 telegram jpeg pic

It's a pity that no algorithm gave more advantages, in quality or in size, the best for compression of the Analog, turned out to be the Analog

Unfortunately, I have never succeeded in successfully recording sound on paper. No analog or digital algorithms

it is an unannounced audio compression project 🙂 and right now inactive

you could add a small bias towards zero in decoding, like 5 Hz high pass filter

can take a ready-made sound wave and draw a line at the top, since the limit values ​​are known,can align it... But these are all small things, my project is not serious

why does it say it's archived?

Is there any advantage opus has over ringli aside from hardware/software support?

no advantage to use opus that I can think of, ringli compresses 60 % more in the high quality audio range, 1000 kB Opus becomes 400 kB Ringli

archiving is a reversible process that Google uses to indicate activity of an opensource project -- I think it helps security efforts to not to stress about this codec (I'm guessing here, not really sure what we want to signal with 'archiving')

I wish there was a demo page with some samples of music and voice in various bitrates... I think you mentioned it's optimized for transparency. Can it compete at ultra crunchy bitrates as well? Right now they're trying to make opus better at very low bitrates, plus dropped packets.

I don't know what it does at ultra cruncy bitrates -- the internet speeds 10x every 10 years, it is not clear to me why we would want to make audio worse right now

Well I wonder if it could eventually be used in telephones for example.

there is no real reason any more why telephones cannot be transparent in audio quality, or even supernatural -- more clear than the original

I'm practicing violin over the internet, and it would be nice if the quality was better, but it is already good enough for the practice to be useful

I use sonobus for audio over internet, musicians are actually an intended audience of it > Simply choose a unique group name (with optional password), and instantly connect multiple people together to make music, remote sessions, podcasts, etc.

in my experience, it works extremely well

~~time for a rust ringli decoder~~

How would a supernatural codec work or be useful in practice?

Wouldn't it just hallucinate?

Even worse than lossy

the same like a BBC documentary does for insects, they just look better on TV than in nature 😄

a supernatural audio codec would slightly reverse the great vowel shift so that it would be fully reversed in the next 500 years

lmao

It would also correct people's bad grammar

but also make audio slightly more clear, by adding minor emphasis on end consonants etc., perhaps also fix such things

And it would make all politicians mute

And make your parents say "I approve of your lifestyle"

I was trying to see if there was any news about JPEG XL support... A little outside my price range xD

"Tickets include coffee" that better be some good coffee <:KekDog:884736660376535040>

what Opus bit rates are you counting as being in the "high quality audio" range?

opus has an encoder and a decoder so i don't see the advantage in using ringli <:SadCheems:890866831047417898>

I don't know why it's not obvious, but no one has written anything about ringli anywhere, not because it's unknown, but because no one has been can to try it. Isn't it obvious that no one really gives a shit about the source code, if there is no executable file, then the program does not exist. The Linux era never came.

Actually, VoLTE technology already has its own EVS codec, so.

for bluetooth there is a new codec LC3 (which is declared as better than opus, but this is a complete lie) in 2025, the best codec for 40-160 kbps is the undisputed leader OPUS without any competition at all. The fact is that at these bitrates there is no point in using anything else at all in principle. This is a lossy monopoly. The exception is bluetooth, to be fair, since opus is expensive to encode and decode, compared to other codecs. LC3 only makes sense for bluetooth.

USAC sounds better at bitrates below 40. If you take even lower, the best will be Encodec neural network by Meta at bitrate 12. If you take higher than 160, it is better not to use opus, depending on the task: For mass distribution, mp3 320 is enough for everyone. For games, Vorbis 192+, for video, aac 192+.

I could hear differences between original and opus with opus at 512 kpbs or so (shaker loosing variance in dynamic/emphasis)

I believe this was in the 256 kbps opus use

I don't like 128 kbps opus, it sounds like from a distance or through a thin wall, missing a lot

Very nice. I'm looking forward to testing Ringli and giving feedback :)

My phone supports some form of hdr but hdr images look bad on chrome. The OEM probably did something bad.

I have the same issue with my phone

Is that xiaomi or mi?

Samsung

Oh. I thought it was xiaomi's fault

Webpage link?

https://jpegxl.info/resources/hdr-test-page.html

Hdr avif looks funny on Google photos

We tried compiling the C version, but <@207980494892040194> kept running into dependency issues. Don't suppose you could help figure it out?

I don’t know if it actually self compiles

What dep is missing?

I got the zig version to build and it works like a charm

However, the C implementation spits out this `undefined reference to 'WinMain'` and a few other errors as well

My environment is msys2 (mingw64) using gcc `gcc -Wall -O3 screen_content_detect.c -o scd.exe`

<@207980494892040194> the reference doesnt have a main function

<@297955493698076672>

So it can't even be built as an executable right?

right

I could have AI hallucinate me some code to get it working, but the zig version works for me.

yeah, the C implementation is just the helper functions 😛

maybe I'll shape it up into a proper executable in the future

i don't think u necessarily need a main function, its a reference implementation with example code, for all intents & purposes

the Zig impl is not a reference implementation, it is based on the C code and bundled into an actual tool (if you could call it that)

https://engineering.fb.com/2015/08/06/android/the-technology-behind-preview-photos/

https://medium.com/@duhroach/reducing-jpg-file-size-e5b27df3257c

Blurring the chroma channels before compression... It made me think, maybe encoders like libjxl can apply several different pre-processing techniques to the image before compressing it, to make the data more ideal for the type of compression being used.

Like subtly re-arranging some of the barely-perceptible noise in the image to make it less random and more aligned with the compressor.

Days without Pashi mentioning noise: 0

I often think of ideas like that, but preprocessing shouldn't be needed, the encoder itself should be improved with the same ideas

You know the entire, the ENTIRE premise behind lossy compression is separating intelligible"signal" from unintelligible "noise" in an image, and preserving the "signal" without wasting bits on noise.

So yeah of course I talk about noise a lot because you kind of have to in order to talk about lossy compression at all

The reason why DCT works so well is because it preserves what our brain sees as important very well, and what our brain sees as noise, it changes the noise pattern into macroblocking patterns and other DCT artifact patterns that sometimes blend into photographs

Being able to recognize what data our brains don't care about, and re-arranging that data so it looks the same but is much easier to compress, well, that's the whole premise of lossy

https://engineering.fb.com/2024/03/26/android/instagram-threads-hdr-photos/ listening to the podcast, I guess Meta landed on using Ultra HDR JPEG for their HDR images on Instagram & Threads

*sigh*

we'll never be able to escape 30 year old image tech I guess?

not any time soon

android doesn't support jxl at all yet xD

big apps can force adoption since they handle their own entire stack

ie, browse facebook slowly in a browser or fast if you use our jxl-serving app - consume even less bandwidth and cycles than a desktop browser with adblock

lot of potential for bypassing browsers

for android, imo itd be smart getting the preinstalled gallery apps onboard. samsung's already includes the jxl decoding routines of *dng 1.7* and theres like 200+ million installs of a version that includes that support

imo people are focusing too much on websites and browsers whereas spreading decoders within apps (yours, your web service+galleries) should *precede* any use

and some 30-year old tech called "PNG" just got updated

mfw realizing 1995 was 30 years ago

https://tenor.com/b0CbE.gif

PNG is kind of an exception though -- you can convert from and to other lossless formats without generation loss

I guess we could have Ultra HDR JPEG to JXL compression heh

Isn't Ultra HDR just a gain map?

that's my understanding

gain map with a stupid name

but I'm not sure if JXL can preserve the gain map if is big enough

IIRC there was a metadata limit?

iirc there was some talk about doing a spec extension or something for gainmap support with transcoding in JXL. IMO it should also be built around supporting JPEG XT as well if they are going through that effort

PNG 4th spec is to add gainmap as well

you say that but we haven't seen a major app do this, no?

some do but its not too common as that increases attack surface

flutter apps sometimes ship their own decoders, (no jxl decoder/binding that is drop in compatible) electron/webview apps obviously support what the chromium/webview supports and some kotlin java apps use coil and that other api, but it has performance limitations and explicit integration that not many are willing to do

https://discord.com/channels/794206087879852103/803574970180829194/1308032222112120854

after a quick glance over this it seems like it's generic enough to handle JPEG XT data (such as alpha channels and whatever else) though I'm a bit tired ATM so I haven't looked too hard

moar ``` (export CMENE=shininglikecrystaltiaras && cd $CMENE && djxl $CMENE.jxl --output_format apng - | ffmpeg -y -f apng -i - -vf 'select=eq(2\,n)' -vframes 1 $CMENE-ctino2.png) ```

A game dev asked me for help with their texture processing, asking about using PSNR and SSIM. I pointed them towards SSIMULACRA2, and I'm happy to see they're already implementing it

why did they need to reimplement it?

They're making a wrapper for it

oh I see

for diffuse/color/base textures SSIMULACRA2 would be excellent however for stuff like specular masks or normal maps it might not be the best choice since those kind of textures are in linear space and not meant to be viewed directly and just as data for a shader

similar thing goes for image resizing/downscaling with or without gamma correct scaling for generating mipmaps and whatever as well I assume

Normal maps are DXTnm only right now anyway, so there's nothing to compare against

https://github.com/Yellow-Dog-Man/Ssimulacra2.NET

https://www.energuide.be/en/questions-answers/how-much-power-does-a-computer-use-and-how-much-co2-does-that-represent/54/ > A desktop uses an average of 200 W/hour when it is being used > A complete desktop uses an average of 200 Watt hours (Wh). A site named “energuide” with such sloppy use of units doesn’t really inspire confidence

especially when both units are wrong XDD

they probably meant 200W and that s it

it’s like Goldilock and the Three Bears

but 200W is huge for a standard laptop

yeah, this is for desktops

oh yes nevermind, then it s correct

or do you mean the 50-100W they cite for those?

well 200W definitely seems a lot for an average of a consumer desktop

50W would be more realistic probably right? I never did actual measurment so I don't know for sure

my 16" MacBook Pro idles at 10-20W so their laptop estimate seems a bit high

my desktop, around 150W including the screen

ah yes the screen

(and the screen alone seems to be about 30-40W at the brightness I use it at)

my mini-pc with a celeron inside is at 2W even under load ahah what a ~~beast~~

it doesnt even have a fan

no moving part

no noise

no dust accumulation

don't ask it to encode av1 though ahah

or run an LLM

poor celeron

it has 8GB of RAM though! more than 4

although perhaps gemma 3n could be worth a try?

I don't use any AI, I hate them ahah

so I will not try sorry

gaming laptop may use 200 watts during heavy gaming.

While it's plugged in

When unplugged they don't drain the battery that fast

I wonder why people don't ever use kilojoules

1 Whr =3.6 kjoule

Usually we better know our average electric consumption per hour instead of per second for object "I use my computer for 30min" we want to divide have 100Wh for a 200W object Not... Multiplying by 1800

And what the heck is a calorie? 4184 joules per kilocalorie? Why?

Why can't people just use standard SI units?

1 terabyte = 1,000,000,000,000 bytes! Not 1,099,511,627,776 bytes, like wtf?

Ounces? Pints? Dry ounce? Wet ounce? Gallon and quart? Cups? Are liters and grams just not good enough for people?!

It drives me crazy when trying to compare prices, and one item is priced per ounce and the other is per some other stupid measure

You can't even tell what price something is and when you read the nutrition label, it's not nutrition "per 100 grams" but rather it's "per whatever arbitrary amount we decide to manipulate the numbers"

America sucks basically

Sorry friends

I know Americans are always either really proud of their country, or really ashamed for some reason... Being proud or ashamed are both cringe. But this drives me mad when trying to shop.

any good tools that are good for specifically checking for corruption? wanting to batch encode a whole wackload of images to lossy, but them not being corrupt is kinda critical and veryfing each one is not really an option. I'll be encoding with e7 d0.5, maybe using the progressive_dc dunno yet, so I'm not conserned with fidelity.

just care about super obvious corruption, even if its a small portion of the frame

what file format are the images you want to check?

iirc https://github.com/qarmin/czkawka can scan for broken files but as for "corruption" idk what could do that

ah yea it can scan for corruption, dunno if it catches xl tho

I bought a ryzen 7 fanless pc, with 6 or 12 cores, don't remember -- it feels really nice -- I plan to use it for my spatial audio experiments / robotic sinfonic orchestra. I think it works with 12 W or so.

Hello could you allocate some time and fix that desaturation problem is jxl.

just jxl, I am doing jxl lossless > jxl lossy. I doubt I will hit an issue, but reliability is key here.

I made my best effort ~month ago

what distance ranges is the desaturation problem at its strongest in the current head of libjxl? (in relation to the luma quality)

I now have a checkerboard pattern stuck in my vision, but I just confirmed it's the AC of the B channel. We need to create a new quant table with a shallower falloff. Though subtle, it's present even at distance 0.1 with flicker tests

Distance 1

Jon had an interesting theory the other day https://discord.com/channels/794206087879852103/1288790874016190505/1395052409105154168

Huh... Effort 4 really shows the B channel bleeding

Main (176 bytes) vs 0.8 (141 bytes) at Distance 1 Effort 7

This is just a 9 x 9 yellow and black checkerboard. It's the same results for larger images, but they hurt my eyes....

Interesting that in all encodes, the bottom right pixel is always full saturation, but the rest are dull

I kind of like the idea of artificially making the input a bit more saturated so that the decoded version is correct – a sort of “chroma gaborish”, in a sense

(not quite, but you get what I mean)

or chroma-preserving filter

I'd definitely say people would prefer the output be slightly more saturated than slightly more dull. But there's a few different ways to fix it, incrasing the saturation internally, adjusting the quant table, different rounding... Would need to try them and see what's best, but 0.8 seemed to be pretty close already

increasing the saturation has the advantage, over quant tables, of not having to signal different quant tables

Realised I should try Hydrium... It was not happy

Signalling a different quant table for B should only be a few bytes when parameterised though, and right now main is already 20% larger than 0.8 while looking worse

570 KB Main and 450 KB v0.8

I think maybe it is possible to do RGB -> XYB in a clever way so that X and B are smoother than what you get from simple RGB2XYB, while the result after XYB -> RGB and clamping is the same. After all, there are many (X,Y,B) combinations that map to black after clamping, and naive RGB2XYB will only use (0,0,0).

sounds a bit mozjpeg-like

kind of, since it's exploiting clamping, but here the aim would be to avoid chroma desaturation, not luma ringing. Though it might end up also helping with that, since you'd do something like mapping black to something like (0.2, -0.3, -0.5) instead of (0,0,0) if the surrounding pixels are close to (0.2, whatever_Y, -0.5)

(so it would seemingly stretch contrast in Y, which will reduce visible ringing after clamping)

In any luma-chroma space, e.g. XYB or YCbCr, there's a large part of the color cube that is left unused if you just apply the forward transform — close to black, chroma always gets close to zero, and close to white, the same happens. So there are "subnormal" YCC values that also have to map to some RGB values (either to some in-gamut color or to an out of gamut color that after clamping does become an in-gamut color) and these values could be used in a clever forward color transform. Basically instead of converting RGB to YCC pixel per pixel and using only the "normal" part of the cube, you could choose "subnormal" YCC values that convert back to the same RGB values if those subnormal YCC values create less overall entropy than the normal ones (e.g. maybe increase Y entropy but reduce entropy in both chroma channels more). How to do this efficiently is nontrivial though. I don't know how to find the set of "subnormal" YCC values for a given RGB value — I suppose the set is empty for intermediate-luma colors, and gets larger as luma gets closer to 0 (and I suppose also as luma gets closer to the maximum value, though I'm not sure if we're supposed to clamp colors brighter than rgb(1,1,1) or if those colors are supposed to be actually brighter (i.e. rendered as HDR even if the image is nominally in an SDR space).

are these results from libjxl head?

I can make this better (at the cost of some compression density elsewhere)

Don't desaturate my dragon 😿

It doesn't matter how it's done, as long as it works and is cheap to do. Even if it's a pre-processing hack. Isn't there a way to predict and compensate for desaturation effect so the final result is the same color as the original?

Yes

I'd try the new quant table with increased B AC first. It should have minimal impact on other image properties with minimal overhead while being fast to implement and test

I don't think that's the right approach, to increase the precision of the quant table's higher frequency coefficients. The human eye is not that sensitive to blurring of the chroma channel. The problem is that the estimation of the final color vs the original color is way, way off. If that can be corrected by predicting and compensating for the error, either during quantization or beforehand during a pre-processing filter step (like <@604964375924834314> said) that would make a lot more sense and you would not have to pay the price of changing the quant tables

Ideally it would be compensated for DURING the quantization step, not beforehand, but either way, whatever works and gets us there.

Even if the B channel AC is to blame, you don't need to change the quant tables to predict and compensate for the color shift

You just have to predict and factor it in, either before or during DCT

I'll try to reduce it with more traditional approaches first

the blue component desaturation is now the problem, and red-green is ok?

I noticed yellows getting desaturated.

If red-green desaturation is present, it is not perceptible (as far as I can see), which is what matters. Blue-yellow is quite notable even at lower distances.

Here is a good problem case image Left = Original, Right = JXL d2

that is too much blue

I noticed greens getting slightly desaturated but it's harder to notice compared to orange and red and yellow.

I think it might affect all colors... but it's easiest for me to notice with yellows and oranges and reds simply because those colors have more cone receptors in my eye

I don't see it with this one

I can definitely see the difference side by side even on my iPhone

The left image is way more saturated and the one on the right is pale

It looks more deeply red and orange, even without zooming in

I would rank it "crazy obvious" level of difference

It looks like the reds are replaced with a pale washed out vomit yellow

I think the Detroit factory image is still probably one of the best examples of the problem

Or anything with deep red-orange

in testing its actually a problem with green primarily followed by yellow

ez to tell with some basic subtraction

Are there any colors that aren't affected? Like... Blue?

i mean considering one of the primes is off i doubt it

I have a feeling it would be hard to tell even if deep blues were desaturated since our eyes are much less sensitive to deep blues

I don't think this is a valid way to tell since it doesn't represent how sensitive the human visual system is to the difference

i mean is 255 than accurate if not then well

For example the color of the diff/subtraction map is not the same color as the original image

And for a variety of reasons it doesn't give us valid insight in terms of difference to the human visual system

It tells us more about objective/digital/mathematical difference but not psychovisual

It would be better to do an A/B flicker test to see which areas change the most visually

For valid insight

sure but for lossy it should artifact not color shift

examining the range of that green block shows wild inconsistency's

granted even on stupid high zoom it's impossible to perceive

but thats with the assistance of algos to smooth it out

for reference yee old jpeg

also has problems with yellow clearly but 0 with green

webp/avif largely the same story

Looks like olde JPEG has a problem with AC details around the text but the background color itself matches

Meanwhile JXL screws up the background color and not just the text details

Also the red looks just as bad or worse than the green

yep while ill admit the testing methodology is nowhere near perfect, it does have a decently accurate representation of harsh flaws

Yeah red and green is screwy

ref img btw https://htmlcolorcodes.com/color-chart/

web safe color chart one

Still, in order to get a true idea about how bad the problem is and where it exists, is an A/B flicker test at the bare minimum...

yea mostly just wanted to share a ez way for regular ppl to see the problems very clearly XD

throw img in pipeline > convert > subtract > use eyeballs 🤣

Did you do a flicker test? Side by side is more difficult to spot. But still perceptible for me.

You can replicate it within a minute or two using a chevkerboard, since it's all AC/HF. Interestingly I can't see it on my phone for the checker patterns, but it's obvious for Sapien's image. Likely depends on how saturated the display can be too

To see if this is a problem with Jyrki's monitor, or eyes

at first, I thought I couldn’t see it because I was looking at the blue parts (where you can see some detail blurring but it’s not really clear that anything happens to the saturation)

it’s much more visible in the yellow parts

flipping between the two images, the yellow clearly becomes more grayish

The issue is that blue gets more saturated due to quantizing/rounding, which desaturates yellows and reds

Yellow is on the opposite side of the spectrum as blue. It's weird saying it gets "more blue" rather than just saying it gets closer to zero or less saturated. While technically "closer to blue" and "closer to zero" are the same thing in this situation

Anyways it's really weird how Jyrki seems to be the only one unable to see what we're seeing

I can see yellow become grayer, but I wasn't seeing the red-green getting less saturated. I'll get Sami's (spider-mario's) help tomorrow to see what I should be looking at.

I use two monitors (macbook pro and a rare dell 8k, but I run it in 4k mode now)

I acknowledge that it can be that my eyes are less sensitive for this than other people's eyes

we were smart enough to add two 3 bit values for X quantization adjustement and B quantization adjustment -- the easiest fix is to just ramp up the precision by adjusting those

Ramping up precision is expensive though

You have to pay for it

Correct, but due to the XYB transform, 0 on the B channel can actually be more blue for saturated colors like yellow. This was an example of increasing only the B channel by 2. The result was the RGB image having an increase of 24, desaturating the yellow https://discord.com/channels/794206087879852103/794206170445119489/1375373628199272550

Do you mean this? https://discord.com/channels/794206087879852103/794206170445119489/1375384819231490048 Because we tried and it didn't work

If you can somehow predict and compensate for the predicted color-shift error, you don't have to pay for additional precision

during the more active butteraugli/JPEG XL I used NEC and EIZO photography quality monitors, now everything is more usual

Original, Head/Main, Maximum boosted B precision via 3 bit adjustment, v0.8

v0.8 is still the most even and saturated result, while being 20% smaller, but still has some desaturation too

very interesting

we do quite a bit of increased 0 quantization for chromacity, and those heuristics have changed over time

perhaps it would be a good idea to bring them back to 0.8 kind

That would explain it, as for yellow 0 in the B channel results in more blue instead of less as I mentioned before

An interesting note, the bottom right pixel always has the original color. For the recent images, that's just black, but in my last test it's quite obvious https://discord.com/channels/794206087879852103/794206087879852106/1397219407650095227

Hmm, I can bisect it somewhat down to a change between v0.8 and v0.9, but before your AC strategy PR

Though, it'd likely be good to aim for even better saturation, than just rolling it back to v0.8's level

My tiny test image (It works at higher resolutions, but this saves on encode time and my eyes hurting from moiré)

I'm thinking it is likely in quantization

true

did at some point during JXL's development implement a trellis quantization strategy that can decimate near-0 coefficients to 0? sounds like that strategy might be malfunctioning for these kinds of images if that's the case

mainline SVT-AV1 has a similar issue where near-greyscale HDR content looks blotchy because the RDOQ process can be too greedy at decimating small coefficients, therefore causing periodic undershoots/overshoots in the chroma channels

my fix/workaround was to make RDOQ be less aggressive for chroma blocks that only have a couple small coefficients <:kekw:808717074305122316>

I feel like given how colour data is more patches and gradients compared to luminance, if someone would make another new format, Modular feels like a better algorithm for chroma data

I don't like trellis -- it feels just too slow and similar benefits can be obtained with other heuristics, like mozjpeg has trellis, but jpegli doesn't

There have been several changes to near-0 coefficients, particularly related to chromacity -- I think these are the reason for the degradation

yes, this is the way -- I have some of this in place for y already where I calculate 4 quadrants of energy within each dct block, and try to maintain the energy by even 'rounding' a very small value up to 1 (or -1) to maintain energy

I think that would fix it, internally the B values were off by 1 or 2. Does it have much of a speed penalty?

yeah, that sounds like the smoking gun

Maintaining the same energy... Sounds like error diffusion.

Nice

there is an analogy with it, just more hacky than usual error diffusion

The hackier the better when it comes to this kind of thing

As long as it works

As if we need libjxl to be any more confusing...

What's confusing is the over(ab)use of C++ template hell, and the messy structure of the source tree.

this part of the code is just honestly confusing, no additional confusion was necessary to be added

Clever hacks to preserve fidelity are a good thing

They are inevitable when making a good codec

starting from https://github.com/libjxl/libjxl/blob/73beeb5409cd805cf8e957b2f33467be74dfbfe2/lib/jxl/enc_group.cc#L58

there is a bit of additional confusion mixed in

my estimate of human population who deeply understand AdjustQuantBlockAC function: 1

also, it is not clear to many why we need QuantizeRoundtripYBlockAC

Anyways the color desaturation thing is really severe, so I am glad you thought of using that "energy preservation" trick you use for luma and applying it to chroma as well...

Currently jxl is probably the worst codec of all when it comes to preserving color fidelity

And it affects jpegli too

Not even libjpeg has such an issue

Sure other codecs have other severe problems, but not this color shift issue

It's unique to libjxl (and jpegli)

That's because XYB is unique to libjxl and jpegli

does it affect jpegli without XYB?

Well, I discovered that Adaptive Quantization really hates small images Original, jpegli, XYB, jpegli-NAQ, XYB-NAQ

Even then, the final XYB image is still slightly desaturated compared to YCbCr next to it though

Very slightly for non-XYB, but still less than JXL currently Original, jpegli, XYB, JXL

idk, I haven't tested.

I cannot tell the difference between those 4 side-by-side...

Let's roll it by again then

But I notice there is a lot more blue and yellow chromatic ringing in the 3rd image

Also I prefer 1x scale comparisons

Especially for this color issue, you do not need to zoom in to see the color shift

The thing is, I notice the color shift in almost every image. But it's not as obvious to me here.

I zoom in because it's in the areas of HF content, which are small details

I do see the desaturation, that said luma artifacts appear to be the most noticeable to me

The desaturation I've noticed and complained about were all very obvious from a distance

And affected the entire image, not just small details

Definitely depends on screen brightness too. I couldn't see it in sunlight, or with the brightness low, but turning it up in a dim room makes it obvious

pegj lx

true -- this makes a big difference in observing this

It's likely for a similar reason. Such saturated yellow is in a very narrow range, so lower screen brightness peaks at the lower saturation, making them look the same The AQ heuristics aren't aware of the narrow range, so B also gets clipped to a lower value (or zeroed as you said before)

https://youtu.be/hCQCP-5g5bo

I've been sent that a few times, pretty dissapointing for me. Didn't even use an image file, just drew onto a spectral synthesiser. Easily could've used a tiny PNG or a JXL art and gotten it to work

can some folk test https://github.com/Quackdoc/cosmic-files/commits/jxl-preview-gallery ? need to know if it's usable enough to push make PR I've had some images fail in weird ways, but my images may just be outliers. press `space` to open a gallery view or `ctrl + space` to open the details pane and just focus a jxl image and use arrows to navigate around

im mostly concerned about performance and compatibility, I dunno if I need to put some limits in or anything

it may also crash, if it crashes on an image, thats probably hitting https://github.com/tirr-c/jxl-oxide/issues/473

so I just discovered something very funny

if you type subprocess.run into your browser, trying to google the python function, it takes you to `http://subprocess.run/` instead

but <http://subprocess.run/> apparently just returns a 301 to <https://docs.python.org/3/library/subprocess.html#subprocess.run>

which is very very funny

someone registered that domain just to do that? lol

I wish I had that kinda cash lmao

same for https://systemd.network/

LOL the network blocked it as 'malware'

Wow, I just realized why I love OpenRC / S6 even more 😁 There is literally a book, just for the network module

systemd is some of the most over engineered crap ever lol

https://github.com/w3c/png/issues/39

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

<#805176455658733570> but <https://github.com/w3c/png/issues/426#issuecomment-2053907919> > We probably also need to have a discussion about PNG updates vs. PNG2 (better name suggestions welcome). Anything that would significantly break existing PNGs should perhaps instead go into PNG2. The trade off is "old stuff broke" vs. "new adoption is extremely hard, so it was in vain." If the goal is to improve the world('s data situation), both make a strong case. > > The challenge of a PNG2 is that it wouldn't just be competing with the original PNG format, but also all the subsequent lossless formats. Lossless WebP has 14 different filters and the ability to de-correlate channels, a number of formats use CABAC to get better entropy coding, etc. > > I think that's okay. There probably should be multiple solutions. > Even if the initial release of the hypothetical PNG2 is just a big catch-up and not yet fully competitive, I think it would be a good thing to do.

I left a comment over a month ago when it was discussed here previously

yeah, it's already been discussed and it's <#805176455658733570>, but it just came back again as a new discussion on hn and on-topic I meant that this is basically no different than introducing a new format, even if based on an existing one and why do we need a new format that is still worse than many other more modern alternatives and especially jxl? and is it really that less new code is so important that nothing else matters?

why did the brotli comment get downvoted so much

it would have seemed worth considering, if the overall idea had been

likewise for the content-encoding

less hyped, less well-known, not many people have tested it and know how effective it is, most people even think that it is only good for text compression and bad for everything else

Chicken and the egg, but the encoder has been hardly improved so there's even less reason to use it, which then means no one wants to improve the encoder

brotli? there have been massive improvements, but the stable version has not been released yet the last release was a long time ago `brotli encodes 26% faster (lz compression tricks)` <https://encode.su/threads/4408-brotli-encodes-26-faster-(lz-compression-tricks)>

Last release was 2020. If people can't see the improvements, they practically don't exist

a lot of people also seem to just assume (without testing) that because compression is slow (by default), decompression must also be

someone on reddit seemed to believe that it decompressed slower than LZMA 🥴

Ironic thing is, ZSTD is the same if you use the higher settings. It's just because brotli defaults to better compression

This is a great demo I found where I can test arbitrary files on any device with a browser. Tested compressing DNGs on my phone in the past https://bench.nickb.dev/

It does show Brotli as twice as slow as ZSTD there though...

that it is, but it’s hardly “slow”, and certainly not as much as LZMA

nothing is slow when we compare to `cjxl -e 11` <:KekDog:805390049033191445>

nothing is slow when we compare to PAQ...

https://github.com/web-platform-dx/developer-signals/issues/215

proposal could use a signal boost and any relevant feedback about usefulness

is that a 9x9 pixel image that is zoomed up?

Yes, it applied to larger versions of the same pattern too, but the 9x9 stopped my eyes from hurting due to moiré. It's an easy way to replicate the desaturation found in natural images too

Well that's interesting... If I encode it as a JXL with `--disable_perceptual_optimizations` the yellow remains saturated but the B channel bleeds into the black pixels too

Default lossy for comparison

interesting, one would almost assume the opposite to happen by the flag name alone

I realised it's because it disables XYB, eliminating the narrow range of the B channel that causes the desaturation

https://jeremylee.sh/bins/ the only one on the internet