JPEG XL

Grey likely means the viewer doesn't support color management, or not HDR JXLs

Cjxl used to have both EXR input and internal paletting to the original bit depth. I think the latter still works for half float input

Nah

I think HEIC is actually kinda heavy

compared to lossy, visually-transparent JXL

I think it's worth converting to JXL. 16-bit EXR is just an intermediate format before converting to lossy JXL in the end.

And lossy JXL is always 32f internally anyway, bitdepth is just a suggestion

You think you think but have you really tried?

don't think so, I am using a Mac, which is supposed to have native support, but even that I tried opening the image on Firefox, Chrome (with flags turned on), Safari, and the Photos app, also tried opening it on my phone. It looks grey on all of those.

Hmm, maybe the color space isn't being copied over. Could you upload an example or run `jxlinfo -v -v` on it?

I remember I made a modification that outputs PFM but I can't find the code anywhere

does anyone here know what colourspace would be correct to output? Display P3 Linear?

cause then libjxl can take that as input

metadata is an issue however

Well I tried but I don't think I properly converted the HEIC into a normal HDR file.

since that's almost impossible (thanks apple)

Maybe wait until we can directly convert HEIC to JXL on Preview or Apple ditches HEIC

I got this working ```python import cv2 from apple_hdr_heic import load_as_bt2020_linear, quantize_bt2020_to_bt2100_pq input_image = "input.heic" output_image = "output.ppm" bt2020_linear = load_as_bt2020_linear(input_image) bt2020_pq = quantize_bt2020_to_bt2100_pq(bt2020_linear) cv2.imwrite(output_image,bt2020_pq[:,:,::-1]) ``` Then: ``` cjxl output.ppm output.jxl -x color_space=Rec2100PQ ```

The problem is Finder only activates HDR mode if using HLG / PQ transfer, I couldn't get it to register a linear JXL as HDR

it loads EXR images as HDR though -_-

still not 100% exact, but DIFFERENT PARTS OF APPLE'S OWN OS DISPLAYS IT SLIGHTLY DIFFERENTLY

AHHHHH

Can't you decode heic as 16 bit PQ?

That’s what the code above is doing

Wait I should probably use display p3 instead of rec2100

Also what is a rendering intent? Perceptual vs relative vs all the other options

What does it actually do?

Yeah apple uses apple p3 color primaries

Uh... My guess is: Don't even ask lol

rendering intent affects how out-of-gamut colors are mapped

I think theoretically it's to decide if you want to clip colors that are out of bounds or if you want to scale them relative to the available space.

so.. uh.. which do i use

you'll want relative colorimetric in most cases

no idea why there are so many different, vague-sounding choices for intent, with completely unhelpful descriptions and names

iiuc colorimetric intents (relative, absolute) has defined behavior, and behavior of perceptual and saturate is vendor-specific

``` import cv2 from apple_hdr_heic import load_as_displayp3_linear, quantize_bt2020_to_bt2100_pq input_image = "input.heic" output_image = "output.ppm" p3_linear = load_as_displayp3_linear(input_image) p3_pq = quantize_bt2020_to_bt2100_pq(p3_linear) cv2.imwrite(output_image,p3_pq[:,:,::-1]) ``` `cjxl output.ppm output.jxl -x color_space=RGB_D65_DCI_Rel_PeQ`

here's the Apple docs btw https://developer.apple.com/documentation/appkit/applying-apple-hdr-effect-to-your-photos

Isn't perceptual "choose what's best for me" and saturation is "lulz" and absolute is "clip" and relative is the same as "perceptual?"

So confusing and bonkers

The one that I select is "idk just make it look good"

not to be confused with "just make it *work*"

not sure it's accurate, but I refer to this when I'm confused about rendering intents https://www.colourphil.co.uk/rendering_intents.shtml

perceptual is supposed to do gamut mapping with some roll-off, but in practice is often equivalent to relative (clip) because the necessary tables are absent from ICC profiles

absolute is like relative but without chromatic adaptation

so the result will likely look warmer or cooler (when adapted to the white point of the destination profile)

https://www.cambridgeincolour.com/tutorials/color-space-conversion.htm

https://www.argyllcms.com/doc/iccgamutmapping.html

“relative” is usually a decent default if you don’t have specific reasons to use something else

ICC perceptual mapping actually often just means no mapping at all, because in a time when there were there were barely any wide color gamuts used, all the common gamuts were rather similar.

So the reasoning was that just shifting everything into the new gamut was likely to the most appealing, since it avoided things like gamut clipping artifacts or slight desaturation without shfting the colors too much, which probably were rarely accurate back then anyway.

This article explains why relative colorimetric or perceptual is the better intent to choose. It also has some nice visual diagrams showing what happens to out of gamut color. https://www.permajet.com/blog/rendering-intents-explained/?srsltid=AfmBOoqJHV4LpytkE4Maz4oBsQ7XmM1EkHiuFS-pWapDDMd1x-zEOQSI

slightly odd choice to choose a greyscale photo as an example for which to use perceptual

jxl stores a low-resolution version of the image and reconstructs the original size image using residuals and prediction... but the math is really simple and doesn't take into account gamma scale vs linear scale when resizing and predicting residuals, so I'm wondering, doesn't that waste some efficiency having to encode the error between the actual linear-scale values and the predicted gamma-scale values?

My guess is this was already thought of and considered not to significantly inflate the cost of the high frequency residual data

But I'm kind of skeptical, because it seems like some prediction is being left on the table. Like if you need to predict the pixels in between a light and dark region, you would get less error and better prediction by going halfway between them on a linear light scale rather than the gamma scale.

Is it just not enough to matter?

You're specifically thinking of Modular Squeeze encoding

Well DCT does the same thing too with the DC/LF image and gamma=3

Yes, because the DC/LF is a squeeze encoded modular substream

Though, you're making me wonder if our progressive lossless work could also improve the DC frame...

And since it's using really simple and naive gamma scaling functions it introduces a lot of avoidable errors that you end up paying for in the residuals.

I don't know how significant those errors are but it's more information than necessary in order to correct the mistakes from the incorrect downscaling.

Come to think of it, what if the only the encoder were to use linear-light downscaling when creating the DC image?

Without any changes to the decoder

Maybe that could increase density by creating less residual energy?

Would that cause a problem?

Even without any decoder changes, that would be a slight improvement right?

Since the DC would be more accurate to start with, less correcting after

Does lossy even retain those differences? This may be a minor quality improvement instead of density

Well when it comes to lossy, density and quality improvements are the same thing at the end of the day

Either way, less residual energy is good for the quantizer right?

Might be worth trying if lossy squeeze modular works better in a "linear XYB" space

I mean I don't see why it wouldn't equally apply to the downscaled DC images in DCT mode either. Really any place where downscaling happens, wouldn't it save some bits to downscale it in whichever way will result in the smallest residuals possible?

That should be the goal always yeah?

It's free density sitting on the table

Just during the downsampling step

I imagine the difference could be very small depending on the image. But maybe a resampling algorithm with linear light and maybe even a little bit of aliasing too! Whatever will result in the smallest possible residuals.

There's already 3 different downsampling methods in libjxl, with the most expensive and most accurate being used currently

Well the most accurate is not necessarily the one that creates the smallest residuals? It's possible some aliasing might help?

Well it's also multiple times slower, which is why I aim to disable it unless at effort 11

I'm not sure if this is the correct place to ask this but

Can you guys upvote this bug report in feedback Hub

https://aka.ms/AAvf2lz

Some of jxl images aren't showing thumbnails and shown as corrupted in windows photos app

For example

extension specific it seems, had that issue before for limited number of images

Those images work on my iPhone

it wouldn't be too hard, cause it's just D4, i.e. the dihedral group. but I think it may be easier to convert each one to a 2x2 transform matrix, multiply the matrices, and convert back. I already have utility functions orientation_to_matrix and matrix_to_orientation

been busy so haven't had time to work on this in the last few weeks tho

Yeah third party image viewers also works

Point was please upvote 😭 🤌

So they can fix that.

Yeah, so it works with Apple's decoder but not Microsoft I guess?

It seems to be a resolution limit in the Microsoft extension https://discord.com/channels/794206087879852103/803574970180829194/1346059712273186909

well thats an odd limitation

100MP decodes fine. thumbnailing and read mostly takes time, but some specific outputs from the same (jpg) source dont preview or read

Could someone try with and without gaborish?

What's the resolution limit

cjpegli is producing some weird color shifts, though I suppose I should expect that at -d 2 <:SadOrange:806131742636507177>

IIRC it still defaults to 4:2:0 too doesn't it?

IDK, but that's not the issue

there's major banding and chroma shift

it's a lot better at `-d 1` but still somewhat noticeable

What about disabling adaptive quant?

I will test, give me a min

doesn't help

Send image pls 🙏

It probably happens with jxl too? They have similar problems with color.

at `-d 2` in cjpegli you get this red, arch-shaped banding on the left

cjxl is much better at the same distance

"Better" meaning it has the same problem but at d=3 for example?

meaning it's not completely eliminated but it's much less noticeable; I haven't tried d 3 in cjxl, but I can RN

even cjxl at d3 is not as bad as cjpegli at d2

there's just this really sharp cutoff on jpg where you have these reddish blocks and these not-so-reddish blocks

cjxl at d3 has a similarish problem with a faint green/yellow color, but it's not as noticeable as the red in jpg

To be fair d2 on jpegli is very severe compression, all distance values are more severe compared to cjxl values

oh, that's intentional?

I don't know if it's intentional. It's my experience.

ah

I've found there's just huuuuge bias with brightness when it comes to distance

bright images can get away with much higher distances than dark ones

In jxl too?

yes, but IIRC it's less so... I've not tested a recent libjxl in lossy enough to know

q100 and d0 aren't lossless for cjpegli

I always forget lossless JPG exists so I really don't care <:CatSmile:805382488293244929>

I'm glad you notice this too. Hopefully the extreme prejudice against dark shaded image regions can be recognized as a critical issue and fixed like one

Along with the extremely weird color changing ringing artifacts

yeah, I suspect a big part of the problem is the people judging the quality aren't doing so with a high contrast monitor with deep blacks in a dark room

And desaturation that's noticeable even when sitting a good distance away from the monitor

I've noticed that mostly on things with lots of chroma detail (especially images with noisy chroma)

it used to just color shift a lot but I think it's desaturating more than that now

They aren't looking at dark images like https://afontenot.github.io/image-formats-comparison/#pont-de-quebec&JPEGXL=m&AV1=m

Try `--xyb`, it doesn't has the chroma shift issues you describe

Desaturation is a major problem with libjxl compared to other codec libraries. Even mozjpeg doesn't desaturate like libjxl does

On d=1 even

But especially d=2

> Last updated: April 2024. so not latest libjxl <:FeelsSadMan:808221433243107338>

I doubt significant perceptual changes happened between v0.10 and v0.11

if I can find a viewer that will open them properly <:kekw:808717074305122316>

well xyb is better but still has some rainbowing

v0.8 was the best lossy encoder we had, but still slightly desaturates yellows

solution: just crank up the saturation before encoding <:kkomrade:896822813414011002>

Can you give an example where the desaturation is bad? It could be just a matter of doing less rounding towards zero in the quantization of X and B...

There was a furry image here that illustrated the yellow desturation issue really well

Sure, I mentioned this before, but pretty much any image with vibrant yellows and orange. Or gold, bronze, etc. "Abandoned Factory" flowers "Ohashi" the vibrant greenish-yellow paint "Japan Expo" the green dress and to a lesser extent the hair too

I made an issue with a photographic example here: https://github.com/libjxl/libjxl/issues/3616

https://discord.com/channels/794206087879852103/804324493420920833/1245897728047714366

Thanks

I think the best and most obvious example of desaturation is with the flowers in "Abandoned factory" image which I mentioned to Jyrki way back when

Thanks, this is a really good explanation

Sometimes when you notice something subtly weird about an image and then come back to it later, it's hard to see the same thing again. But the saturation issue is pretty consistently bad versus other codecs, even mozjpeg preserves saturation better

Does it also occur in larger smooth saturated color regions, or only in smaller details like those yellow leaves?

If it's mostly yellows getting desaturated in non-smooth regions, it suggests we need to allocate relatively more bits to the AC of the B component.

That reminded me, maybe we should make a new build reverting the quality regression, just to play around with for fun https://discord.com/channels/794206087879852103/1278292301038227489/1309307664387276820

Yes, it appears in large regions that are obvious even viewed from a distance.

Like the green dress in Japan Expo

A while back I did a comparison against 0.8 too. Still desaturated, but less than current https://discord.com/channels/794206087879852103/794206170445119489/1351548537980321852

I'm pretty sure it unfortunately affects all colors. Quantization is just supposed to reduce accuracy, not universally reduce saturation lower across the entire image

Reduced accuracy and quantization noise should be evenly spread and noise-shaped, not have a perceivable bias in only one direction

It's like the colors are being scaled down rather than rounded to a nearby point. I would've thought the values of bright yellow and dim yellow would compress about the same

Back to 0 days without mentioning noise shaped artifacts

looks to me like the dress is actually yellow-green (or at least reflecting some yellow light in addition to the green), and that yellow gets obliterated by libjxl

the green actually gets *more* saturated in some areas, possibly just because the yellowish tint is lost

that's really weird, but not too different from some of the color shifting I've seen it do

oh nvm, I had the original and JXL backwards; it's JXL adding in the yellow tint, and the dress is originally green

I'm using "noise" in a general sense here, "quantization noise" is synonymous with "quant error"

Either way there's no reason for a reduction in quantization accuracy to uniformly decrease saturation like that

For the same bitrate it could just as easily increase saturation, or most preferably, spread out the error so it averages out, and try to mask it.

That's usually called rate-distortion optimization or RDO

A big buzzword here

Or anywhere there's talk about image/video codecs

Yeah, that's what I tried to say

You said it well too

It seems like it could be a very basic mistake that's easy to patch. Finding the best error-diffusion algorithm is not easy, but fixing a simple rounding mistake?

Seems like low hanging fruit

Hello everyone, can I ask for help in this channel?

yes

I have an unusual jxl file (texture from a game), according to the script where it is used this texture contains several images inside, but none of the decoders can convert it. I assume that it has an unusual structure (hex structure definitely indicates that it is jxl) any suggestions how to decode it?

if you can't decode it then it's likely not a jxl

whatever makes it appear like a jxl could be coincidence

consider this case which reads similarly without more context https://discord.com/channels/794206087879852103/804324493420920833/1335434938576670770

was image generated by Special K ?

I would be very cautious to respond to a user with such nickname

Svt - Jpeg encoder

What you think <@532010383041363969>

Summon anyone with banhammer

https://www.hdblog.it/green/articoli/n615342/dubbi-phase-out-carbone-italia/

You don't know how many effort I spend up making this encoder so please shut

This is <#794206170445119489>, at least put it into <#805176455658733570>

I've run an antivirus

Is there a demo website somewhere doing wasm jxl decoding?

Here: https://giannirosato.com/blog/post/corpus-lossy/

It's a bit heavy, maybe it could benefit from our new faster decoding improvements

Doesn't seem to work for me

Me neither, there's no WASM or js being downloaded

oops

I shared the wrong page, Gianni said he forgot which of his pages uses the WASM jxl decoder

https://discord.com/channels/794206087879852103/794206170445119489/1355704370787778580

I copied an antispam cookie in cloudinary.com

Maybe this one? https://giannirosato.com/blog/post/jpegli/

1605 ms by default vs 531 ms with FD4 for a lossless 1080p image. 10.6 bpp to 12 bpp <https://jxl-oxide.tirr.dev/demo/index.html>

Bear in mind, that page is a lossy corpus, our changes are only to lossless

Lossy is even faster to decode even compared to our changes

Yeah. The new Lossless FD2 (very) roughly matches default VarDCT

> jxl-oxide-wasm 0.10.0 yeah I need to update that...

I had a hunch, so I dug up the old Oxide browser extension https://discord.com/channels/794206087879852103/822105409312653333/1333582170790428724... Yep, LQIP is working beautifully

Huh.. I'd never tried progressively loading Delta Pallete before. Looks cool

The same 'image' in Waterfox.... Yeah....

waterfox doesn't support progressive decode

to do so requires you to call specific API calls to fill a buffer with the partial data

unless you do that, you'll just get `JXL_DECODER_NEED_MORE_INPUT`

It does, but libjxl disables LQIP so it requires a higher percentage

oh, I see, that must be new then

nvm

it wasn't back when I tried it

Added a few months ago IIRC

ye, it's been a year for me

probably

I currentlly use stock Firefox, hopefully Oxide will be integrated into it at some point

Another interesting note, Oxide uses NN upsampling for the progressive scans, while libjxl (presumably) uses the non-seperable upsampling, or something that smooths. So you end up with progressive scans almost immediately, but possibly looking worse than the slower libjxl ones

bilinear is probably a good compromise

over nearest neighbor

the non-separable is very slow

he removed it because it was too harsh on wasm

https://giannirosato.com/blog/post/nvenc-v-qsv/

this was the page

<@794205442175402004> here's the actual page containing the WASM decoder

Is there any chance jxl-rs cold be no_std? From a quick glance a lot of std usage is in `core`

no-std would be really nice, ~~imagine using jxl-rs as a shader~~

Yes

Extremely yes

As a side effect the codec library would be much more secure, without access to filesystem or memory allocation :)

So much yes

what is `no-std`?

basically just allows compiling without std which is useful for compiling to targets with no real stdlib like microcontrollers and other weird targets (like spirv shaders)

oh, it's without the standard lib?

yup

oh so it's like `gcc -nolibc`

yeah, basically a crate will define no_std support and make it so that other projects can incorporate it, microcontrols are basically the only real consumer for stuff like this, but rust-gpu can compile no-std code into spirv shaders. it would perform terribly im sure, but you could in theory make a rust decoder for anything, make it nostd, and compile it to a spirv shader

I'd imagine a spirv shader would be terrible for most things, but useful for, e.g. RGB to XYB

since GPUs eat that kind of thing alive

sRGB to XYB is one of the biggest bottlenecks in libhydrium

and I'm considering figuring out a 3Dlut method to make it faster

but I'm really not an expert on it. I'd have to ask haasn

sRGB to XYB was pretty decent as a shader, I did experiment a bit getting the rust crate ported over to rust-gpu and the conversions themselves were pretty fast, but well, you had to set up everything else yourself so it was not great for me lol

if you can make it in a way that auto vectorization actually works then that would probably be ideal [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&name=av1_dogelol)

could things like calculating metric scores also be improved by shaders?

things like lz77 backref calculation would probably not do particularly well as shaders

yes. I was working on a ssimulacra2 shader, but the ssimu2 blur function really didnt map out well, and didnt feel like playing wack-a-mole trying to figure out how to write my own blur shader from scratch that gets close to it

Copying buffers between system ram and vram would slow things down unless you could avoid that

I think the main benefit would be no memory allocations or access to the operating system

That's really great for a codec

vszip and vship chose the route of using a standard gaussian blur

instead of the recursive one they use (recursive gaussian is atrocious for gpus)

you are creating a gpu ssimu2? 👀

there is already an implem of butteraugli and ssimulacra2 on gpu

in HIP

(and Cuda)

someone was also able to turn hip into spir-V/opencl using CHIP-STAR

(side note, SSIMU2 is not bottlenecked by the GPU here, using gpu decoding and get the frame directly on the gpu would probably allow me to get around 500 fps with my current implem)

RTX 4080 super is able to get 150 fps butteraugli 😵‍💫

the gaussian blur being non recursive can sometime create a wide gap with jxl implem but I am not sure that it is a regression to MOS. I noticed the opposite when the difference was really large for butteraugli the difference in gaussian blur doesnt create a big difference in result

I was, RSI typing hurts too much so I do as little as possible now

this might be relevant: https://youtu.be/8SkdfdXWYaI

this is really neat

ive just been using LLMs lol

I have heard some people claim that their RSI improved after switching to US Dvorak keyboard layout

But you have to re-learn and forget your existing keyboard layout memory. It's much easier to learn though compared to, say, QWERTY.

RSI is not real you just have to move every 30 seconds

tru

“have you tried yoga?” (https://www.painscience.com/articles/tyranny-of-yoga.php)

You get used quite fast! I use it all the time just because it allows me to stop watching the keyboard, since the visual layout is still QWERTY, it has been a shorter journey than I expected.

actually yeah, but a lot of the RSI damage I have is compounded from the factory work and boxing I did in the past, it does genuinely help though, so does the standard excercises like finger push ups, but it's easy to over do them

Yeah, it's a lot faster to learn than it was to learn QWERTY. If you already have existing memory of a different layout you end up forgetting the old layout at first. But your memory of the old layout can eventually be restored later on, if you choose. It's even possible to have both layouts memorized at the same time, but that's a lot harder.

You need to stop doing the thing that hurts. That's why there's an "R" there for "repetitive stress injury"

But yeah I have heard a lot or stories of people allegedly having improvement to their RSI after switching keyboard layout. In my own experience it actually felt really strange and weird for my fingers to hardly move at all compared to QWERTY. My fingers were used to moving more than twice as much, and it felt like the words were just appearing and typing themselves after I got into the cadence and rhythm of it, and my fingers felt like they were mostly holding still...

It was an odd sensation and took a while to get used to, since the finger movement is more evenly spread out across all fingers and mostly on the home row, rarely having to move at all...

It really just feels like you're holding your hands almost still while the words are just appearing and typing themselves.

I think there's a difference between "general mindfulness" and a specific physical or mental exercise.

We should be mindful and you should feel guilty if you don't enjoy being mindful because if you aren't mindful and living in the present moment then you are literally not present, and might as well be somewhere else, asleep or not alive.

Out to lunch

Guilt is meant to make us correct our behavior so we can live like who we want to be. Being half alive and lacking mindfulness and self awareness and thoughtfulness is a very healthy thing to feel guilty of!

Everyone with a healthy conscience feels guilty of that exact thing because we can ALWAYS be MORE mindfully conscious.

the "mentality stuff" behind yoga can get a bit... cultish sometimes,. but the physical benefits of yoga are undeniable

A lot of people also religiously push certain specific physical and mental exercises that work for them but not for everyone

You have to discover what works for you. Everyone is slightly different.

I contacted this guy and he still hasn't found a solution <:PepeSad:815718285877444619>

it would be much easier if i had knowledge in reverse engineering ...

Switching layout causes them to move -> less RSI 🤯

anything relating to the image processing itself is very fast on a shader but stuff like entropy coding is pretty useless to do on a gpu

there's actually no evidence to suggest that dvorak is faster than qwerty for typical typists, once you control for the population type

a lot of dvorak fans will like to say "qwerty was intentionally designed to make you slow so typewriter keys wouldn't get stuck" but there's also no evidence to suggest this at all

True. There's no evidence that it helps you type faster.

the actual origin of qwerty isn't even fully known, but what is known is that some of the earlier typewriter designs used it because alternating left-vs-right hand caused keys to get stuck less

You can definitely reach the same speeds with qwerty.

but that has an effect of making you faster, not slower

well, assuming you can actually fit everything you need in the gpu, if you are performing a lot of copies on large images... it's rough...

memory management is pain

ye, but stuff like, sRGB -> XYB is the sort of operation that gpus eat alive

yee

It was designed by Sholes. It was based off an alphabetical keyboard layout with some common keys moved around to make it slightly better. It is only slightly better than an "ABCDEF" layout.

I really like rust-gpu, or really any language that lets you write shader and cpu code at the same time for stuff like this

the Remmington was the first QWERTY typewriter and Sholes filed a patent for it but there's not a ton of historical evidence that sholes unilaterally invented it

we have the patent filed with the US Patent Office in the 1860s

but minimal sources other than that one

Sholes tried to incrementally improve it by moving more keys around but Remington said "too late, bad time to change it when it's already getting so successful"

Therefore we are still using this alphabetical-based layout that's only slightly better than ABCDEF

It was a very early prototype basically

With still a lot of alphabetical sequences left like DFGHJKL

there's a lot of misconceptions about QWERTY's origins tho

Yep, true.

these are largely in part because of a 1980 article a journal of informaion processing

which made a few incorrect assertions, like that the layout was designed to slow people down

Sholes was trying to design a good layout when he made QWERTY but he just was not allowed to actually finish.

here's a really good 2009 paper about it

https://repository.kulib.kyoto-u.ac.jp/dspace/bitstream/2433/139379/1/42_161.pdf

it includes gems like how scientific american reported that you could type from 60 to 80 wpm on it

most Americans today, even those who touch-type, don't type that quickly on regular keyboards

People on both sides say a lot of questionable things :)

It won't make you type faster but it's certainly much much faster to learn. You'll be touch typing much sooner than the time it takes to learn the Sholes layout QWERTY

The US Navy trial by Earle Strong definitely had multiple major problems too.

And people on both sides reach strange conclusions both pro and contra.

It's absolutely faster to learn, it absolutely eliminates most of the required hand movement compared to QWERTY, and, surprisingly, you absolutely can type just as fast with QWERTY. Those are the 3 major takeaways.

my opinion on QWERTY is that "it works" and trying to do anything except it ends up just putting you in an uphill battle

it's like deciding that using miles is stupid while living in the US so you will choose to only use kilometers. you can do that. but everything around you will still be in miles. so you still have to know it

since people do not exclusively use their own keyboards

Some would argue Dvorak just works for them too. And yeah, using miles and ounces and whatnot is pretty infuriating :)

yea, but the problem is that you can't just *decide* to not use them when your recipe is in ounces

or when the sign is in miles

like, you have to know how to work with them *anyway*

Personally, I learned QWERTY first while in school and it took a very very long time before I stopped looking at the keyboard keys.

I didn't learn any other layout until recently.

like even if dvorak is easier to learn or whatever you still *have* to learn qwerty if you work in any place where you do not own the hardware. which is most people

institutions have restrictions on those sorts of things because they have help desk that has to be able to type on your keyboard if something breaks

so they won't let you use anything else in your cubicle

Usually you can switch layouts with "logo+space" key combo.

I think it's good if people decide what they think works for them, depending on what their priorities are. Some people are more or less worried about theoretical or real problems with going against the status quo.

I don't want to pressure people either way.

But I am biased obviously and I think it's cool when people try new things ;)

Like JPEG XL for example

<:JXL:805850130203934781>

I personally decided to try learning a new keyboard layout just to test my own elasticity.

Not because of unrealistic expectations

QWERTY was designed to have the letters of the word TYPEWRITER all on the top row so salesmen could more easily find those keys when demoing a typewriter by typing the word "typewriter".

I don't know what the other design criteria were but avoiding stuck hammers was one of them iirc

this is often cited, but there's no primary source evidence to suggest this is the case. the brand name had been decided before the position of the keys was finalized, and the marketing demonstrations were typically done by having someone typing out a live feed like a telegraph or a speaker

Maybe it's just a coincidence then that those letters are all on the top row

as far as I'm aware, yea

considering the brand name was Sholes & Glidden Type-Writer

with a hyphen

see the patent

there was a hyphen but it was Shift+6

(in the remmington no. 2 model)

so it wouldn't have been possible to type Type-Writer on the first model, and wouldn't have been only the first row on the second

Perhaps <#806898911091753051>

I forget the name of the friend of Sholes who allegedly suggested to Sholes to put those keys in the top row.

Might have been Glidden

Might have been hearsay

Wikipedia says something about it too, with attribution to > Gould, S.J., The Panda's Thumb of Technology. *Bully for Brontosaurus: Reflections in Natural History.* New York: W.W. Norton & Company, 1991.

hello guys

https://jxl-art.surma.technology/?zcode=7Vy9btwwDN7vKdSpQNAilm2dz0v3Dp36BEGRAhmKAm2G9O0bJNadf0SRpn4syc50J9onmfz4kaLo3N%2BJr88f%2F4oH8evxk%2Fj28Ofp9wdxd386Pf0UP8QXUZ2EGD7K149vX%2F69flHy%2Fet1oDt3w4AQn8X3x2dRq%2Fo6Mlx0bvrr0O3OqhkN3oYbNRl%2BE7xMpr79LWec3VQrtRBdhc2lMQj1r1ZGmb5V9kaxbUnThV064AL7%2FNgUkMyixEE0tiRtruHGqXWpmtAL6pRdUeeqYymCokpIujF4qpSgo124kxEQlZlBUnHE5NSmL1AyCFJXOYM6e%2FMGHQRnnKVdZMFUG5Cu%2Ft2qcaGYpbevNRygdZT1SctTbeNq9BydBQ904GNbxAllDCh49QWNCs0ruAdw044sY9wK5GiSXPjoAagDULvaABFj8QGdEPn2QEPjRxiGpgsfBtu2M7FY2%2FV7whEzqwOFLjgaxHPDrEx5IKWUQiHkAOa%2FSuIhn08YOJUn2GgikWpP6RBnI%2BKzJuh%2FfREQiWRMSwh52PWWl04lW9ogg5dpxq3Aqy%2Fo%2BlDPlZoD6ERylsbqYSUPZ4l3%2FJOZt3hCOlfvZXG9Qw5XHWan5K3LMk2GaCCzGfOsqNzTbEdcH1wUBX2wdCmZjtDbemR7idzWM57RX2GydapMmta0sqwtJebg5kkgmZtHmOcidfZAuvDHhbC2EWtaxJsjSNZpIShQgw8LWESqhRVgtVAQTBAjZOuc%2BrUVExbOwMyElTIEjxuhkBtHuISxjpWUP1aK22i1DdrIaSHu%2BNxNCY2a8G4r3PSxSZdck2SzajznRZMgWP02eU7MTT6X8sB0uEOy09KAMSR08F8BoUANYAeycLrBqB6NRgSul5G5PjC%2B97Rvp%2BYsMYCMGNRD9cA5tJvkhWQtSewV02zRS92zcBqyVomlqreof6A5KqCZUpiVnmewmdOZWfmpYAoAkrUnAAXq2Es%2Ff2VtI73W%2B4OsMQY4sfQSL%2B8SymfeEF54wYwPI49QZptzMyiTs0%2BXZ0vQH%2BJ28%2BXvO%2BGPffPzHX%2BwZ%2Bu%2FsDCgjiPekLYP1N63DSTo7KYSYLfEmlpc0X2wUiQIwtKlZDwy6%2FFbdPi9X9vPXpwda8rY2gc09oHGm01DgK4VuEMfozyfVlcxgZUQzwMG1Tb21vMe6sXsa5q6LEgHZ7CC3PLUCLmh1GZVqN1UsHQzYECmjYoMoCsvHlwQRrQ%2Fq80Gvu2NxC87%2BNDUzH67XQ9OaEuVRrLBhQMPoL05bE9fwSM1sgOiQMPYRwd00WUCITTRonms9U0QKBCSuARuoaDZNRozovU%2BF%2B6L4X9YwsF8WyZVakWPenywEuZXrCQvDLUHC7pEaAB9bgdenPFComEkQGA0jD12BmgtdqtKShCC4tJqLcd9sltAXUpzTg822zgtes8MnWfGvjOg66wo50C5kfPKdqCNvTXJ6%2BtTMaxHDOcsYnOiPV5KtSEqzEtlVOfmZaPSUj%2FOP27wEyN9rywo2pD8DC0uKo7LFlkfDBqfPGVvyoVgoyGTmr0xnyYRaBtbt4DGrX25QL97D%2FACYJaas6ZmJLLu5kjP2bJAh1Um5qYes6w%2FpCqs3cAJq3sjkZCoAkSz4evX%2Fw%3D%3D Who made this ? i wanna contact him

it was made by someone in 2021 who is no longer in this server. I am curious as to what reason(s) you have for wanting to contact the creator.

I tried to study this code, and the complexity of its execution drove me crazy. I'd like to do something like this

It’s basically just a bunch of row and column checks

I am pretty sure a simple commandline `cjxl -d 0` will compress better thqn that

Um, is that actually less bytes than just... a normal bitmap?

-d 0 -e 10 -g 3 -I 0 -P 0

https://embed.moe/https://cdn.discordapp.com/attachments/794206170445119489/1363454430229561434/mario.jxl?ex=68061763&is=6804c5e3&hm=44ebfa5bb4d718e9ee2bc9e4ddfe01ad5e3df9eff23e782aef6426d2afb93574&

Squeeze would work well, if it were limited to 32x32 as the smallest step

https://embed.moe/https://cdn.discordapp.com/attachments/794206170445119489/1363462475327995924/MarioButSmaller.jxl?ex=68061ee2&is=6804cd62&hm=f72ef24fbf5a130479104a318a64d7c642ee351122a26f5b98674d0ee946f316&

I assume the 7 bytes are from the recent ANS commits, since I ran the same command but it works at e9 too

why does my funky command produce a bigger file <:PepeHands:808829977608323112> ```cjxl -d 0 -e 11 --allow_expert_options --resampling=8 --already_downsampled --upsampling_mode=0 new.png new.jxl JPEG XL encoder v0.11.1 794a5dcf [AVX2,SSE4,SSE2] Encoding [Modular, lossless, effort: 11] Compressed to 586 bytes (0.286 bpp)```

Yeah I tried that too. The upsampling weights for making it NN is too much overhead

that's weird I really thought NN was pretty straightforward doesn't it just store the multiplier (8 here) and... that's all ???

Eventually I'll try encoding it with a custom 32 step squeeze transform, to return it to 1:1 pixel scale internally

it's custom weights in this case

The default is the fancy non-seperable upsampling in the decoder, so NN has to signal data to reverse that

[⠀](https://cdn.discordapp.com/emojis/902695649198374962.webp?size=48&name=chad%7E1)

`cjxl -d 0 -e 11 --allow_expert_options` v0.11.1 794a5dcf [AVX2,SSE4,SSE2]

Huh, that's interesting. I wonder where that extra byte came from in main, and why my e11 was worse than e9

compressing the weights can yield a smaller file: ```927 art.png 587 art_jixel.jxl 196 art_jixel.jxl.paq8px208fix1 240 MarioButSmaller.jxl 254 MarioButSmaller.jxl.paq8px208fix1```

pointless

Interesting, the LZ77 build I used should've compressed the weights too

this is a 10k scan of imax film and i took the massive TIFF file (491 MB) and compressed it to a JXL (9 MB) the film grain at the individual pixel level is literally identical to the original how the hell is this possible? what does JXL do differently than JPEG that allows for this insane efficiency?

it seems impossible to me i dont see any blocky artifacting or anything

its literally perfect

Can you link the original?

TIFF (left) vs JXL (right)

i can try to find the download

https://pixeldrain.com/u/acuWaWDJ

Thank you

am i crazy?

the compression is not even detectable but its like 50x smaller

how is the tiff compressed?

not sure its one thing for the image to have a lot smooth regions and structured data, and that be compressed well but i dont understand how the film grain gets compressed this well because film grain is pretty much random

Haha

downloaded, two images have LZW comression, the rest are uncompressed tiff files, so they will be significantly massive. It is true that grain doesn't compress super well, but comparing from uncompressed to compressed will always be better. ofc jxl is also just really good at what it does, zero doubts about that. but even encoding the folder to png, it brings it from, 2.07gib to 829mib, encoding to jxl losslessly using d0 e4 is 747mib

I think they were using low distance lossy

Nah, it's legitimately really good at preserving grain textures. Aside from a few strange quality bugs involving chroma and shadows, it's a really groundbreaking, revolutionary DCT image encoder. It can do things AVIF can't do and it's even inspired a lot of improvements in avif.

It has the potential, in the future, with incremental improvements to jxl encoders, to eventually become the best at everything. Every category of image compression.

It's already really good at most things. But encoder improvements happen slow because libjxl is kind of old and hard to read code.

Libjxl is more like an unkept garden, it just needs some TLC, also quality improvements are not just a priority right now, mass adoption is the key focus at the moment.

And like half of the devs are working on the rust decoder.

Will there ever be a Rust encoder?

There has been talk of making a simple encoder to complement the decoder

well, there is a basic jxl encoder in zune image

Mass adoption is fueled by quality improvements that keep it competitive without any embarrassing gaffes that stand out in comparisons

You can't expect people to mass adopt something unless it makes the competition look unreasonably poor by comparison... not the other way around.

do you have any examples of weird chroma/shadow artifacts?

that would make me so happy because of how applicable it is

Yeah. Common to a lot of video encoders, libjxl unfairly crushes dark shadowy image features a lot worse than brighter ones. And it has a tendency to desaturate a lot of color images like deep yellows, orange, and green, as well as strange color distortion/ringing artifacts in some colorful photos... I can show some examples later if you must see.

These are simple and fixable defects in the current libjxl encoder.

dont worry, im just curious, its not a *must* also, does that mean the artifacts are not due to a design flaw in the jpeg xl spec or anything? its specifically an issue with this encoder?

Exactly. It's specifically with this specific encoder version. Aside from those specific defects, it's very impressive and state of the art, for a relatively simple DCT-based image compression algorithm.

The fact is, the current encoder is not even that sophisticated, it's pretty basic and does not use all of the available technologies possible in the decoder

It was designed to continuously improve far into the future with advancements in the encoder, without requiring changes in the decoder.

is libjxl heavily optimized or is it made simply as a proof of concept implementation? im assuming that libjxl is powering the JPEG XL support in GIMP, which on the slower settings can be *really* slow on larger, detailed images and i wonder how much faster that could get if we had dedicated jxl encoding hardware

or even just speed improvements to libjxl over time

It's close to a quick demo or initial proof of concept. A taste of what's possible.

thats good because it means theres lots of room to improve

There is... but as you just heard, quality improvements are low on the list of priorities. "Accelerating adoption" is the priority, whatever that means... To me that sounds contradictory. Quality improvements ARE ultimately what accelerates adoption.

People adopt something new because the alternatives are unacceptable or completely outclassed.

im already hyped about the current quality and i imagine that mainly performance improvements just need to happen for adoption to be easier

it will have to compete with AVIF tho

so i get what youre saying

Mozilla have stated that they will likely include JXL support for Firefox if a fast and full rust based decoder is made by Google devs. this is what I suspect people mean when they say the focus is adoption right now

People don't just make a major switch when it's "slightly better, in certain situations."

It's mostly the work of Luca though.

As far as I understand it.

I am looking forward to firefox including it too but if you think rationally about this, if firefox were to adopt it right now, firefox is a dead and irrelevant browser and doesn't have much impact on adoption.

what about safari? i thought apple said they were likely adding support as well?

Moritz has been working on it quite a bit as well and also there are other people as well

i know chromium is the biggest fish

dont get me wrong

Firefox getting on board will not ultimately drive adoption unless it helps pressure Chrome to follow, and there is no evidence of that

not caring about Firefox's adoption seems like a very bad idea especially since Safari/WebKit is onboard with support

It's already up and running on all Apple products across the board

thats awesome

Yep

Windows added support too

you think thats gonna be able to swap chrome or no?

In their official photo viewer app

No one knows since it ultimately seems to be up to the AVIF tech lead to decide what codecs are allowed in Chromium and he shocked the world by announcing that all the interest in jxl is just a figment of our collective imagination and he's pulling the plug.

With no one above him second guessing his decision as the lead subject matter expert and head of the "Chrome codec team" no one knows what it will take for his arbitrary decision to be reversed.

As the head of the team that brought us both AVIF and WebP, he says there's no justification for JXL. But he'll probably add AVIF2 when that's ready 😂

Flooding the web with his half baked formats forever and blocking any actual image codecs that weren't made by him

historically, chrome doesn't like being the odd one out, if it's just apple or just firefox supporting it, whatever, but when firefox comes along and supports it too it pressures them

That's just a theory. I hope you're right.

I can't remeber what the chromium team calls it but they do track what firefox and apple support

It's purely theoretical but I sure hope so

For sure they will be the very last...

well right now the biggest thing to do is pressure android into supporting it by reporting jxl as broken pictures to google images app reviews and your phones manufacturer help portal

if other teams/people at/on Google/Chromium see that all major browser engines besides Chromium support JXL then there will be at least some sort of pressure to implement support and the excuse can't be "only Apple randomly supports it"

funny thing is if JXL does end up getting implemented in all 3 major browser engines then it might make JXL look more enticing to web devs over AVIF just because of how much newer it is/seems by date of inclusion

<:JXL:805850130203934781>

On the bright side, when it does eventually become supported in Chromium, it looks like it really will be here for the long haul. It will be the new benchmark all other formats will have to measure up to.

There probably won't be a new image format standard for a long long time after that.

Just like how modern formats still struggle to compete with ancient crusty old JPEG '92

jpegli is great

I'm currently working on a major speedup to hydrium so I hope it's as faster as I think it is

that might make things easier

Since hydrium has such a small codebase it could be audited more easily

there's lots of reasons to adopt jxl over avif outside of purely compression quality, many companies have expressed their interest in the format, jxl is extremely flexible with virtually infinite resolution, bit depth and channel amount, progressive decoding, animation, and transparency support while quality at low bpp is situational, there's many other advantages to jxl so if people could adopt it rn, more people could help develop the quality at lower bpp and improve encoding tools for everyone unrelated but man is animation support for formats not called gif so inconsistent

Yes

just the fact *reversible* lossless transcode also transforms baseline jpegs into images with a minimum progressiveness is big

this is news to me, could you explain?

Old JPEG is compatible with JXL and can be converted losslessly. Always results in a progressive image

iinm jxls are progressive by design at all profile levels, and you can make them *more* progressive

Bit-identical btw

Huh, didnt know that jxl is progressive at all times (thought you had to specify when encoding), and i didnt know that lossless trancodes to jpeg were always progressive

that reversible lossless conversion that guarantees smaller filesize *and* is quasi-instant too is unique in the entire multimedia ecosystem

https://discord.com/channels/794206087879852103/1278292301038227489 <https://github.com/libjxl/libjxl/issues/3754> <https://github.com/libjxl/libjxl/issues/3616>

itd be a massive deal for providers of cloud services. even my ghetto desktop cpu crunches 15 typical photo-tier images per seconds with guaranteed smaller filesie on effort 7 and handles as high as 50/second on e1 while still shrinking the filesize from original

afaik jxl encoding is generally faster than avif, even when using svt, right?

converting anything to wepb/avif has the major issue that doing it losslessly will increase filesize severalfold, while doing it lossy will lose visual detail without even any guarantee of smaller filesize (you have to lower loss % enough until you get a smaller filesize, for *even more* loss of visual detail)

*Only AVIF, Lossless WebP isn't far off JXL right now

people shouldnt focus too much on minute performance and file fluectuations. libjxl's compressor in particular just sorts efforts according to typical ressource consuption cost, and over time this cost will fluctuate (techniques that were once slow and only attempted in e10 could become fast and added to all efforts for example)

prog. decoding is the most appealing part of jxl for me from the point of a regular user

or specific distributions of libjxl could be tuned for specific image types like greyscale comics, or to focus less stringently on preserving visual detail at all quality targets

<#1358733203619319858>

:>

Lossless mode is not progressive, most of the time

Lossless is group by group progressive by default, -p enables squeeze which allows under 1% of the file to be viewed

improvements are always appreciated, although its shocking how broken fd was

It was neglected in favor for the lossy mode of libjxl.

~~"Faster decoding" for lossless just lowering the effort level, now we actually have a functional flag~~

Group by group sequential. Nothing progressive about it.

Better than AVIF and the order can be controlled :P

Yep

It didn't just lower the effort level, it disabled compression entirely

What I meant to say was that if you wanted faster decoding the only way was using lower effort levels.

Right yeah, e1 and e2

e1 and e2 are truly amazing

At some point we might rework the effort settings predictors. Right now it only uses Weighted and Gradient until e10, but Weighted is 1/4 the speed of Gradient for decoding while only being about 2% better in most cases

All FD1 does in our fork is disable Weighted, and it's already a 2x increase

A little bit of both. libjxl is the original testgrounds for the format, with code dating back to the original PIK, FLIF and some WebP mixed in too. It was quite heavily multithreaded and fast codepaths added for common use cases, but it still has nearly a decade worth of technical debt at its core that makes deeper changes hard to implement