JPEG XL

Did it know with my cousin neomelodic song but I will not tell you what I did

Probably this encoder would be released and flessible

a little off topic, but I hate pages that are layed out like this, so much dead space

I have a bit of warm head stomach so I stay now 6 minutes to unlock some new JXXL images

https://lzip.nongnu.org/xz_inadequate.html

some legit but relatively minor criticisms, mixed with some "what?" claims.

honestly speaking lzip is not good either

in some sense, the core design decision of xz mirrors that of 7z, and xz is in fact significantly simpler than 7z

so the design has to be evaluated under the use cases imagined, but the document just "assumes" those use cases

I'm curious – why is lzip not good?

which ones are the “what” claims?

I have spent too much time to elaborate this on HN (haha), so: https://news.ycombinator.com/item?id=39873122

the "what" factor is mostly about corruption handling, which is a technically correct but very marginal criticism for compression formats.

for most of the jxl images, impact of a single bit filp is likely to be isolated within a pass group or an LF group afaik (when errors are ignored)

(for me, corruption resistance is something that is good to have for compression formats if can be added without much cost, but is never mandatory.)

errors will propagate further for progressive lossless (aka squeezed) images

Seems like a pretty sound article to me.

And comparing to bzip2 is pretty interesting

technically not incorrect, but too marginal to me.

and I felt that, after analyzing the lzip format, that incompleteness contributed to the design of lzip as well

there are many questionable statements as well, like this:

> A LZMA stream is a check sequence in itself, and large errors seem less probable to escape detection than small ones.

this is in general not true, and the truth of this statement will greatly depend on the specifics

I think this can be reasonably said for, for example, DEFLATE where its tree construction step is quite redundant and can be filtered out

but I can comfortably say so because I'm aware of a library that makes use of this fact: https://github.com/mxmlnkn/rapidgzip

the rapidgzip paper comes with a very detailed analysis of such "unlikely" DEFLATE trees, and successfully argues that speculative decompression at all possible start bit positions can be actually made work

finding such filterable feature from more modern formats would be much harder, because that naturally means more wasted information entropy

I don’t know about zstd generally being efficient enough; there are some cases where it seems to be significantly beaten by lzma

(or by brotli)

too bad brotli still lacks tar integration

(lz, xz and zstd have it)

Also probably grain synth has to be tried on jpeg xl

That's my first attempt best to just forgot it

I can't see anything when Im at home i download Libjxl ♎

what are you responding to?

I thought everyone had already stopped using xz due to it being slow

e.g. Arch <https://archlinux.org/news/now-using-zstandard-instead-of-xz-for-package-compression/>: > zstd and xz trade blows in their compression ratio. Recompressing all packages to zstd with our options yields a total ~0.8% increase in package size on all of our packages combined, but the decompression time for all packages saw a ~1300% speedup.

Maybe I should... Thank you for the pointer BTW.

to https://news.ycombinator.com/item?id=39873122

Thanks for the link, I swam back to the main thread, read most of it and still love lzip 😍 (and brotli)

google invested in jpeg xl too... google disproportionate ability to push for new standards is a fact which can been attested : compression (brotli, snappy), protocols (SPDY then HTTP/2 and /3), image and video formats. Owning two monopolistic windows on the webternet : android and chrome, they can steer the boat their way, and they will

if they will steer the boat in any way, at least they should make it more smooth, not more rough...

It doesn't help when they're only competition. Real competition are useless pieces of trash.

ios doesn't *really* compete with android in the same way that firefox competes with chrome

agreed: we want diversity and/or plurality, not exactly competition

this is why I want servo to succeed so badly, since it can be a real competitor since its very much oriented towards a community project

what was a big hit to diversity was when EVERY browsers (opera, edge, vivaldi, etc.) all went to use blink

~~also it can load some porn sites now~~

it couldn't before? 🤨

Then Servo is way further behind than I imagined

ladybird progresses ridiculously fast and well too

if my understanding is correct, Servo was something like 80% done at every level, but the remaining 20% requires yet another 80% of time each

which is the reality of web standards

Servo has two layout engines. The old engine was much more further along, but technically interior than the new engine, so the current maintainers decided to deprecate the old engine and focus on the new engine because it is technically superior and will be better in the long run.

it is, well, a standard and one that has been written pretty well, and you can even implement one or two perfectly, but implementing 100s of them means a lot of inevitable unexplored edge cases

Yeah. When some Servo components were integrated into Gecko, what made it take multiple years before they could make them enabled by default was that they didn't support the web properly, and didn't support all hardware properly.

plurality is required solely for exploring a majority of them after all

engines can focus on whats in actual use rather than endlessly chase after chrome's weekly api additions*

these are for most cases long tails meaningful for some users, but many users have their own long tails 😦

(a smaller portion of them of course include things like FLoC...)

its worth noting that servo still shares a lot of that same code like webrender and stylo

so I think a focused browser actually means something more like a tailor-made set of browsers than a single well-made browser

which would have been possible if there are less than 100s of standards to implement 😦

The issue is you can't really have A tailor-made browser, they don't really work like that. Unless you have one very specific app. But at that point, you're sacrificing so much, it's not worth the effort.

like, in the early day of WWW, there was a web browser written in *Python*

https://en.wikipedia.org/wiki/Grail_(web_browser)

yup, I meant that it would be the real limiting factor for alternative browser engines

client side python ! my dream !

LadyBird is an exciting project but I don't expect too much from that either, there is a very steep road ahead

if the energy spent on ladybird could be spent on servo it would be nice 😄

I still think it's interesting that [NetSurf](https://www.netsurf-browser.org/) supports JPEG XL

the last "independent" browser engine with a substantial coverage in my mind has been, by the way, that of the OmniWeb

hmm, my recollection was a bit flaky, was that OmniWeb or iCab? I'm not sure now...

anyway, I think one of the last independent engines was written by two people where one dealt with layouts and another dealt with scripting

I think that point was the most productive point: you can implement the most of actually usable web browsers after, say, 5 person-year of work, which is not a small task but doable if you had a vision

now it's more like >1000 person-year, I can't even estimate the lower bound

I still think servo is the most promissing browser, partially because of how open it is to the community work, but mostly due to how easy it is to actually hack on it. this is a list of the "sys" packages, which is the non rust components, it is a really small ammount of stuff, and the vast majority of it is platform enablement stuff

the barrier to contribution is very low

servo uses image-rs for decoding so getting servo working with JXL was really easy

I thought r/jpegxl and Hacker News had the worst commentary on this announcement, but of course Phoronix manages to be infinitely worse.

Phoronix is full of Linux fanboys.

i mean, yeah ofc. its an opensource/linux news forum

thats like saying "A candy store is full of people with a sweetooth"

Well said

https://twitter.com/ccwscott/status/1773431658798289335

(original: https://www.yogli.net/tigersuit?pgid=jlaqoedt-93c32eaa-a430-49b6-bc0f-d4607b0b63c5 )

Phoronix always manages to have the most incompetent takes on new projects, it's like some natural law

indeed

A large part of it's self contained nature is that it was the first non-trivial rust software written, making it unsually portable and self-contained for a rust codebase

I wouldn't say it's unusually portable. Most rust applications are more or less the same now. Some ofc rely on non rust libraries. but I wouldnt even say it's the majority.

for a lena replacement, my favorite remains this one : https://mortenhannemose.github.io/lena/

Most Rust devs try to minimize non Rust dependencies IME.

How does soy always give people the same face

the fuck are you talking about

I doubt soy has that much power

if soy gave everyone the same face, like 25% of the world's population would have the same face

some racists will claim it to be the case

yea :/

I was kinda joking lol, I am a fan of deep fried tofu, soy sauce, etc

But people call that particular face "soy face" and I don't know what the true cause is 😂

They all look exactly like that

That unhinged jaw look, eyes popping

This guy looks much more normal by comparison

He isn't about to detach his jaw

This is a good point. Competition leads to winners and losers, and often there are Matthew effects that make things converge to a monopoly (or oligopoly) situation. What is needed is not "more competition", but more diversity and maybe even more importantly: a more democratic decision processes. It is OK not to have dozens of different web engines: it's enough if there is one good one that is steered in a democratic/community way, not in a corporate/bureaucratic way. We currently don't have that though: Chrome/ium is owned by Google gatekeepers, Safari/Webkit is owned by Apple, Firefox by Mozilla, and they all claim to take community input seriously (and to some extent they do), but ultimately the gatekeepers have the final say and if they choose to ignore the community there is no way to force them to change their mind — they are not elected, cannot be held accountable, and do not have to motivate or explain their decisions.

Owned by Mozilla? lol, how independent are they?

We don't even know how they come to their decisions

Or who

Why are there so few browser engines? Because it's unbelievably difficult and complex to maintain one. Why? Because the modern web is a broken POS by design

It's almost as if it's designed in a way that you need a multimillion dollar company

Because of how inherently insecure and badly designed web standards are

Javascript should be off-by-default and web pages should have to request extra privileges to run scripts on your computer, at the bare minimum.

Why that isn't common sense, idfk

ton of features now handled by engines used to be part of operating systems

serenityos' ladybird is kicking that impossibru nonsense excuses with ridiculously fast and ultralowcost development

Just like asking permission to access your microphone or GPS data, there ought to be a permission dialog for JS

If web standards cared about privacy and security that would have happened decades ago

But I think they want to keep the web horrible so that only multimillion dollar companies can be gatekeepers

I heard good things about Ladybird and SerenityOS

I also think part of the problem with web standards is a general public lack of awareness of the inherent design issues with the browser security model

Most people only care about adding extra convenience features like JS and CSS additions

Not re-thinking the whole model of security and user consent

Users are expected to not give meaningful consent when trying to simply read and browse

a lot of complexity could be chopped off if the most popular web services simply moved to their own installable apps on desktop/mobile. theyd still be powered by an embedded browsers but at least its theirs to develop at their dime

Websites expect to be able to do all kinds of things users wouldn't consent to without having to gain permission first

And the website totally breaks if that feature is disabled

That's a problem with web standard design and expectations

Only way to fix it is to add standard ways of obtaining consent and restrict what web pages can do without consent

a lot of basic interactions should be accessible through cli

purely visual interaction will always be bloated

modern webdev is messed because this added complexity means job security

Yes, just because I want to browse somewhere and read something doesn't mean I want to give the website permission to run arbitrary scripts on my PC and analyze the type of environment I'm running and report back to mother base

It's called hyper TEXT

instead of using simple ways of obtaining the result you want, you gotta code everything yourself, document nothing, use [current framework of the year]

Not hyper violation of my PC

Or phone or whatever

Hyper violation of my battery life too

its only become an issue cuz chromium kept adding new stuff and google search/webmasters/lighthouse demand everyone urgently adopt it

Get permission first at least, idk why that's not a standard expectation for everything in life, consent

a slower release cycle like safari' was perfectly fine and kept the web taking its time evolving without anyone burning out or other browsers chasing after a moving target always rocketing away

How did the web get so fecked up?

I think it would be nice if there was just a long period of no (or at least minimal amount) new web specs, or a restriction on the amount and complexity of new specs each year

because iirc there's still a bunch of things/specs from over 10 years ago that only some browsers support today

chrome is google's 'superapp'. ship inside chrome what you want exclusive, store in chromium what you want massively deployed

chromium and youtube should be taken out from google's control and fully independant

would be nice if browsers actually had time to reach parity rather then having to chase new things every year.

this mess is only possible when web services also control where theyre delivered

about current tracking, we had concerns the moment chrome initially shipped - at the time, we just imagined the problem would be chrome integrating google analytics so that "runs best on chrome" sites would be lightweight while firefox would be served the bloated javascripts

A lot of the time the new features are helpful and obvious additions that get rid of worse alternatives like bloated javascript "frameworks"

frameworks are optional code. merging their functionalty inside browsers makes them bloated unmaintainable blackholes

that competing browser makers feel forced to fork as is or made simple derivatives of

mozilla messed its own browser similarly, coupling the engine and browser code in an unseparable all or nothing package that prevents the creation of gecko-powered browsers that reuse an existing shared gecko engine package

in the IE era, we had tons of 'IE shells' that were comparatively simple to maintain and improve and nobody needed to think about the engine internals as long as it wasnt an ancient Trident version

A lot of the additions make things simpler.

But most of the time it does increase the amount of work for browser developers unless it replaces/removes old crap

Directly I mean

Highway on Rust thread, following the comment by veluca:

SIMD apparently coming natively to Java: https://coderoasis.com/java-23-new-features/

Did WASM SIMD come before Java SIMD?

wasm simd is widely available so i guess so

jxl-oxide demo also uses wasm simd https://jxl-oxide.tirr.dev/demo/index.html

is it possible for an encoder to perform against a number of passes? like, instead of generating one final output and serving the result, consider what the quality would be after say 30 generations reencodes using the same parameters

figured jpg is low complexity enough it could be feasible and that could be one way for image farms to reduce generational loss even if they stuck to jpg

someone made an updated visual comparator for image codecs that includes latest versions of everything and jpegli

some first impressions like in for anime-style images were formed based on ancient code so maybe better to reference it in place of the old one that wasnt updated since forever https://afontenot.github.io/image-formats-comparison/

it’s not decoded by jpegli, is it?

looks nice

I forgot how FLIF can do a reasonable job at lossy, for a lossless codec: https://afontenot.github.io/image-formats-comparison/#abandoned-factory&FLIF=s&MOZJPEG=s

Interesting how it adds a lot of 'specks' around fine details

that's also how its progressive passes look like: since it always only encodes actual sample values (no frequency transform whatsoever, just funky interlacing), you get basically something like nearest neighbor resampling, with all the aliasing issues that brings but also more "crispness" than the usual blur you get from chopping off the high frequencies after a frequency transform

Hello, i am writing c code on lzss compression using hash table string matching approach. can i ask about code help here?

don't ask to ask, just ask 🙂 no guarantees that there will be an answer but at least it saves a roundtrip 🙂

okay thanks, i will let you know!

i am looking for simple code for lzss compressor which uses hash table to find match. anyone here has experience with writing LZ family of compressors ?

about above, do the results for jpegli and jxl look proper? idk why but i felt they shouldve had better results. any flaw in the conversion method or more appropriate way to generate results, like decoding jpgs using jpegli instead of native browser decode then converting that to png?

What would be the best method for taking the sRGB colorspace and sorting it all into 256 luminance values that, as a whole, do not demonstrate a color shift when each color sharing the same value is placed next to one another. OKHSV does what I need well, but I'm hoping for the ability to further push the perceptual luminance farther apart. I was thinking about multiplying the value in OKHSV by the saturation and sort the colorspace that way, as highly saturated colors tend to have a higher luminance, but that didn't work

I only need the 2^16 colors that share the same luminance to not hold any noticeable color shift when they're chosen randomly and placed close to one another, but they don't need to actually contain as rigorous of a chroma balance as OKHSV has

Did you try the L of CIELab?

Your assumption that among the 2^24 colors in 8-bit sRGB there are 2^16 colors sharing the same luminance for 256 luminance values, is a wrong assumption

There are way more colors per luminance level in the mid-luminance range than there are in the darks or in the brights

For 0 luminance there is only one color: perfect black. For max luminance there is only one color: perfect white.

Yes, I noticed there's a significantly higher distribution of luminance values for some values, but I'm not super concerned with that

As long as they don't differ too much, I'd happily accept some variation in actual luminance, though to what amount I unfortunately don't have a concrete figure to give

i think there's interactive figure of oklab

you cannot map colors 1-to-1 into a 2D rectangle where one axis is luminance, that's like making a 2D map of the earth without any distortion. You'd have to stretch out the "poles" of dark and bright to take more area than the actual number of colors.

like that ? https://oklch.com/#70,0.1,51,100

yes exactly that

this website is awful ! it shows how the usual RGB don't allow access to MANY saturated colors 😭

quite nice to see the difference between the sRGB and P3 gamut

If I were to show a screenshot of the JPEG XL test page in my browser on my website, showing it supports JPEG XL, would that be allowed? No legal issues or anything?

This would be the screenshot

Yes that is fine, right <@532010383041363969> ? I think that image is yours.

is that Windows Vista/7?

7

<:yay1:1097749673780973588>

I took the photo in the hermitage museum in Saint Petersburg. I have given it to public with a license to use. I am not aware of Russian or international laws that would complicate its use. It is one of my all-time favorite test images, since the red-gray contrasts are difficult for compression.

Unless the interior is copyrighted

Fortunately there isn't any statue or painting in it

<:astolfoarc_thumbs_up:1152603499230675054>

Unless the interior is copyrighted -- that sounds like a French concept

did you run the jpeg with jpegli ? ... with or without xyb 🙂

https://github.com/kode54/dumb/blob/master/LICENSE <:Thonk:805904896879493180>

I could presume that currently most people would use Jpegli without XYB

I have Cog forked by him

I've been trying to make FFmpeg support ICC profiles in the last few hours, without any success.... My goal is to have an input with an ICC profile (i.e. XYB JPG), and a PNG output without attached ICC (the color-space should be applied to the "image data itself"). Using `ffprobe -flags2 icc_profiles -show_frames xyb.jpg`, we can see FFmpeg can see the ICC: ```[SIDE_DATA] side_data_type=ICC profile size=720 [/SIDE_DATA]``` When converting from JPG with ICC to PNG (`ffmpeg -i in.jpg out.png`), somehow FFmpeg copy the ICC for `BRG` color-space (see attachment) but not the ICC for the `XYB` (see attachment). The converted `XYB` is therefore wrong. "Corresponding" ticket: [ffmpeg not writing ICC profiles in images](<https://fftrac-bg.ffmpeg.org/ticket/9672>). From this ticket: [ffmpeg not reading color information from JPEG ICC profile](https://fftrac-bg.ffmpeg.org/ticket/9673), I discovered that there is a [video filter `iccdetect`](https://ffmpeg.org/ffmpeg-all.html#iccdetect), and from what they say in the ticket comments, it is used to read the ICC and apply the color-space. For some reason this filter is not available by default on Arch packages, but it is in Termux packages. So... yeah I've been playing quite some time with `iccdetect` and `flags2` without any success (makeing FFmpeg apply the ICC color-space on the "image data itself" - and then remove the ICC). Anyone could help me please ? https://cdn.discordapp.com/attachments/587033245061873759/1146176676628267098/DSC_4313.jpg

by “applying the colorspace to the image data itself”, do you mean converting to sRGB?

I think the libplacebo filter might be able to do that

if not, in the worst case, you could generate an XYB->sRGB LUT and then apply it using the `lut3d` filter

I think sRGB, yeah. Sorry because I know almost nothing about color-spaces and stuff. My only goal is to have the output without ICC but right colors.

could you give some guidance please? Would be really grateful <:FeelsReadingMan:808827102278451241>

the basic idea is that all RGB images have to be interpreted in *some* colorspace which tells you, notably, _which_ red, green and blue the RGB values are in relation to; “sRGB” (HP and Microsoft, 1996) just so happens to be the colorspace that most software assumes in the absence of other information, and the one that more or less matches the average ’90s CRT monitor (and later displays that have tried to emulate them, although this is less and less true), such that images might happen to accidentally look correct even in the absence of color management

I’m not fully sure but I think this is worth a try: ```shell $ ffmpeg -i 'input.jpg' -vf libplacebo='color_primaries=1:color_trc=13' 'output.png' ```

if that doesn’t work, then DisplayCAL’s “3DLUT Maker” could be used to generate a LUT from XYB to sRGB, which could then be applied like this: ```shell $ ffmpeg -i 'input.jpg' -vf lut3d='xyb-to-srgb.cube' 'output.png' ```

(libjxl also contains a couple of tools that can help in generating such LUTs)

output does not have anymore the side data ICC, but got output with wrong colors also these warnings, but apparently it should still apply the ICC: ``` [libplacebo @ 0x5908774cb000] Detected profile gamma (3.543) very far from pure power response (stddev=3.7), suspected unusual or broken profile. Using anyway, but results may be poor. [libplacebo @ 0x5908774cb000] ICC profile too wide to handle, colors may be clipped! [libplacebo @ 0x5908774cb000] Detected profile gamma (3.543) very far from pure power response (stddev=3.7), suspected unusual or broken profile. Using anyway, but results may be poor. [libplacebo @ 0x5908774cb000] ICC profile too wide to handle, colors may be clipped! ```

trying lut3d rn

it says "ICC version 4 is not supported" when importing the "source profile" with the extracted ICC from above image <:PepeHands:808829977608323112>

oh, then maybe it will have to be done with the libjxl tool + lcms; one sec

```shell $ .../libjxl/build/tools/generate_lut_template --lut_size=32 'identity.ppm' $ convert 'identity.ppm' 'identity.tif' # ImageMagick $ tificc -i 'XYB.icc' 'identity.tif' 'xyb-to-srgb.tif' # lcms2 $ convert 'xyb-to-srgb.tif' 'xyb-to-srgb.png' $ .../libjxl/build/tools/texture_to_cube 'xyb-to-srgb.png' 'xyb-to-srgb.cube' ```

something like this

(I think ffmpeg supports up to a LUT size of 65×65×65, but from what I recall, YouTube silently ignored those larger than 32×32×32, so I’ve gotten into the habit of using that size)

Yet in France you have the right to take a picture of an artwork exposed in a museum, no copyright whatsoever exists in this case.

Should mention, I made the page live yesterday https://eclipse.cx/projects/r3dfox.htm

Really? I have a painting in a French gallery I want a high quality photo of, but all the images are either potato quality, heavily paywalled, or both.

I'm a long time Wikimedia Commons contributor and I've seen many pictures about Taiwan being removed due to including modern paintings or statues

Besides this is stalled https://phabricator.wikimedia.org/T270855

You can take it yourself to the quality you want then 😊

The rule I know is applicable in France, I don't know for other countries

https://www.radiofrance.fr/franceculture/podcasts/le-journal-de-la-culture/peut-on-ou-non-prendre-des-photos-dans-les-musees-7527009

> Alors que l’expo Vermeer fait polémique, car , victime de son succès, elle force les visiteurs à patienter dans de longues files d’attentes, même quand ils ont réservé, mais aussi car les photos y sont interdites. what a badly written sentence

alors que [x], what?

Amazing website

jxl looks very noticeably worse than avif though, unfortunately.

Like in the abandoned factory scene, the orange color of the foliage is noticeably washed out.

It's actually shockingly bad

like hard to believe bad

Like it might even be some kind of color translation error because it's a totally different color even at Large size

I have partial color blindness too

So either I'm seeing something that you need to be color blind in order to notice, or it's even worse than I think it is

Probably the latter.

Can anyone else look at this image and confirm? https://afontenot.github.io/image-formats-comparison/#abandoned-factory&JPEGXL=m&original=m

I'm sure it's not just me.

it is that much worse

And slide comparisons are awful

the images generated for jxl and jpegli couldve been gimped by author's unfamiliarity with both iinm like with mozjpeg, chroma subsampling may changes with the chosen quality level for a better final result with higher perceptual quality and less deviation from input browsers my be decoding jpegs less eficiently than generating pngs from the output jpegs and displaying those instead of direct decodes

It has the settings at the bottom.

I want to believe that I have good color vision, and my mon is nice, but for me the difference is very small, if noticeable at all. Other compression artifacts are much more visible

Well from a distance you can tell the difference in color

Speckles and ringing and blurring are harder to notice from a distance than an image-wide shift in color

I tried to look both close to monitor, where ringing\blurring is visible and from my usual distance (70-80 cm) - no, color is almost the same. BTW, asked my father to have a look, he has red-green color blindness, waiting for the response.

That's what I have. Deuteranomaly

the difference I think I’m seeing is AVIF being slightly too green compared to the original

(normal colour vision, profiled monitor)

ah, yeah, jxl is maybe slightly less saturated

though it doesn’t seem to be a change in hue, as far as I can tell

Yes, my impression is the same

on my end the difference with color is very noticeable, I feel like there is something else going on here

ok yeah this is a Firefox vs Chrome thing

as I suspected one of the images is being color managed while the other isn't in Firefox/Gecko's default configuration

canvas double calibration

I'm on FF

it heavily depends on what monitor you have and if you have a color profile setup for said monitor, For me I have a P3 monitor with a color profile set so the difference in the images becomes very noticeable since only one of them is being color managed in Firefox

meanwhile in Chromium the colors are pretty much identical for me

I have ~AdobeRGB monitor, and it is used with it's profile. But on my machine images are exactly the same both on FF and Chrome. Mb it is because I have non-default color settings in FF?

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/3.5/ICC_color_correction_in_Firefox

did you change `gfx.color_management.mode`? because that would explain it

Yes, I have 1 there

Otherwise images without profile built-in are acid

I'm pretty sure it's because of using canvas

the image decode comes calibrated then painted onto canvas and calibrated again

Hmm

Tricky.

It's extremely noticeable in thorium on windows.

Except in the "large" image

the "medium" image the color is extremely changed

but since it's harder to notice in the larger image, it leads me to believe it's a problem with the lossy encoder

I can see the difference from a distance without even trying

And I'm color blind so, that's pretty awful

at 1 bbp, it should not rape the colors that badly

I think the format is capable of better fidelity than that

it seems to be very far behind avif too unfortunately

which I'm a little worried about, since I think avif is an objectively worse format aside from subjective lossy quality, and blurry lossy mode isn't that important to me.

there is literally zero difference in color on my computer

I tried it on both firefox/linux and thorium/windows, on two different computers and monitors, same results

after zooming in I think I see what you are talking about

I also tried comparing JX Large vs JX Medium and there's the same obvious difference

The Large image is fine

The Medium and below is completely different colors

Since I'm comparing JXL against JXL it can't be a difference in the decoding process

It's definitely a problem with the encoder.

I'm convinced now but idk maybe it's only visible to my colorblind eyes and not to normal people

But that would be pretty unlikely

if I zoom in, I see that some orange details disappear

I'm seeing it now it's just the color management thing with Firefox and my monitor distracted me

I'm looking at the foliage on the left side of the image.

The red and orange

The color of the foilage pops and sticks out on the Large and Original images and it seems very different even from far away on Medium and below

does anyone know where the images can be found for download?

weird thing is I remember doing a very simple test against AVIF and JPEG XL a few years ago and the JXL kept colors but lost details while the AVIF kept details but shifted around and lost colors

the source image can be found here: https://afontenot.github.io/image-formats-comparison/cite_images.txt and the bottom of the main page says what versions of encoders where used

I remember that too, seems the tables have turned

here are the images <https://github.com/afontenot/image-formats-comparison/tree/master/comparisonfiles/subset1>

I notice the same desaturated colors in the mercado image too

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

should probably be tested against the master branch of libjxl

since libjxl 0.10.2 does not have the improvement I linked

(not saying the website should but us)

That's a pretty significant change yes

At least it looks like it could be

Gotta test it...

The bad colors is very noticeable across a lot of images here, like "end of show"

It's a shame this comparison gives a very poor impression of jpegxl

Lots of cases where they're tied, a few cases where jpegxl looks better, but when jpegxl looks worse it looks obviously worse by a huge margin.

Personally I hate blocky and smudgy artifacts, I hate it when the color significantly changes, and I hate color banding. But I don't mind high-frequency noise that's hard to see from a distance, that obscures other artifacts like blur. I think the human eye is most commonly forgiving when it sees noise instead of weird low-frequency distinct shapes of other common image artifacts. I wonder... Would it be possible for jpegxl to mask lossy artifacts as dither-like noisy-looking artifacts instead of blocks and smudges? I have a feeling automated metrics would hate that sort of thing but human eyes would love it.

I would be a lot more willing to consider to use lossy compression if it added fine grainy noise instead of smudges and smears and blocks. It would look very "photographic" and natural by comparison. idk how feasible it is though.

Then the next recompression iteration will be like: Ah sh.., here we go again

Got response (from red-green blind person): no, there is no difference

smells a bit like colour management shenanigans

some of it was but once that was sorted out it seems like there actually is something with the colors although I assume the merged pull request I pointed out probably improves the situation or negates the issue

Hmm, so maybe I'm actually seeing something that a lot of people don't seem to notice well, despite my colorblindness. Like I said, I'm looking at the red and orange foliage on the left. It's very noticeable even from a distance to me.

Even just comparing Large and Medium

I don't think it should be that hard to notice

I noticed it the other day, JXL seems less vibrant compared to the original of AVIF, but hopefully the increased chroma quality merged recently helps

we could do this -- now we are opting towards smoothness, but to a lesser degree than most other codecs -- we used to do this a lot more, but Jon changed it (with a 2-3 % objective score improvement) back in the day, perhaps three years ago -- we could have modes for this

Human eyes are very different than metrics unfortunately. And I think lossy codecs should be designed for human eyes, not metrics. I think in general, human eyes are more accepting and forgiving of noise and grain compared to smears and blocks. I think the reasoning is very simple actually. It's high-frequency noise and distortion, instead of low-frequency.

Low-frequency signals are easier to mistake for spurious structure and geometry that isn't supposed to exist

High-frequency blue noise has no structure so it's harder to confuse our visual cortex into recognizing shapes and patterns that weren't in the original image.

It's easier for our eyes to ignore.

Personally I would be ecstatic if libjxl went in that direction, and metrics be damned.

btw, I notice HEIF also has a similar problem with colors in the comparison...

What's the name of that test image that has a table with grapes, a clock in the background, a color palette, some kind of wheel in the foreground...? Often used for testing image codecs

Wasn't it the test setting used by dpreview.com? I don't know if an original image exists...

I just want to see it again, it's one of the best test images

I can't find it again 😄

the one with the lobster?

It seems that dpr have never had grapes in the test scene https://www.dpreview.com/articles/8217017575/a-history-of-the-test-scene , also imaging-resource does not have it

the one with the bicycle wheel or something like that

it is important to have some details on a red background -- that is the most challenging environment for digital photography and for compression

Could you explain why it is the most challenging for digital photography, please? In a few words, to get the main idea

This one https://github.com/libjxl/conformance/blob/master/testcases/bike/ref.png?raw=true

It's a good test image because it has a variety of tricky things: the subtle background on the wall that easily gets smoothed away, as well as the texture of that tablecloth; the colors and textures of the fruits, plants, lobster/salad; the reflections in the glass; the lettering of the clock; the high-contrast spikes of the wheel that are prone to ringing; the interference between the tennis racket and the bike and the test patterns below the clock that can easily cause aliasing, etc. That said, it is also a bit of an exaggerated "demo image" that can be used to showcase directional prediction modes but that isn't very representative for typical image content.

here's the original image btw, the one in the conformance repo is lossy

this one seems to be missing the ICC profile, though (iirc, it’s supposed to use the Rec. 709 transfer function, not sRGB)

oh, right, they're not sRGB — these test images are really old

yes ! the lobster ! what is the source ? Who took it first ?

https://github.com/libjxl/conformance/blob/master/testcases/bike/itu-t.24_ReadMe.txt

the racket in front of the spokes is amazing 😄

indeed, my bad

it comes from this: https://www.itu.int/rec/T-REC-T.24/

the version from 1998 was a TIFF in CMYK and was distributed on a CD-ROM

so last century

I don't know where it came from and when/how it was converted to RGB

but yeah the image must be at least 26 years old and probably more

it was most certainly a scanned film of an analog camera

yes, I don't think there was a digital camera that could do that back then. It does look like a scanned film with some mild digital postprocessing (some unsharp masking, and the addition of the "ISO 400" text)

Maybe some scanning DB? However I'm not familiar with that era, my DB knowledge starts at 2002 🙂

I'm not sure why, but it's true. Red textures tend to get blurred by lossy codecs or the color often changes.

No, the question is about digital photography, not encoding

Not exactly sure, but maybe most phychovisual models greatly underestimate our ability to see details and texture in red surfaces.

He says "that is the most challenging environment for digital photography and for compression" - I assume he is referring to lossy compression.

Mosaic color filters in digital sensors tend to have less red as well.

Usually mosaic filters have extra green

I think the human eye is least sensitive to blue, if I recall correctly.

Is there a convenient way to correct the colors or get a version of this image with correct colors? This one is washed out.

That'll be from the missing ICC

But the same is for blue, because number of red and blue pixels is the same. My guess is that usually (but not always) red is the least sensitive channel, and for red colors there are no\few signal in green\blue channels. But let's wait for Jyrki

I think that's right

Red and blue textures commonly get very ugly thanks to lossy compression and chroma subsampling.

But our eyes are probably better at noticing it with red than with blue.

I think you missed that

when it's captured, the blues and reds have a lower resolution than the greens, thanks to the nature of the sensor. It's encoded in a bayer matrix because that's how the sensor itself encodes it when it's captured. You cannot somehow "separate" digital photography from digital encoding.

"that is the most challenging environment for digital photography and for compression" - compression is digital encoding too.

Here is a version with a correct color profile. It's not a huge difference compared to the one misinterpreted as sRGB but there is some noticeable difference.

When you say the one in conformance repo is lossy, do yoy mean the PNG is a decode of a lossy JXL or something?

yes, the conformance repo is for testing decoders and the png files there are reference decoded images

I notice that it looks amazing despite being a very small jxl file. Was it made by hand somehow?

does it? it looks rather artifacty to me

with that said, I have no idea how (say) AVIF would compare because I don’t know what flags I would be supposed to use

ah, I have some flags in my shell history

I guess it’s crisper (but also slightly larger)

IrfanView seems to struggle with CMS and new image formats 😦 For jxl it just ignores built-in profile, for avif it shows completely wrong colors when CMS is enabled in IrfanView settings (keep in mind that dulliness is because of Discord does not understand that my mon is wide gamut and screenshots must be tagged\converted)

windows apps in particular tend to default to color management off as a default it seems rarely gets revisited over time. opposite for store apps like Photos

Also worth mentioning that avif needs 390 ms to open, and jxl - 45

are these intentional artifacts

No idea

I just wrote out the full XYZ to CIECAM16 transform and I feel so drained. Are there any other widely used colorspaces that are this complex, conversion wise?

I believe this is moire caused by scanning non-ideal horizontal-vertical target orientation

👌

I didnt realize those were patterns that were physically in the scene

that scene (in jxl conformance test suite) has caught numerous bugs in jxl-oxide

Is there a way in HTML to have a fallback image? Say I have a website, and I give it a JPG, WebP, and JPEG XL image to display. Is there a way to say have it try JPEGXL image first, and if it fails go back to WebP, and if that fails go back to JPG?

`<picture>` is exactly for that https://developer.mozilla.org/en-US/docs/Web/HTML/Element/picture

see here for a simple example of it used in a page: https://github.com/jxl-community/jxl-community.github.io/blob/main/index.html#L287

Please don't even bother with webp, I'm begging you...

<:Think2:826218556453945364>

If you use mozjpeg or cjpegli, the quality and filesize ought to be similar. Plus you get the benefit of progressive decode if you don't use webp...

idk I've just used paint.net

But if there's an easy tool you can give me to do basic 80% quality encodes I am willing to try

It seems that the picture thing falls back even in browsers that have no hope of supporting picture, so I might use it

I think I iwll just use cjpegli

When will a v0.10.3 or v0.11.0 exist I want to wait until a new version to try

Much better when using lossless

A good lossless codec that was needlessly and intentionally crippled and limited to match the half-baked lossy codec it's unfortunately attached to.

webp is pretty good you have no idea what you're talking about

Ever since it was first shoved down our throats codec experts warned it was no better than ordinary JPEG

Less features, worse quality, and a good lossless mode with arbitrary limitations forced on it by committee.

It's an absurd format

?

PDF week begins May 6 in tokyo, physical and remote. Imaging model will de discussed May 6 and 7 https://pdfa.org/pdf-week-tokyo-starts-may-6/

anyone attending as a member or expert ?

ordinary jpeg??

ordinary jpeg is such a low bar for lossy compression

webp is definitely better especially at lower bitrates

That it's unable to beat ordinary JPEG is exactly why it's so ludicrously bad and the whole reason why the codec team at mozilla and xiph objected to the standardization of a new mediocre format.

But I'll do a test right now, just to confirm and make sure.

jpeg was 'alien technology from the future'

even in 2024 the full scope of its specifications havent been implemented

video-based codecs dont even satisfy today's needs and have unfixable limitations baked in. hardly futureproof

Where are examples of jpeg beating it? All the examples ive made and seen have webp do much better than jpeg

I tried making a comparison just now with the bike image, but cwebp ignored the color profile and messed up the colors.

In comparisons by mozilla and xiph and cloudinary, mostly.

Ah

I use whatever jpeg library GIMP uses lol

But I am happy to test it myself right now. But already cwebp messed up the colors.

I used the image wb posted with the corrected color profile

but it looks like the one with the wrong profile

cjpegli did not mess it up somehow

Even though I used XYB mode

-metadata all

lol, thanks, I'll try that. Interesting how something that affects the visual result and fidelity is an option that's off by default.

webp arguably looks slightly better here, I'll admit.

Lmao

But, it lacks progressive decode, so jpeg actually shows up on the screen faster. And it lacks other features that boring old jpeg has like 4:4:4 chroma sampling

Webp is only subsampled?

in lossy mode yes

Im highly unfamiliar with webp

and lossless mode has arbitrary limitations imposed on it, like on image size and bit depth (only 8 bits)

Mmm

I don't mean to be a buzzkill lol I just really hate that webp is even a thing

Believe me i also hate webp

JPEG is fantastic

Heic?

Webp just seems like google trying too hard

mozjpeg beating webp is outdated data, so mozilla's old comparisons aren't really relevant

lossless webp is pretty darn good

oh i personally dont work with lossless stuff

so im not familiar

it must be better than PNG but im pretty sure JXL is better than webp?

the gap from png to webp is a lot bigger than from webp to jxl

but lossless jxl should improve over time, I think the devs spend a lot more time improving lossy

ah okay

lossless jxls are consistently half the size of a png (closer to 55%, higher with clean sources with large flats color regions like in digital art and digital comics

imo the best sources for lossless compares and best candidates for offering downloadable or prioritize displauy of jxl versions of their creations)

for small clipart-like iconry, afaik the video-based codecs have a *minimum* resolution limit hurting their efficiency (64x64 pixels ?)

oh really?

i understand their efficiency being hurt

another reason theyre not suitable to use for say compression avatars or thumbnails

makes sense

a few months before, someone compared formats generating thumbnails for hundreds large images using recommended or default settings. almost all formats generated thumbs in less than 2 seconds, avif alone did so in like 35 seconds each (!)

a shame i couldnt find it back, bro swore off that in no time

holy cow that's insane

in hindsight its understandable why even cloudflare doesnt generate avifs for anything but relatively small images and generates/serves webp for everything else

The JPEG is progressive.

Wow, I didn't expect this

It looks a lot better than the webp, especially areas with red edges

It's very noticeable

This is just using: `cwebp -o mercado.webp -metadata all mercado.png`

Then I made a JPEG the same size with jpegli

It utterly destroys webp at this image.

I did the same process with the other test image with the crab and the bike.

Anyways, this is why you should never ever use webp ever for any reason >:(

webp stores to yuv420, so lossy conversions will always reduce color accuracy even at the highest quality. across say 200 recompressions, colors naturally shift towards green

image editors generally edit in rgb so thered be some precision loss from doing colorspace conversions but it can be minimized

much of the touted file savings of video-based codecs come from *discarding too much data*

JPEG is just plain better.

It often beats webp at quality at the same size, or gets close, and it's more compatible and faster, and has pregressive decoding.

lossy webp is quite good at medium high and lower

webp is good for... video

because it's VP8

keep in mind that the webp devs actually forked the vp8 encoder and optimized it for still image photography

at least video is something JPEG can't do as good

like until jpegli, webp actually did win against jpeg for anything where 420 was fine

this wasn't true when webp was new, but they did good making the webp encoder better

it still beats jpegli below like, q=75? idk the exact number.

Mjpeg (barely a video format) mpeg-1/2?

Basically jpeg for i frames

I bought a webcam a few years back. Then I found out that the newer more expensive model didn't have h264 output, only mjpeg.

😳not even mpeg-1?

Or mpeg-4 part 2

That’s insane

Mjpeg has such a high bitrate compared to something that actually compresses temporally

yep, mjpeg 😬

How much was the webcam

That’s inexcusable on the manufacturers part

like $250?