JPEG XL

but XS means something more like "extreme speed" since it aims at low-complexity, ultra-low-latency

and then I think they chose XL just to contrast with XS: where XS aims at being very simple and low-complexity, i.e. it's literally something meant to be implemented in hardware in something like a video cable, XL aims at being very complete, has many features, and doesn't aim at ultra-low-latency but rather at very good compression (which is not something you can do if you also want a latency that is measured in lines)

but I don't think anyone really knows. The name was chosen before I got involved in JPEG (it already had a name back when it was an adhoc group lead by Netflix that was drafting a call for proposals, and I only got involved after submitting my FUIF proposal), and nobody is really sure what it means but "long-term" is one of the things Touradj mentioned when I asked him a while ago

EXTRA LARGER

I've always thought it was pronounced like "web-pee" 😂

That IS how it is spelled and it makes more sense to call it that

Either way it's out-of-this-world dumb-sounding

“P” and “B” are voiced/voiceless variants of each other, so it makes sense that they’d be conjoined into a single phoneme.

I don't think so. You don't pronounce "web page" as "web age" or "wep age"... Web-pee is the pronunciation that makes most sense to me.

How does jpegli compare to AVIF in compression?

That’s fair, though when pronouncing it quickly, I dare claim “web page” and “weppage” would sound undistinguishable, or nearly so.

Also, correct me if I'm wrong, but isn't WebP stuck with VP8? So they couldn't even use the improvements from VP9 I think

yes, webp is vp8 just like avif is stuck with av1 and when av2 comes they'll have to define an avif2 — even with 'informal' standards like webp and avif, you cannot just change the codec completely, that would be an interoperability nightmare

libvpx supports both vp8 and vp9. libaom/libavif/libheif can potentially add support for future codecs and existing software gains support via libraries' upgrade.

if they create new library with rare dependencies, road of adoption is longer.

There's too much stuff not using dynamic libraries but static linking. If a future libwebp would start supporting vp9 payloads or a future libavif would start supporting av2 payloads, that would cause new bitstreams to still have media type image/webp or image/avif and decode fine with upgraded decoders, but non-upgraded decoders would fail on them. It would create a lot of confusion and problems.

Are you saying that dynamic linking is a good or a bad thing?

I think upgraded webp or AVIF would work as long as one of following is true: 1. It uses a new mime type 2. It’s backwards compatible with existing decoders

I remember there was some issue a long time ago where some browsers supported lossless webp and some not and there was no easy way to detect the support

yes, and the same with animated webp

and now it's kind of the same with animated avif

these formats aren't designed to be forwards-conpatible like PNG, unfortunately

but realistically using a different coding algorithm would be hard to do with that

I don't think you really can design formats to be forwards-compatible. PNG does have a field to signal the compression method (which has only one option: deflate), so in principle you could add other compression methods but it would still fail to decode in viewers that don't support that, so in practice it does not really help to have such "extension options"...

I meant more like how PNG has lots of extensions (e.g. sRGB chunks) that viewers can either choose to read or silently ignore.

And if the decoder silently ignores them then it won't see something it doesn't understand

ah yes, its chunk naming convention is quite nice

but basically you can only add extensions that can be ignored

I hope they go with av2f as the name

av2f vs VIC vs Jpeg XXL

https://encode.su/threads/3397-JPEG-XL-vs-AVIF?p=77946&viewfull=1#post77946 I got post by Pascal Massimino (skal) from Google, with issues to Jon regerding some tweet about Bankoski?

I guess <@794205442175402004> is the best person to reply to this 😉

He means a tweet I deleted because I considered it not wise to put a name there, since I don't want people to be "thrown under the bus". Why is skal now putting that name out there again? He is throwing Jim under the bus 😅

Now my army of jxl zealots is going to make his live hell

It is my opinion that decision makers should be held accountable for the decisions they make, but it seems like that is too much to ask. So I deleted the tweet that was naming a key decision maker because that only gets seen as an attempt to turn things to personal attacks, while I think we should have a debate on the content, not on people.

So far my attempts to have an open discussion have not been very successful. Or at least the discussion is going very slowly. I am still waiting for a response from the avif team on my feedback on their comparisons.

They acknowledged receiving my feedback but that's all I got in the almost two months that have passed since I wrote that blogpost.

thanks, I have added response and request for clarification

I deleted that tweet on the day I wrote it btw. But I guess the memory of it remains vivid...

To play devil’s advocate, though, if I may, I haven’t found a clear position on two main (at least in my mind) arguments: decode speed and low quality competitiveness. I don’t even know if their tests have been corroborated. I hear many an insult here thrown at those tests, but being a luddite, I have no idea and no way of checking if they are considered/are flawed or genuine, but unimportant or if work is being done to improve in the areas they highlighted as possibly benefiting from improvement.

I did address both of those points in https://cloudinary.com/blog/contemplating-codec-comparisons

It would be interesting if others (and in particular the avif team itself) could weigh in on these technical aspects of the discussion. So far I haven't seen any counterargumentation to the points I made.

<@794205442175402004> https://discord.com/channels/587033243702788123/610740411723546635/1070759577597001832 the same problems in the av1 discord comparisons that the bd-rate plots don't show the real difference at high quality as it is seen at low quality https://cdn.discordapp.com/attachments/610740411723546635/1070799550572396696/image.png

Since you wrote https://cloudinary.com/blog/contemplating-codec-comparisons#decoding_speed (which mentions tests being done on Chrome 92), they posted https://storage.googleapis.com/avif-comparison/decode-timing.html, which to the layman looks slightly worrying. Or not? Does JXL have a problem with decode speed or does it not have any such problem?

It has a bit of a decode speed problem on arm32, but not really on modern phones or on desktop imo.

(most obviously, I’m not interrogating! also, I don’t have answer to any of my questions upfront. they are just that: questions)

Is this for a single image? What image is it?

I don't know, just saw this comparison, probably a single image

Is that problem on older hardware possible to fix/improve by the implementers (Chrome team/Mozilla etc) or would that need to be fixed by JXL itself? Or – maybe it can’t be fixed? Or – maybe it’s considered not worth it to spend valuable dev time on improving something that will go away in time?

speed is not a real issue as has already been discussed and compared https://discord.com/channels/794206087879852103/1050717952871251988/1051505977729482782

It can be fixed, but I think the main issue is not the old hw, but that they're somehow using arm32 builds when testing on hw that can actually do arm64. On arm64, speed is not an issue.

For single images, it can very well be the case that avif outperforms jxl. Which is best is quite content dependent. Overall I see jxl perform better, but certainly on every single image.

I think jxl is overall 15% better than avif at web-relevant qualities, but on individual images avif can be 10% better or 40% worse

yeah, I also mean that on such plots, the difference in high quality is squeezed, also this difference is difficult to precisely compare by metrics and basically most formats look like nearly equal

Could someone contact Google in some way to update the feature status for JPEG XL? Firefox now has a Neutral position instead of No Signal.

is neutral even a supported option?

don't know how that website is setup or handles things

lmao I just realized that it's common for royalty to use "we" instead of "I" when referring to just themself.

So it looks like that's what these people are doing here. Using the royal "we" when saying "We decided that JPEG-XL is not good enough but AVIF is."

After all, they are the supreme Guardian Gatekeeper Gods of the Internet itself.

It's only natural they should speak like royalty

Unfortunately, at the end of the day, a person will decide NOT to have a debate and a person will decide not to take responsibility for their own decisions, either.

I like your analogy but I’m more inclined to believe it’s a decision made by a single person and “we” is there just to imply that it’s some kind of broad consensus

JPEG XXXL MAGNUM

Why, you may ask? Because they CAN, and that's the easiest and most convenient thing to choose.

If they don't have to do anything else and have no accountability at all, of course they will.

libjxl would need to be updated after adding some arm7 perf tuning

When I say "webm" or "webp" in front of live human beings I get weird looks and often interrupted and asked to repeat it again because it doesn't sound like something that is meant to be a word.

https://storage.googleapis.com/avif-comparison/decode-timing.html The decode speed looks very bad across the board here, not just on armv7 ISA... For what its worth Jon here made his own test page for measuring decode speed if you would like to try it. I believe it is located here, but maybe Jon made another one that I lost the link to: https://sneyers.info/browserspeedtest/index2.html

In my experience on my own modern (amd64 ISA) hardware, libjxl decoding speed can vary depending on the input image, particularly in lossless mode. But for DCT images (including losslessly-converted JPEG) the decode speed is extremely fast, faster than dav1d.

Lossless can in general be slow(ish) to decode, when arbitrary MA trees are used so no specialized decode path can be used. But VarDCT should indeed be 'fast enough' to decode. On current CPUs it's fast enough to decode many screenfulls of images in a fraction of a second, so it's not decode speed that is the bottleneck, but transfer speed and human consumption speed. Compared to jpeg and jpeg 2000, which were both quite computationally heavy for the hardware of the time, jxl is a lightweight codec.

Falkon is a cool browser, does anyone know if qtwebengine has JXL support?

Also JPEG seems extremely simple and fast just comparing it to any other codec.

the huffman encoding is probably the bottleneck of JPEG

I've seen mention of av2f in the av1 discord, and it seems better than jxl lossy from the one comparison I saw, where both images were the same filesize

av2? Is it even slower than av1?

That seems to be a trend with google/on2

and video codecs as a whole

i think we can expect that to always be true, as we get better compression by making the codecs more complex

yeah, even if there are solutions that are faster at the same or better efficiency or faster for modern hardware, it still would be very difficult to make a noticeable improvement in each new format generation without increasing complexity

I have seen these comparisons and it's also at lower qualities where avif will also be better, av2 in the current implementation is only 7-8% better than av1 on typical video content (even without counting encoding time), for high fidelity I doubt it's much different, also av2 will be easier for hw implementation

Low conplexity doesn't have as high a priority of a design goal anymore

it's why H.264 will last forever

since it's actually low enough conplexity to be pragmatic for end-users

We don't always need more complexity to get better compression. Look at QOI.

Part of research and progress is doing the same thing with less complexity/power/work

Personally I think Theora/VP3 could have been improved a lot more before switching over to VP8, which was much slower and not any better than a fully tuned and optimized theora encoder could conceivably do

JPEG *was* a computationally-intensive algorithm back when it was introduced. I remember what is like when JPEG was loaded to a good old DOS machine.

while the computational growth of those algorithms is far larger than the actual computational power growth, algorithms *will* become substantially more complex as computing power increases anyway

Maybe someone could have modified x264 to output theora frames, xTheora :)

Theora was ridiculously fast

If you compare the final release, libtheora 1.1, to the development branch 1.2, which never made it to release... the difference between 1.1 and 1.2 is night and day

xiph/mozilla was putting a lot of tuning into theora before open source vp8 was announced

xiph/mozilla also significantly contributed to the development of AV1 later, before mozilla fired everyone involved, along with all of their other engineers

qoi is simpler, but doesn't have better compression (it's only better than the fastest modes or bad implementations) and for more complex formats like modern video formats, something very simple and at least as efficient is almost impossible, maybe just simplify some parts (because there are some new algorithms or hardware has changed and so it became possible to use some simpler but slower methods, etc.)

Hell look at LZMA vs ZSTD

or gzip vs lz4

no? zstd doesn't surpass lzma in compression ratio, nor lz4 does the same for gzip

they instead have a different trade-off which was not possible before

for example zstd is strictly superior to gzip in every aspect

which means, if you have a fixed computational budget, the ratio can be improved; if you have a fixed target size, the compression time can be shortened

and zstd is possible because it better understands and exploits modern computer architectures

if zstd were introduced at the same time deflate/zlib/gzip was introduced, then it would've been much less practical than today

what we should demand is an *adequate level* of computational complexity, not just a low complexity because there are only so much things you can do with that complexity

They are practically equal, within a few percentage points of one another

And hundreds of times faster

highly depends on workloads, as you've paired they can differ by ~20% in ratio

(especially for lz4, which doesn't have any entropy coding)

for some parameters LZ4 gives better compression than gzip, large benchmarks: https://encode.su/threads/3315-enwik10-benchmark-results

of course, if you compare the highest level in lz4 (-9) with a low enough level in gzip (-2) that can always happen

that's what I meant by a better "trade-off"

and https://github.com/inikep/lizard is pure LZ reaching gzip -9 there

note that lizard can reach ~~gzip~~ zlib -9 ratio but that takes more compression time

I think lizard is not fundamentally unsuitable for that use case, but that is probably not the lizard's main focus area

3,249,895,474 bytes, 307.467 sec. - 53.869 sec., gzip -6 (v1.3.12) 3,242,491,764 bytes, 341.968 sec. - 53.809 sec., gzip -7 (v1.3.12) 3,240,805,000 bytes, 422.917 sec. - 10.572 sec., lizard -45 (v1.0.0) 3,237,924,757 bytes, 390.420 sec. - 53.756 sec., gzip -8 (v1.3.12) 3,237,812,198 bytes, 392.835 sec. - 53.771 sec., gzip -9 (v1.3.12)

indeed, but it is not that far

lizard's main selling point is of course a very fast decompression

yeah if you need something like LZ4 but more compression lizard seems doable

beaten only by http://fastcompression.blogspot.com/p/zhuff.html there - precessor of zstd

AND it's getting more and more into the <#794206087879852106> or <#805176455658733570> area, sorry everyone

AV1 is perfect

https://twitter.com/GaiaSky_Dev/status/1621449291691606016

what does this say in english?

https://www.gamingdeputy.com/it/android/jpeg-xl-mozilla-non-supporta-neanche-il-nuovo-formato-grafico/

... it almost looks like it was machine translated

"we haven't estimated how much effort it would take to finish it" FOR GOD'S SAKE JUST CLICK THE GOD DAMN MERGE BUTTON ALREADY, IT'S BEEN FINISHED YEARS AGO

lmao they haven't even begun to estimate how long that is going to take

where's that

https://github.com/mozilla/standards-positions/pull/741#issuecomment-1414685282

this is why I lost faith in open source

indeed, top of their trending webpage for months ( https://connect.mozilla.org/t5/ideas/idb-p/ideas/status-key/trending-idea ) ... and they say they didn't even bother to look at it

this is just awful, and further shows mozilla's fall from grace

What sort of asinine corporate bullshit do you have to swallow for a statement like that to make sense. I mean the code is already written the patches are ready to be merged

You can already try it out in waterfox right now

It's complete, done, it's at parity with all other image formats once you merge those patches

hdr isn't done

But ig it's not done for every other format

That's why I said parity.

And a lot of problems with HDR and color profiles in firefox, look like they are willfully unsolved because it "might" cause compatibility problems

this is just a corporate project at this point which happens to be source-available in open-source license, can't be seen anything else than that with how they are handling contributions

what pisses me off is that (just like Chromium team) they don't answer the questions

Both firefox and chromium are basically "Corporate Open Source", which seems to mean "you can see what we're doing and work for free for us, but you don't get any say in the decisions we make". Sure, you can make a fork if you want, but 66% of the market share is held by Chrome itself, then 20% is Safari and then there's 4% for Edge/IE, 3% for Samsung Internet, 2% for Opera, 1% for UC browser (these are chromium-based and unlikely to deviate from upstream), 3% for Firefox, and then the remaining <1% is the very long tail of "exotic browsers", many of which are forks of chromium/firefox/webkit and open to community input/contributions but their overall impact is quite small. Even if ALL of the forks would decide to enable jxl, that is still less than 1% of web users, so as a web developer it doesn't really make sense to add jxl variants of your images just for such a small demographic.

teh corporate opensource browser cabal

Thorium is quite nice. Feels a little snappier than Chrome. It's otherwise basically exactly the same thing, except it seems to be maintained by someone who likes to do things in a way that just makes sense and is better for the user. The differences seem to be mostly making things faster, removing annoying things, improving privacy, and enabling nice things by default (like jxl).

How does it compare with Ungoogled Chromium? 🤔

I am dreaming of an ecosystem where forks are way more commonly used than Chrome itself, and if a fork starts making bullshit decisions, you just switch to a better one. No single gatekeeper can block a feature that many want, or force-introduce a feature that many don't want. I think that's the whole point of FOSS, in particular that's what the F is all about. We have been using the Corporate Editions of the software for too long. Time to go back to the Community Editions!

It is using some patches from ungoogled according to https://github.com/Alex313031/Thorium/blob/main/infra/PATCHES.md

No idea where the differences between the two are though

The problem is that some popular “corporate” free software projects have large user bases that are unaware of the importance of certain features because it doesn’t affect them directly. Surely if Chrome made a change that affects users directly, they’d feel more inclined to move away from it, but since the users don’t see the changes, they don’t feel such a need.

Also, I think the problem with switching to a Chromium‐based browser is that sometimes (albeit not always) they keep Chrome’s user agent string, in a way that causes metric keeping servers to consider for them to be Chrome, so it doesn’t make it seems like the browsers are as diverse as they might be. (Though I suppose I don’t think currently the user base of such browsers is signicant enough to even make a dent on the graphs either way.)

Yeah. I wonder what would happen if, say, Serif and Adobe would start recommending Thorium to view HDR jxl images.

speaking of user agent strings it seems like some bigger forks of browsers are getting rid of their custom strings, for example waterfox reverted to using firefox's default string because websites where breaking and vivaldi ended up doing the same thing. (vivaldi did it 3 years ago while waterfox did it sometime after since they where also encountering websites breaking) https://vivaldi.com/blog/user-agent-changes/

Or maybe a 'bigger' fork like Edge or Opera might decide to follow Thorium's example, that would be cool...

I think one major reason to do that is to reduce fingerprinting. If privacy is a concern, putting an exotic UA string in every request is not a very good idea...

that is one reason however in vivaldi's and I think waterfox's case it was done because websites where breaking if they didn't get the exact string they expected

Though maybe all the exotic browsers should agree on a user agent string to share between them, so in the statistics at least they don't get counted together with the big ones

Chrome has been working towards taking away information from the UA string slowly over time.

That's very bad website behavior but I can totally imagine that this happens. If I made a fork, I would still send the UA string I want, and let those bad sites break because they deserve to break (and add a 'compatibility/privacy mode' option to send another UA string, so you can still use those bad sites if you really need to)

(The goal is to eventually make it useless for the purposes of detecting which browser is being used.)

Well it used to contained very detailed version numbers and OS and cpu info, for no good reason really.

I was on a website for a virtual medical appointment and it told me the site only works on Chrome and Firefox and that I should download one of those, even though I was using a Chromium browser, so I had to download another browser to do it

both are on Chromium 109 now - any chance for leaving jxl in 110 there?

Generally the only reasonable use of UA strings is to circumvent known bugs or limitations - like a browser saying it accepts a format but actually it's broken when there is alpha or animation, so probably you should send it a fallback format in those cases.

once time I was on my phone and some of my friends where using a website meant for screen sharing and I opened the website in firefox and it would not let me use it because it said I needed chrome so I ignored what it said and faked my user agent in firefox to be chrome's one and the website worked perfectly fine for the couple of hours that I used it

https://github.com/Alex313031/Thorium/issues/104 looks like Thorium will keep it, yes

> Includes Widevine 🤔 🙃

I use UA to decide if I want to enforce HTTPS by default

It depends on OS also, since browsers use root certificates from there

the project lead has not made a statement on whether or not support for JXL will be kept post M109 however them making support turned on by default seems to suggest they would want to keep JXL support

however the patch to restore JXL support is large so they might drop JXL support just because of that reason

Nearly everything should be done by content negotiation or other forms of proper feature detection. Assuming things based on UA is only a last-resort fallback in case there are bugs that cause the normal mechanisms to fail.

Well, client-hints still provide all the old information for fingerprinting, and even more. For example, you can get exact version of Windows 10 that wasn't possible.

Firefox makes it so that it uses Chrome's UA string on several websites (including the CDC's COVID website) because of stuff like this, so maybe file a report

https://github.com/mozilla/standards-positions/issues/552

I do agree with Mozilla about replacement of User-Agent to Client Hints.

Not for cross origin requests though, at least unless specifically allowed by origin. Origin can also use javascript and get a whole bunch more fingerprinting info that way, client hints in that sense don't make things worse than they already are.

The main harmful thing about UA client hints imo is that there just is no reason why UA should matter. Client hints are about allowing responses to be adapted to variable available features and client conditions, like "i want to save data so please send me a small crappy image instead of a nice big one, if you can" or in the future things like "i am viewing on an HDR screen so please send me a HDR version of this image if possible".

Assuming features or viewing conditions based on UA is just a bad idea.

OS information in the UA is also useful to provide a download for your specific OS. For example, if somebody is on Windows ARM, the green DOWNLOAD button could link to an installer for ARM with small another link "other versions" underneath.

It would be better if we could do that kind of thing by having css queries that allow you to show only the relevant buttons. That way the server doesn't need to know.

Or just use js for that.

The CSSWG thinks it’s harmful to be able to make those kinds of queries from CSS because those aren’t things that should be able to make a page look different for users. They used to have e.g. mobile media queries, but removed them from the specs before they were actually implemented by browsers because that isn’t a good criterion influence the appearance of the webpage (though things such as “whether the main pointer device is touch or not” or the width/height of the viewport are).

The premise is that the page’s layout and style/appearance shouldn’t change depending on criteria besides the capabilities of the environment related to displaying the page (i.e. things such as whether the display is grayscale would be a good criterion, but not the specific operating system, since that shouldn’t influence the ability to display the page, and thus should be opaque to the page).

Fair enough, css is about display after all.

Client-side JS would be the right thing here, no need to tell the server what the OS is.

That’s fair, though if the concern is privacy, if it’s queriable from JavaScript, a `fetch` request can always give it away.

That's how forks are supposed to work... ideally... in theory... but not when you are forking a crappy corporate "enterprise-y" codebase full of fragile overengineered bloated garbage that's impossible for anyone to maintain except for a corporation that likes to waste billions of dollars maintaining code that should be rewritten

It's good to rewrite things from scratch after a certain amount of time instead of continuing to maintain something that is not reuseable and should be thrown out.

Like webkit/blink

That's why Servo is kind of exciting, maybe.

if only there were chrome forks that were as customizable as Firefox, maybe even legacy/full xul themes level

Isn’t that what Vivaldi is?

Vivaldi is nice only problem is it's UI runs very slow if you put pressure on it

I ended up switching off of vivaldi because the amount of tabs I was throwing at it made the UI run so bad it made the whole browser run awful

simple actions that would normally take under a second where taking almost 5 seconds or longer to do

their whole ui is written in html, css and javascript while the ui in normal chromium is C++ from what I remember

I'm guessing many people like watching netflix on their browser

I hadn't seen this poll yet: https://github.com/ungoogled-software/ungoogled-chromium/discussions/2202

maybe someone could open an issue at https://github.com/iridium-browser/tracker/issues to ask them about keeping jxl in?

when you showed that Thorium is seemly keeping support on this issue https://github.com/ungoogled-software/ungoogled-chromium/discussions/2184 they responded saying ```"It looks like they use GPLv3, we won't be able to include patches from the here."``` so maybe my idea from <#804008033595162635> about creating and maintaining patches is relevant here since Thorium is under a license that isn't compatible with everything and also the it seems like the Thorium devs might not make the patches they use easy to apply as I have found no where that just houses the separate .patch files for use outside of Thorium

thing is I don't know who is willing to maintain JXL support patches for chromium

if no one else stepping up to then I would love to do it myself however there are quite a few things that personally prevent me from being able to do so

Maybe we should just put some .patch files for chromium on a libjxl repo. WDYT, <@795684063032901642> ? I think that would help to take away worries about "who will maintain it". Maybe even big forks like Edge might want to use that.

what I'm about to suggest might over complicate things but what if there are multiple patches of varying complexity? since it seems like a lot of the code changes that happened in the removal commit relate to chromium's testing system of which i'm not too sure is useful for most cases or most people's needs

I could be wrong since I know nothing about chromium's testing system thing or whatever it's called but all the code for it does kinda bloat up the size and complexity of what the patch to restore JXL would be

the idea I have suggested of having multiple patches might be a bit much so I guess the question should maybe be "should most or all of the testing related code be removed to make the patch easier to maintain?"

I guess that will be the decision of who ends up making the patch(s) since I'm not really too qualified to comment on all of the individual components of the JXL support for chromium

once a cleaned up patch is available Ill try to see about how much effort it would take to port it to electron and cef i'm not familiar at all with their codebases and application building systems however it shouldn't be too hard hopefully

no It does not seem so, they are simply saying they are unsure if they are allowed to use the work that the Thorium devs did to bring back JXL support

someone not from Thorium would have to make a patch

I don't think that packaging code in .patch files without writing any new line of code is by itself copyrightable (and thus allows relicensing under a less permissible license)

thing is even if licensing isn't a problem I'm not sure if ungoogled chromium will have a good time trying to obtain the restored JXL support from thorium since I don't think thorium makes their .patch files public I can't seem to find them anywhere

overall I think having the .patch(s) available from somewhere else (such as the libjxl repo or a repo just for them) is probably better.

Yes, and also makes it easier if we want to make updates in the integration code and get them synced between forks.

We should probably also do this for the firefox-derived browsers

I propose adding a github.com/libjxl/browser-integrations repo which consists of easy to integrate patches for chromium, firefox and webkit

something to note is a lot of browser forks seem to be privacy focused to varying extents and some of them seem willing to integrate patches that make JXL usable (such as librewolf and ungoogled chromium), however whether or not they chose to have JXL support enabled by default is a different story, with forks such as librewolf they may not want to enable support by default in fear of possible fingerprinting while it seems like forks such as ungoogled chromium might have a sort of policy that "new features" be disabled by default although with ungoogled chromium i'm not entirely sure since I don't know enough about the project

when I am in a more stable mind and not on the brink of falling asleep from being awake for a extended amount of time I will attempt to ask on the ungoogled chromium github what their status is on whether or not they plan or are open to the idea of JXL support being toggled on by default

and for librewolf I need to work together with my friend again and submit a patch to bring their JXL support up to the level of where waterfox is currently

and also see how open they are to the idea of it being toggled on by default although I assume they would be less open due to their heavy focus on privacy and from what I assume supporting a image format that most other browsers don't might be a fingerprinting opportunity

but I'm not an expert on browser fingerprinting so I'm not fully sure, although if it is a worry then if more and more forks supported and have JXL support turned on by default then maybe fingerprinting won't be as much as a worry?

Realistically speaking, it's nothing to worry about.

well the thing is forks like librewolf seem to be **very** privacy focused

so for them It can be something to worry about

having it supported by default reduces fingerprinting potential imo — if it's behind a flag, which some enable and some don't, then it adds one bit of fingerprint. If it's just enabled by default, and nobody disables it, it doesn't add to the fingerprint.

thing is the userbase of a fork can't be considered the majority even if the fork has the support turned on by default it doesn't matter too much since for example in librewolf's case one of the only pieces information that a website is able to gather is the user agent string witch will just report that the browser is a very recent version of firefox and that combined with the website being able to understand that the browser supports JXL means the website can make the guess that the person visiting is using librewolf (if JXL support was on by default)

the only reason I bring this all up is just to show a reason why a fork like librewolf might say no to JXL support being flipped on by default

however maybe I'm thinking *wayy* too much about all this because librewolf did accept a pull request that made it so the option to turn on JXL support actually worked instead of doing nothing

which means they atleast accept that some users might want to turn on support even though the users of librewolf are using it for full privacy

yeah maybe I might be thinking way too much about all of this I should probably get some rest.

main reason I was even thinking/worrying about this is I guess to prepare myself in the case of some forks saying "no" to JXL support being enabled by default

It’s a real problem with GPL because it’s a “viral” license. The moment you introduce GPL code into a project, the whole thing becomes GPL too. A lot of people don’t want to take that risk.

unless your fork is really identical to what you're forking from, I think you have to assume that there will be _something_ that makes it possible to know what browser is being used, even if it's not by just looking at the UA string or client hints.

yes, which is why libjxl uses a much more permissive license (BSD-3), so proprietary software can integrate it too (technically LGPL would possibly be enough for that but that still smells like GPL so corporate lawyers prefer something unambiguously permissive)

Sounds like a good idea to keep around patches for chromium that can then be used for chromium derived browsers. At least a minimal amount of maintenance would be required for that. For example right now highway is updated inside chrome (it still is in chrome because there was another dependency needing it), so this means some adaptions when building with a patch for jxl support would be needed. Of course many of the files of a JPEG XL patch would be related to testing, but it should be trivial to split it up into two patches: one for basic functionality and one for all the testing. I will try to build a current version of chrome with jxl after the highway stuff has landed https://chromium-review.googlesource.com/c/chromium/src/+/4223354

Shall I go ahead and create a new repo in the libjxl github org for this? Seems best not to clutter the libjxl/libjxl repo itself with this, but it's of course related enough to put it under the same org

Unsure, but let's definitely not clutter the libjxl repo. Perhaps it would be easiest to have the code on the chromium gerrit, because this way we can use the testing infrastructure and it would be convenient to simply keep rebasing continously

yes but can we just put stuff there without needing approval from the folks who removed jxl in the first place?

yes, I think I can put stuff there, I think there is little restriction what can be put as WIP

then I suppose for the chromium-forks integration that would be a good place to put it. For the firefox-forks integration it doesn't make much sense to put it there though — can the existing firefox infrastructure be used for that?

Probably? Isn't that where it is currently at?

As far as I understand, there is some partial jxl integration code in firefox, then there are some old pending patches to fix stuff that currently have merge conflicts, and then the various forks (pale moon, basilisk, waterfox and librewolf) took those patches and made it work.

https://nicolas-hoizey.com/notes/

Keep in mind that taking code from Pale Moon is risky: https://old.reddit.com/r/palemoon/comments/pexate/pale_moon_developers_abuse_mozilla_public_license/

for JXL support the only relevant browser that would have to use code from palemoon/UXP is waterfox classic and waterfox classic has used work and code from palemoon/UXP in the past from what I remember, also while that is a hairy situation waterfox classic does not seem to be under risk as much as the project(s) listed in that post

waterfox classic already has palemoon/UXP code in it so porting over the JXL support would not change the state of anything except the code that was made for backporting JXL being by a different contributor then the other code that waterfox classic has inherited

Is there any jxl code in pale moon that was not already submitted as a patch to firefox?

no there isn't. all the code in palemoon for jxl support is backported

palemoon/UXP is based on firefox 52 while waterfox classic is based on firefox 56 so waterfox classic would have to use the backported code from palemoon

normal waterfox is fine though

Libjxl itself in any case is not a problem, license-wise. I think it would be a bit silly if the integration code would create license issues - not saying that that code is completely trivial, but it would still feel strange to me if someone would insist that the plumbing code would have a more restrictive license than the two things it is connecting...

either way waterfox classic should be fine since it already has inherited code from palemoon/uxp and the project(s) listed in that reddit post have a different relationship with how palemoon/uxp's code is used

On the community website, I didn't found the fact that extension to read jxl are available under Firefox (https://addons.mozilla.org/en-US/firefox/addon/jxl/) and chrome (https://chrome.google.com/webstore/detail/jpeg-xl-viewer/bkhdlfmkaenamnlbpdfplekldlnghchp). Could this be added?

Feel free to make a pull request on the website repo 🙂

it would be neat if that extension had a context menu item if you right clicked on a jxl image to save the original jxl file since that extension has to internally convert jxls into pngs (or atleast some kind of canvas element that lets you save it as a png) for the browser to be able to display jxl images

not sure how hard that would be to do though might be quite tough

also sadly color profile management and animations don't work with it currently

i will ! i wanted to confirm i didnt miss it 😁

We'll need to keep those pages up to date as things are evolving. E.g. at this point it would be good to add a list of browsers with jxl enabled by default. Thorium isn't mentioned anywhere yet...

the project lead for thorium has still not made a statement yet so it would be best to wait first before adding thorium to the list

Well at the moment it has jxl enabled by default, while my company-administered auto-updating Chrome has no way anymore to get jxl support.

Maybe open an issue so that I don’t end up forgetting? 😄

https://phabricator.services.mozilla.com/D119700#3977128

So this is old, 2021, and a very strangely worded message. It's this one's job to review pull requests and merge them, but instead of doing that, which could take 5 minutes to do, this strangely worded reply was typed instead.

As if it's someone else's decision

Personally I'm not sure what to make of this, other than the fact that mozilla or someone within mozilla decided back in 2021 that JXL patches should not be merged because for some reason that would compete with AVIF somehow.

Patches that fix extremely basic and fundamental bugs and missing features within the already-existing JXL implementation within firefox.

funny thing is that comment is by someone who created the WIC codec for JXL and also keeps updating libjxl in firefox's repo

also mozilla seems like they are sorta struggling when it comes to developer resources

not surprising tbh

I went here to look at other build scripts or rebranded versions of firefox with all the mozilla fail whale removed: https://wiki.archlinux.org/title/List_of_applications#Gecko-based

Never heard of Dot before.

https://github.com/ungoogled-software/ungoogled-chromium/issues/new?template=feature_request.yml

Would it be worth trying to get ungoogled chromium to support JXL?

Sure. Didn’t notice

https://lr.slipfox.xyz/r/vivaldibrowser/comments/zjz1do/jpeg_xl_support/

<@171381182640947200> for some reason the firefox extension is going absolutely nuts in IRCCloud and leading to massive memory and CPU usage

It seems to cause firefox to send endless GET requests over and over again asking for avatars and writing endless errors to the console.

What errors do you get in the console? Could you open an issue with a bit more detail? I might be able to investigate it later today or this week and release a new version.

made a pull request for librewolf to improve it's jxl support https://gitlab.com/librewolf-community/browser/source/-/merge_requests/53

if it does end up being a problem then atleast the patches to enable it by default and to improve support are separate

Make it report by default that it doesn't support JXL images 🙂

Basically, enable JXL image support by default, but until other bigger browsers have it, don't advertise it 🙂

tbh, I hadn't really taken that into consideration, so I wouldn't really have a response, but either what username or BlueSwordM said could work, preferably the latter one

in the librewolf pull request that removed the jxl nighty check the person who made it suggested that it could be enabled by default however there was no response to that

maybe just wait and see if the librewolf devs come to fingerprinting conclusions on their own and then respond to them when that happens?

if they do then the pull request could be reduced to just the improving patch

That will also not make it work for e.g. shopify websites, since they will then just get the fallback jpeg/webp

think they mean don't advertise as in don't say it on the website not don't advertise support to websites in the browser

I can troubleshoot it again later, if I recall correctly the console was pointing to this line? https://github.com/zamfofex/jxl-crx/blob/main/worker.js#L27

What Jon said: Not advertising to the website that the browser supports JXL image. Having partial JXL support(opening JXL images in a file explorer) rather than none is better than nothing 🙂

that would require extra code and also make it so if someone wanted to then they couldn't make the browser advertise support to websites

soo that's unlikely to happen

especially since I don't see them writing code for that

The fingerprint footprint effect of new format support is quite minimal imo. I think it's more of a theoretical concern than a real thing. Was this issue raised when other formats like webp and avif were added? Or new video codecs etc?

well thing is webp and avif where added to major browsers of which are less privacy focused and also librewolf says to websites "I am a recent version of firefox"

Capability signaling is a quite essential aspect of http. There are bigger privacy/fingerprinting fish to fry than this, imo.

For avoiding fingerprinting, it should be saying it is chrome, since that's the lowest entropy value for that field

thing is websites could try to look for firefox vs chrome specific differences and if it detects firefox with a chrome agent string then that's a problem

<picture> tag works regardless of http accept headers right?

In fact isn't <picture> better in every way? It makes no difference for fingerprinting however.

I personally believe including JXL support flipped on by default is not that much of a privacy concern however you need to think in the mind space of someone who is very very very privacy focused as that seems to be what librewolf is targeting

which image the browser chooses from a <picture> element is fingerprintable entropy

yes but image cdns (including shopify, cloudinary etc) tend to use http content negotiation, not picture tags. Picture tags require changing html every time a new format gets added

and in any case the server will know which of the images was fetched

Yep

So therefore it's impossible and pointless to guard against fingerprinting

for this reason

well some kinds of fingerprinting like blabbing on every request what exact linux version and cpu model you have can of course be avoided, and this has been done already

i imagine they would probably want to keep it off by default in that case

I think you have to assume that there will be a way to figure out what browser the client is using — unless you're absolutely identical to another browser in all observable ways, but then why did you fork in the first place? for a nicer UI skin?

web standards are not designed for privacy or security and the idiotic assumption that javascript should be enabled by default is the biggest mistake. If fingerprinting is a real problem then people should rethink how a web browser is supposed to act

And what a web site is

speaking of shopify it seems like if a browser supports JXL but not AVIF then it will fallback to jpeg and webp

found it out when testing what would happen if I disabled AVIF support in waterfox but kept JXL on

and I know it's a shopify issue because other websites work fine

Could be their logic has a bug there, since that is not something any browser does

How do I disable webp support...

I'm going to try setting image.webp.enabled=false

yep, firefox

well, that's all that needs

That feels like a fairly straightforward way to have Discord thumbnails cease working. 😅

Yeah, everything is broken

discord is completely broken with no fallback.

Everything is just a gray circle

Well that's annoying that webp is such an awful format but websites are already depending on it with no fallback...

Honestly other browsers held out for a long time but they eventually caved when google intentionally broke youtube

They let themselves be manipulated so easily by Google

and it's an objectively worthless format that has no reason to exist in its current state. Many people offered suggested ways to improve the format but Google just kept it the way it was

And expected everyone to adopt the half-baked format as is

webp has a lossless mode that is better then png however webp has so many limitations that png doesn't have such as the resolution limit and also being limited to only 8-bit

It feels really strange to claim it’s “objectively worthless” (or to claim any of your opinions as “objective”). In this case because I think there are legitimate situations in which WebP does better than PNG. (If it were strictly worse, no‐one would use it, regardless of Google’s incentives towards it.)

I don't think youtube broke, it still works on browsers without webp (though it does have a weird way to do it, which breaks when you manually disable webp in chrome)

lossless webp is certainly better than png within its limitations

I haven't looked to far into jpeg vs webp however webp has forced chroma subsampling which is a shame however webp does an extra dct block size it can pick from when encoding so if there was an equivalent to mozjpeg for webp then webp could have better results however i'm not really an expert on the limits of the webp spec compared to the jpeg spec

and it has a pretty well-oiled encoder that gets good speed/compression trade-offs

for lossy, webp is pretty much garbage

before mozjpeg, it did have some advantage over jpeg

I mean the objective qualities of the format, like the lack of features and general huge oversights in the design.

now, I think lossy webp only has a very narrow and inconsistent advantage over jpeg at the low quality end

lossless webp is cool but it's tied down to this clown format

and it effectively cannot do the range of qualities needed for the high end of the web, let alone for use cases like photography or printing, where its obligatory 4:2:0, limited dimensions, no cmyk support etc are just making it unsuitable

with avif available, lossy webp is completely obsolete imo

this is sorta related but I am excited for jpegli and have to ask what is the current state of it? <@794205442175402004>

i'm not really involved in jpegli at all, <@987371399867945100> is doing most of the work there

I see. I have been wanting to mess around with it but there seem to be no compiled binaries around for it

jpegli is pretty workable via benchmark_xl

I didn't know jpegli was connected up to benchmark_xl I was under the impression that benchmark_xl still might have had the old xyb jpeg functionality

I do need assistance with using it however though since I suck at command line......

does it still work the same way it did back when before it was called jpegli?

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

it's fully functional (for non-xyb, yuv420, ...) depending on the encoding options

and https://discord.com/channels/794206087879852103/1020724883241574472/1065718302573338655

it just fails...

this is bringing me back to when xyb jpeg was first a thing and trying to create one flat out didn't work so I gave up

ill continue in <#1020724883241574472>

It's going to be really funny seeing ancient JPEG start competing with modern codecs

Does the psy tuning benefit both jpegli and libjxl?

JPEG has always been a fairly good and well‐made format that is still competitive today! This is a fairly interesting video comparing different formats for a limited set of metrics: <https://youtu.be/-7k3H2GxE5E> (Also see this comment, which I felt was fairly interesting/amusing.)

why is the middleout flag more well known than modular lol

I mean, the other way around

why ISN'T it

Welcome to Windows. this error has been going on for more than a year. And I do not know why No One of the JXL developers does not fix it.

I can't just take and create a Jpeg XL block scheme on windows ```benchmark_xl.exe --input=12.png --codec=jxl:7:1.0 --debug_image_dir=. benchmark_xl.cc:144: JXL_CHECK: speed_stats.GetSummary(&summary)```

The only explanation is that none of the developers use Windows at all

the workaround posted in <#1020724883241574472> of using ECT worked for me https://github.com/fhanau/Efficient-Compression-Tool

for the first time I see this software, it looks like micro ffmpeg, but where is XYB actually?

the workaround is to put a png source into ECT and then use the ECT png

I do not understand

png file goes into ECT and ECT outputs a png file then you use that png file with benchmark_xl

🙂

doesn't that mean I can use guetzli to create jpeg

iirc guetzli is a JPEG decoder

yes. I know that...

Guetzli is a jpeg encoder. I don't think it has a decoder too

I can take a PNG in XYB format, convert it to YUV to compress it Guetzli, and attach to the output file that it is actually XYB?

knusperli is a decoder

yes, it's true 6 kb

Okay, I'll do it through a crutch

what was the one that decodes jpegs in a higher-quality manner but still compliant?

https://discord.com/channels/794206087879852103/803574970180829194/1075012936327761962 <https://github.com/google/knusperli>

ah ty

but I guess jpegli is already better as an encoder and decoder (and much faster)

The Android version of Telegram supports XYB JPEG when sending a file!!!

Why does Windows give return codes in hex instead of decimal?

So, you're saying Telegram supports JPEG?

you missed one word before the word JPEG

I'm pretty sure DZgas is saying that XYB jpeg works properly, i.e. properly color managed including ICCv4 profiles.

which is not a given just by supporting JPEG

Heh, so I suspected. It's nice that it's properly color managed. I wonder what software discord is using to resize images

whatever chromium uses

since it's just chromium

that's not what it does

discord has a server side thumbnailer

ye, but in the client it uses whatever chromium uses

if you mean what it uses to downscale for its server-side thumbnailer? no idea lol

chromium has had color management support for a long time

yea, it does

scaling in the discord client works fine

it's the server-side thumbnailer that doesn't preserve colors

yeah I know

that's why I asked, I wonder what software they're using that doesn't support iccv4

or any color profiles whatsoever actually

and i do https://discord.com/channels/794206087879852103/1020724883241574472/1075037766859116575

Their server side downscaler must be something that just ignores colorspace and assumes everything is sRGB. I don't know what retarded backend software they're using for that, none of the usual image libraries will let you do that easily, but maybe they're just doing something silly, something like this: ``` # strips all metadata, good for privacy! convert input.jpg tmp.ppm # downscale and compress convert tmp.ppm -resize 300x300 -quality 70 thumbnail.jpg ```

You'd be surprised how many "image processing backends" are actually just some hacky scripts like that

https://discord.com/blog/how-discord-resizes-150-million-images-every-day-with-go-and-c

<https://github.com/uploadcare/pillow-simd> <https://github.com/discord/lilliput>

```Ultimately this isn't really an issue of color management as this library isn't doing any work in color space. Lilliput removes all metadata, but there is an argument to be made for keeping some of it. For now, the library does what it is intended to do, and it's possible to use another library to apply whatever APP data you want afterwards. Since the vast majority of JPEGs don't contain this information, I don't see this as being very high priority.``` https://github.com/discord/lilliput/issues/40

heh my `# strips all metadata, good for privacy!` comment was spot on

it's frustrating when people who clearly know or care little about images make image processing software

> Some image containers do better at ICC than others. With JPEG, I don't see how you can maintain ICC information without getting into EXIF. 🤨

by putting it in the app marker that has been assigned to that function?

yeah, the guy is clearly just confused/incompetent, and it's a bit sad

I added jpeg support to benchmark_xl (before we made it an extra/ codec) ~4 years ago having no idea what I was doing and I was still able to read and write ICC profiles properly (commit d036785a7 in the previous gitlab repo)

“unify codec_jpg and codec_jpeg” we have some “interesting” history in there 😂

2 jpeg decoders?

sjpeg, libjpeg, and then our own jpeg decoder for jpeg recompression

codec_jpeg being the latter

reading the DCT8 coefficients without converting them to pixels

> none of the usual image libraries Sadly, libGD is quite widely used (eg. WordPress?): https://github.com/libgd/libgd/issues/136

yeah I guess there's still plenty of stuff that just ignores colorspace info

which to be fair was kind of a reasonable thing to do 20 years ago, when basically all screens were SDR with sRGB gamut anyway so there was little reason to deal with all the complexities of color management: just use only sRGB unless you know what you're doing and use proper tools.

today though, I think it's completely unreasonable. So many screens can do wider gamuts and/or HDR now, and it's madness to expect all images to be just sRGB

Stripping all metadata without doing anything is definitely wrong. But stripping metadata and converting it to sRGB on upload can just magically remove a lot of user complains about images not working (due to broken color profile support on browsers and apps), so site devs just normalize all images to one most supported profile (sRGB). YouTube also wouldn't let you upload arbitrary videos, it always re-encoded, so it's something like that, only for images.

(Perhaps use complaints would push browsers/platforms to fix colour management...)

Hopefully the advent of HDR would push things forward

I don't think anyone has because it's just not in a easily useable state

here's my hot take. color profile should not be considered metadata anymore, but part of the bitstream, since it's required for opening the image fully.

I'm sick and tired of people waving off profiles as "it's just metadata" in the same vein that some people treat the theory of evolution as "just a theory" without actually understanding what it entails.

I know this is just a semantic argument, but the objective is to bring to light the point that an image cannot be actually opened if the profile it came with isn't there.

afaik XYB JPEGs are only possible with v4 profiles

Color profiles are considered metadata though 🙂

Remember, there's external metadata, and then bitstream metadata 🙂

Color profiles should indeed become bitstream metadata and only editable by bistream filters IMO.

I did imply that so I'm not sure what you meant to mean?

this is roughly what I mean. color profiles should be first class citizen in the same vein as declaring resolution and bitdepth.

That's exactly what we did in jxl

It's part of the codestream, right after the header fields for image dimensions and bitdepth

Yes and I like that... but I meant universally

I'm talking about programs and software refusing to address profiles as a non-negotiable part of the picture

That may be true for sRGB vs P3 vs Adobe RGB 1998, where it's mostly just a difference in saturation and average users might not care much about that.

when I exported a photo as Adobe RGB without realising it, and a website dropped the profile, the visual difference was quite dramatic

it affects R, G and B differently, so it looks quite weird

yeah it's quite a big difference, but if you don't know what the image is supposed to look like, it can still look plausible, just with colors shifted a bit and desaturated quite a lot, but if you don't know how it's supposed to look, you can think that's just how the image is.

however when images are ProPhoto or Rec2020 you can't just ignore the profile without completely making the image look bad

for the most photo types you kinda know though

I think I found the image on which I saw it happen, and I tried to reproduce it, but the effect is less than I remembered

as sRGB:

exported as Adobe RGB then profile stripped:

The effect will be bigger when comparing an Adobe RGB image with one that is profile stripped and interpreted as sRGB

https://github.com/Alex313031/Thorium/issues/104#issuecomment-1430573061

Nice, Thorium lead dev confirming they'll keep jxl in Thorium post M109!

https://twitter.com/jonsneyers/status/1625899885982625792?t=MF9RbNOSQ_nvVGJL-piDwg&s=19

Doing my best to promote Thorium 🙂

<:CatSmile:805382488293244929> <:Stonks:806137886726553651>

Flatpak ksnip (screenshot application) can save .JXL images too. You just have to manually type .jxl instead of .png https://flathub.org/apps/details/org.ksnip.ksnip

So if firefox is literally the only web browser today that does not support v4 profiles why does xyb jpg seem to work in firefox

i recall (correctly or not) that in newest versions they actually enabled that

extended support releases definitely don't have that yet on the other hand

Hmm, for some reason I doubt it

Because I have all of the about:config flags enabled

See if this image works for you...

https://littlecms.com/img/blog/stress.jpg

it doesn't work.. even though I have that flag enabled

i mean that they did enable that flag in newest releases

but it's not implemented right?

or maybe it's "right" but different from chromium's impl in some way that ends up failing this

https://www.color.org/version4html.xalter this looks correct for example

this is a fake picture

Android Telegram v2 and v4 Desktop Telegram only v2

it actually displays "correctly" in thorium though..?

Do you have the source image?

No, this picture doesn't work.

nevermind, got it

https://www.mozilla.org/en-US/firefox/108.0/releasenotes/

It was enabled in Firefox 108

Archibald is wrong here

SSIMULACRA2 scores, with everything below 0 cut off

& here's with below 0, which is UNUSABLE quality

It is not a fake picture lol. What is actually truly "fake" is firefox's iccv4 support

Firefox is the only browser where it doesn't work

It even works in the default windows photo viewer AND in microsoft edge

microsoft edge is just chromium a interesting test would be to test legacy edge

ill do that right now

It works in every viewer with ICCv4 support including the default photo app in Windows

Firefox still does not actually have ICCv4 support

It is NOT a fake picture.

It does not.

Basically the enablev4 flag is just a lie

heres legacy edge (EdgeHTML)

What that flag actually does, is enable proper v2 support

```~ $ mvi 'https://www.littlecms.com/img/blog/stress.jpg' Auto-loading profile 'extension.jpg' (+) Video --vid=1 (mjpeg 640x400 1.000fps) VO: [gpu-next] 640x400 yuv444p [vo/gpu-next/libplacebo] Arithmetic error in ICC profile gamma estimation? Please open an issue [vo/gpu-next/libplacebo] Failed opening ICC profile... ignoring [detect_image] First image detected [detect_image] Image detected Exiting... (Quit)```

`gfx.color_management.enablev4 = true` enables proper v2 support, without that flag v2 support is broken.

It does nothing for v4 support.

epic fail