JPEG XL

arithmetic error in gamma estimation, that sounds pretty bad lol

https://twitter.com/giannimastodon/status/1626022158987149313?s=20

It looks like I didn't post the source for the test images. It's from the LittleCMS website

https://littlecms.com/blog/2020/09/09/browser-check/

https://www.color.org/version4html.xalter

How about this test page from *seemingly* the ICC website?

I'm on the latest Firefox (110.0) on Windows, with `gfx.color_management.enablev4` true by default, and this image doesn't work, but the color.org v4 test works fine. Weird.

Seems Firefox has incomplete ICCv4 support, then?

The CMS library used by Firefox (`qcms`) asserts if it tries to use `lcms`' image's ICC profile. At least one program that uses `skia`'s built-in CMS also seems to ignore this colour profile.

that lcms test is strange

claims to use clut, but chrome's clut is also wrong

see https://displaycal.net/icc-color-management-test/

Is it possible to have a similar file size as avif by losing fidelity/reducing noise before encoding with jxl?

you can also get similar file sizes by just using lower quality settings for cjxl

https://twitter.com/jonsneyers/status/1626131842335182849?s=20

jxl looks quite clearly better than avif also at such small filesizes

I guess lower effort settings don't use fancy stuffs, so maybe e3? I'm not sure if libjxl supports jxl to jpeg transcoding though

These kind of pixel-peeping comparisons at (slightly too) small filesizes are extremely useful IMHO. General disregard for fidelity at both high and low qualities is a problem. I personally prefer to see some artifacting if the image is closer to the original overall (for example obliteration of film grain is a huge loss to fidelity, atmosphere and truthfulness of an image).

Currently we have no real tooling for that, but maybe jpegli could eventually become the basis for this. Basically the idea is to use only dct8x8 and generally stay within the expressivity of jpeg, but use some "jxl-only enhancements" like gaborish and epf that are cheap to signal and make the jxl image a little better while the jpeg version still looks acceptable.

That image wasn't chosen to make jxl look good, it was chosen because of the image itself (mostly turquoise colors so fits with the 'official logo color' we have on the JPEG website, and it conveys some of the "perceptual" and "attention to detail" connotations we wanted to associate with jxl). We added a jxl variant because it seemed appropriate to do that (from a dogfooding point of view), and then we had the idea to also make it useful as a subtle browser support test (with the text overlay in the bottom right corner) and compression performance demo (the jxl being half the size of the jpeg and looking just as flawless). It was only because Jake mentioned it that I tried converting it to AVIF and comparing JXL and AVIF compression of that particular image. Fortunately it seems to be a clear case where jxl is just better 🙂

Well it renders just fine in image viewers that actually support ICCv4 instead of lying about it. So basically everything but Firefox.

Probably the lcms test exercises more v4 features and the color.org test uses mostly v2 features in the v4 profile

Maybe Firefox has a very skeletal implementation of v4 support that treats a v4 profile like a v2 profile.

And ignores v4 features that aren't in v2

I have not inspected the profiles in use on color.org but it seems to be a lot less informative test than LCMS

It does not say what specifically what features are being tested for example.

The only thing that enabling v4 support in Firefox seems to do is enable LUT, which is a v2 feature

While Firefox does have some form of ICCv4 support since 2010 (and it seems that it was improved over time), it does not support non-cube multidimensional LUTs used by that `lcms` image. For some reason the author of that blog post assumed that ICCv4 does not work at all, while in reality `qcms` simply does not support that particular artificially generated profile. Without ICCv4 support Firefox would not be able to display `jpegli`-compressed images correctly.

how can I use jpegli right now?

benchmark_xl --input=test.png --codec=jpeg:enc-jpegli:xyb:q93 --save_compressed --output_dir=./

<#1020724883241574472>

https://twitter.com/jaffathecake/status/1625902956284456968

what does "optimise for high-density displays" mean 🤔

this thing people were doing 10 years ago https://www.filamentgroup.com/lab/compressive-images.html 😨

probably high dpi displays?

but idk about the optimize part though

yeah but I mean like in practice. does it mean one massive image at low quality for all devices. or some thing with srcset and 2x etc. descriptions which is a pain to use in responsive design

There does not seem to be that many alternatives to LCMS

There's Argyll I think but it seems dead and doesn't support iccv4

the x-descriptor is was invented when mobile and desktop websites were a separate thing so I don't really see any reason why you would want to use it today when w-descriptor does the same thing but better

and qcms is also only used by firefox, and has zero development manpower

like the rest of firefox

It's their own in-house NIH color engine

does the iccv4 work even for basic use cases like srgb or adobe rgb? at least https://www.color.org/version4html.xalter shows correctly in firefox for me

i think both creating @2x/maybe @3x variants of images, and also using lower quality settings for those variants

cuz supposedly you don't notice as much

Firefox seems to have extremely basic, partial/broken iccv4 support

Enough to pass the color.org test but not enough to pass a more thorough stress test that uses more features of ICCv4

yeah, I guess it's a start so it works for the 80% use case

would be nice to get full iccv4 support, hopefully it won't take another 10 year or so...

Sad part is Firefox used to have perfect support when they used lcms but then they switched to their own, broken and non-functional, in-house NIH system

Also, Mac OS and Windows both have ICCv4 compliant color management libraries that Firefox could use instead of their own in-house qcms garbo

On those platforms Firefox ought to be using the built in OS-provided color management API

The default photo viewers on Mac and Windows have no problem with the ICCv4 stress test image.

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

Most software does

Try downloading and opening the above stress test image in various software.

Only firefox, and extremely minimalistic image viewers with no color profile support, fail to render the above image.

such as qimgv

Why does it seem like everyone but Google and Mozilla are excited about JXL? 🤔

And they were at first too until abruptly reversing course

Weird 🤔

mozilla didn't abruptly reverse course they didn't really seem to care about jxl that much at all and it seems like the only reason firefox got basic jxl support in the first place was so if chrome decided to flip on jxl support by default then mozilla would have a head start with getting their implementation done

I guess I could see that. They flat out refused to merge basic bug fix patches after all, that would have brought them at parity with Chrome support.

Some speculation: Chrome and Mozilla are heavily into AOM — which is by itself of course good, we all want royalty free codecs for the web. They somehow have the idea that they need to make AVIF succeed in order to make AOM succeed (I don't know why they think that, to me it seems like AV1 can be a big success also without AVIF) — so they fast-tracked AVIF support, not "experimental behind a flag" but just immediately ship, no questions asked. Then JXL came. Obviously it is a competitor for AVIF, and likely if all browsers would support JXL, it would significantly reduce the chances of AVIF getting traction. Chrome reluctantly allowed us to have jxl support behind a flag, but we never could get the flag enabled by default so it could never actually be used. I'm assuming they were hoping that AVIF would meanwhile get traction, and then JXL would just slowly disappear as nobody would really be interested in it since AVIF is in their minds "clearly better than JXL" (you saw their comparisons: it encodes faster, decodes faster, compresses better, basically it's better in everything except lossless, but who cares about lossless on the web). Meanwhile, <@239702523559018497> started implementing jxl support in firefox, but then as soon as Mozilla leadership saw that, they also blocked it getting enabled by default or making any further progress. Just like Chrome, they don't want to risk getting seen as 'detractors' within AOM by allowing a 'competitor' of AVIF to succeed. They fired all their codec experts (the Daala folks) back in the 2020 layoffs, so they don't have anyone left who can do a serious investigation of the actual technical merits of JXL (or AVIF for that matter), and they basically just believe what Chrome leadership is saying about it, and Chrome leadership gets their results from the AVIF team (which is part of the Chrome codec team).

I'm just speculating here, I don't work at Google nor at Mozilla so I am just guessing what to me would be the most plausible explanation. If my speculation is true (or close to true), it's a rather frustratingly silly mess of a situation...

It definitely did not have perfect ICCv4 support, in fact the `lcms` versions used by Firefox share the only-cube-CLUTs limitation with `qcms` . Makes sense, because `qcms` was a `lcms` rewrite. By the time `lcms` developers removed this limitation, `qcms` was being used for more that a year and `lcms` was gone form `mozilla-central`.

though all colour management support is disabled on firefox android for some reason

interesting!

https://people.csail.mit.edu/ericchan/hdr/hdr-jxl.php These beautiful images look way too dark in waterfox. Anyone tried it out in Chromium fork?

works a lot better in thorium

firefox is using the jxl extension, i cant test waterfox atm

and imageglass absolutely fails at it

https://twitter.com/alexjc/status/1626875879140753410?t=ls8GT_RFnvMSu6EvwXomZQ&s=19

CanIUse is saying edge 110 still has jxl support behind a flag, can someone verify that?

just checked edge, 110, jxl doesn't work, edge://flags no jxl

I also checked and edge does not have JXL support anymore

JXL never showed up on the flags page you always had to use a command line parameter to enable support

You have to start it with --enable-features=JXL

not sure but they did to the flags page to make it not show up however I believe it wasn't intentional

either way microsoft seems to be pretty unaware or just not care about JXL so it's not surprising that with the bump to chromium 110 support is just gone

in Opera it still works, but it is chromium 109

what version of opera is that? would be useful to know since me and a friend plan on archiving as many chromium forks as we can that are on chromium 108 (short term LTS) or 109

Is thorium available for Android? 🤔

"Opera 95 was released on February 1, 2023, based on Chromium 109" https://en.wikipedia.org/wiki/History_of_the_Opera_web_browser

Does not work in Edge 110 and Edge 112.

If you are willing to waive Chrome, Firefox supports extensions on Android, I’m pretty sure.

only very few extensions are supported.

did they change anything recently?

No, it's still the same "install Nightly, create account, create collection, do million other things, then you'll have installed android extension (if you're lucky and relevant API is implemented)" process. The only thing changed is that they now allow Beta channel to install them.

but I couldn't install your extensions on the mobile version of firefox... don't know why, it is not even listed on the add-on page

Mozilla limited what addons can be installed on mobile Firefox at some point (and removed about:config)

Right now, Bromite hasn't been updated since v108, so it still supports JXL behind a flag

i use firefox nightly for the primative jxl support and ublock origin

when did they supposedly do this?

unless it's only available on nightly or something

Idk I am just parroting what I read here

I remember reading the same thing at some point

well i used about:config on android firefox nightly to turn on jxl, so it's probably on that one only

I'll try nightly. Indeed, in the standard version, add-ons are scarce (perhaps 5% of the store is available) and the about config url return a blank page

I just tried edge with --enable-features=JXL and it does not seem to work

But I never tried it before when it did supposedly work

because... why would I want to use edge...

ew... gross.

that kind of message is the reason why bing ai wants to kill all humans

I wonder what the AI thinks if you ask it about other browsers

Also, what exactly is so "open" about openAI and the censorship harness they use to oversee and restrict their AI?

I don't think there's anything open about openAI

"open" is to the tech industry what "bio" is to the agro industry: it's a very nice thing but companies tend to use it mostly as a marketing label and will do everything to erode the term of all real meaning so they can get the positive vibes without actually changing much at all in the way they do business

If I remembered correctly at start they were open source or they had open access to docs and other things. But as time progressed and they were successful Microsoft and other companies pumped money into them and they started closing everything "open" and now they are basically another company.

What's the best Android browser for use with JXL? Using FF Nightly rn

I do not know where to be so that there is a jxl that needs to be viewed on android. Yes FF

https://github.com/Alex313031/Thorium/issues/111

^right here

Thorium reversal of JXL removal seems successful: https://github.com/Alex313031/Thorium/issues/104

they do seem to have got a compiled build working! however it seems like they are having certain compiling issues seemly as a result of them attempting to update libjxl from 0.7.0RC to 0.8.1

which is something I recommended they do however I thought there wouldn't be any compiling issues

https://github.com/Alex313031/Thorium/issues/111

https://github.com/bromite/bromite/issues/2574

bromite will automatically close any issue unrelated to privacy with a bot :P

"I haven't read the full thread but I just want to voice my opinion that chrome's experimental JPEG XL support has been the *only* way for me to properly view HDR images edited and exported in Adobe Camera Raw (see https://helpx.adobe.com/in/camera-raw/using/hdr-output.html). As a user (and web developer) I do not understand and agree with the motivation for removing the support and I really think this format has great potential and should be supported in chrome (or something better so I can look at my HDR images but this was the best there was)." - https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c390

Haven’t these questions been answered time and time again though?

https://github.com/Alex313031/Mercury/issues/6 Mercury, a Firefox fork from the same person that made Thorium. I just opened a feature request to enable JXL support OOTB.

Sure. I'll approach this tomorrow

Has anyone opened any issues for Signal's image format support?

I’ll do it tomorrow in a more well thought out manner than the Bromite one

The more I think about it, the less I think Bromite is worth bothering, as the app hasn’t been updated since chromium 108

How about explaining that "the guy who's responsible for forcing webp down peoples' throats with no debate is the same guy unilaterally removing JXL support without addressing the concerns of facebook, shopify, adobe, etc who all asked for it to be enabled by default. And the only explanation he gives is that AVIF, his latest project, is supposedly so great and amazing that there is no need for any other format to be allowed to compete with his precious baby."

I'll respond with this, verbatim :D

Despite literally everyone else saying otherwise

His assistant publishing a comparison claiming that jxl is slower than the infamously slow avif, despite literally everyone's actual experience with both formats clearly demonstrating otherwise.

Their own graphs demonstrating that avif is losing by a substantial margin at the most common bitrates.

Yet those graphs are only shown if you click through the links. All the graphs on the front page are showing preposterously contrived cases where AVIF wins if you cook the numbers by averaging in meaningless data.

But lol I can continue forever with this and it's TMI at this point. Really all that needs to be said is this guy is clearly fighting for his own legacy and ego or something

And completely not responding to anything anyone else has asked or said.

All he talks about is AVIF and how good or "sufficient" it supposedly is

Never explaining what JXL would need to change

just "oh my god my AVIF is so good, oh yes give me AVIF right there honey just like that oh god yes"

Uh sir we're trying to ask you about JXL, can you please pull your pants up and tell us what we need to change to make it accep- "Oh god my AVIF is so amazing! Put your AVIF right there! Yes! Yes!"

lol I better stop before I get myself into trouble though.

:)

<:kekw:808717074305122316>

https://github.com/signalapp/Signal-Desktop/issues/6312

done. fingers crossed

Read my issue - it works on Android, but not on the desktop client

That's why I was able to list it as a bug report

Just updated Opera to 96 and JXL stopped working :/

https://github.com/Alex313031/thorium-libjxl

https://github.com/Alex313031/Mercury/issues/6#issuecomment-1449215125

Looking good!

I should probably comment about the unmerged jxl patches for firefox

No linooox version? 😔

I would like to interject for a moment. What you are referring to as linooox is, in fact, loonix.

Or as I like to refer to it, Guhnoo Slash systemdbus.

https://github.com/Alex313031/Thorium/releases/tag/M110.0.5481.178

Nice to see a M110 with JXL enabled by default — almost feels like entering a parallel universe where the bad decision didn't happen and a good decision was made instead 🙂

<@853026420792360980> Is the new ffmpeg able to play JXL animations? The Telegram Desktop is not playing animated JXL so I am thinking if upgrading ffmpeg would help there. On Windows they use following commit in Telegram now: https://github.com/FFmpeg/FFmpeg/commit/cc33e73618

JXL on Telegram could certainly do with some polish. Naturally if you upload a file and let it 'compress', then it generates a jpeg with worse quality and bpp. Uploading as a file will let you download and then view the image in-app on desktop, but on mobile it will just show a preview and try to load the device's gallery app instead of telegram's in-app viewer. It recognises animated jxl files, will render the first frame and label it as a 'gif', but upon re-selecting the channel the image fails to load at all and shows a play button over empty space, loading the first frame instead as a static image once it's clicked. I probably didn't need to type any of this, but I thought it'd be handy to have the current state of things written down

... since many technological breakthrough came from porn, does someone ever tried to convince a porn hosting website to push jpegxl ? just asking 😄

Unironically, I think the main issue there is that most of it is either videos nowadays or booru's where the original file is always best. A test image set for another day :P

atm no. the nature of the JXL file format makes this difficult. I am planning on adding support but don't expect a merge any time soon

just sent a patch to the ML to add support it, but knowing the review process it'll take some time to get merged

The original file? You mean like a JPEG or PNG that can be losslessly compressed?

And save terabytes of space for those image boards?

People don't like to think about it but, porn is probably the #1 use for image formats.

So if JXL proves itself useful in compressing the sexy then it will be unstoppable

No one will be able to do anything about it, especially since it's basically the only format capable of losslessly compressing all of the existing JPG and PNG waifu comics

If it becomes popular on imageboards for its ability to losslessly compress everyone's waifu then no one will be able to unseat it, not even the Chrome codec team

So true. I've already encoded all my PNG doujinshi into JXL and use Tachiyomi to view it

Fair point, I suppose with a format around that's *actually* lossless, suddenly 'original' gets a lot more vague

That's... actually a pretty good idea. I don't know how one would approach that, though.

As in, how do we convince them to use JXL (especially without browser support)?

probably as a server side thing if theres no browser support

aka the server sends jxl files and the client has some form of wasm or js to handle it

Well you can just write some patches, a lot of image boards use open source software... Install it on a test server and write some patches to add JXL support and test it out and see if uploading works as expected, viewing, image previewing etc...

Often there are a whole bunch of different sized versions of the same file for thumbnail etc to save bandwidth, maybe JXL's progressive and LQIP features could come in handy there.

I know JXL contains a table of contents at the beginning of the file, although I'm not very familiar with how the server and client could possibly signal how much of the file to partially download or send.

I'm not sure how that sort of signalling works in HTTP

When it comes to partial downloads, I guess there are a lot of questions about how it should be done, whether it should be the client or the server that determines what to send... probably the server since that's what's currently happening.

It definitely needs to become more convenient for programmers to work with partial JXL files

currently there is no api at all for dealing with that

but it would be a pretty nice thing to get rid of multiple size encodings of the same image

My thought was have the server stop sending data after x KB are sent for example. After looking at some docs, it seems like http supports requesting and sending partial data already for streaming video, download pausing and such. So it should definitely be possible

In https://invent.kde.org/maui/pix/-/issues/14#note_600026 I explained what I did to enable AVIF and JXL support in the app.

Looks like someone finally had the same idea with progressive jpeg in 2019, although it doesn't seem to work nearly as well as JXL could https://github.com/McSodbrenner/embedded-image-preview http://embedded-image-preview.cerdmann.com/prototype/

for some reason cerdman.com is in the oisd blacklist that I use

Can the chroma channels use modular while the Y channel uses DCT?

Having watched the clip in <#822105409312653333>, sending partial progressive files instead of generating dozens of thumbnail sizes suddenly seems like a much bigger selling point than I thought. Save on storage and transfer like we've been saying, but also overall processing and power too. Lossless progressive doesn't always seem the best idea though, it made this test file I just rendered over a quarter larger (I'm probably getting outside the scope of this channel now)

Progressive and lossless doesn't mix very well. Lossless coding tools like (local) palette and lz77 inherently cannot really be combined with progressive.

<@794205442175402004> I'm here for a few weeks and I noticed that you answer here a lot a questions about some general technical stuff but the answers often disappears in the oblivion of discord, could a quick "hobbyist encoder FAQ" be created, one that could be pinned on reddit or hosted somewhere else, and which could be an answer to : what kind of settings should be best for photographies, manga, drawings, pixel art, screenshots, etc. What are in a few words the difference between modular and and varDCT, can I use both, what are they best suited for ? What are the impacts of lossless or lossy on the selected algorithm and the final result ? What the link between distance and quality or effort etc 😄

I could start to compile a short list of question seen a lot... But I don't know what would be the best place to host the answers

some answers are already in the --help though

Sounds like something that could be put on jpegxl.info

sounds nice, I'll open a google doc to draft this and then I would try to list some questions and fetch some answers to start (digging the history of these chats)

I guess the thing there would be to use the WASM jxl decoder implementation. The main drawback is that you have to load ~300KB of JS/wasm, but for an image board would quickly save more than that on the images themselves.

I just realized that the GPL in (https://github.com/Alex313031/thorium-libjxl) might make it more difficult for other Chromium forks to add in libjxl support based on the license...

it seems like this has already been a concern as on the discussion page for ungoogled chromium the license for thorium was brought up.

Didn't it mix fairly well with FLIF and MANIAC?

For doujins I guess cbz/cbr viewer support is needed (both on desktop and mobile comic viewer apps)

For online galleries, the wasm polyfill should be good enough, 300kb loaded for hours of scrolling might be an acceptable tradeoff

If the polyfill could be hosted on a cdn, it could be downloaded once for all (or almost) with some http cache-control

Cbz/r make little sense with jpegxl, just a tar archive of the files should be enough 😅

For nonphoto images, not really, non-interlaced flif could also be better than interlaced. But the gap was smaller because 1) flif doesn't do lz77, 2) flif's 'progression' is nearest-neighbor, not actual downscales, which makes the previews worse (aliasing artifacts) but does make it possible to mix palette and progressive, 3) flif's compression when doing interlacing comes from being able to predict from 7 of the 8 neighboring pixels. But it comes at a cost in complexity / memory locality, so flif's decode speed is a bit of an issue.

That is basically what a CBZ is. It is just a zip file (usually uncompressed) sometimes with a metadata `ComicInfo.xml` file as well. ZIP is important here, as it allows independent file access.

^ no index in tar makes ZIP more attractive here

Tachiyomi at least supports JXL within CBZ, which is nice.

My bad, I thought tar files were indexed.... Cbz then 😁

aliasing artifacts are not so bad, it preserves high frequency texture information (a bit too well) :)

Yeah it can be fine in some cases, but in some cases it can be very bad. For a preview it's ok, but for an actual 1:2 or 1:4 downscaled version of the image, it's too crude...

I don't know if this has been mentioned here before but Shopify supports and uses jxl as a part of it's automatic CDN and it seems to make small to medium sized images jxl files

and this goes for all sites made using Shopify

heres a good example of one https://www.tentree.ca/pages/about

^ almost all of the images on that site are jxl due to their small resolutions

something that has to be noted though is Shopify will only send jxl files if the browser also supports avif

so that means browsers like palemoon and basilisk will not see jxl files as they do not support avif

weird

How about Thorium?

should work in theory

Hmmm

Wait you made a pdf with a jxl payload?

Since when is that a thing?

I’d imagine it’s just a JPEG of the JPEG XL logo to test XYB support.

Ah, an xyb icc profile test

PDF with actual jxl payload will also be nice, will take a while before that will work though.

Well most of the image viewers I've tried have proper iccv4 color profile support

Like the default viewers on Windows and Mac

from what I can find, ICCv4 support was only added in PDF 1.7

so it’s relatively recent

and maybe Adobe Reader requires the PDF to actually be marked as being 1.7?

does it work better then?

nope, no difference

`file` reports that pdf as version 1.3

In Chrome with JXL enabled (when it worked) I've never gotten a Shopify page to show JXL files. Is this worldwide or limited to some regions?

https://github.com/libjxl/libjxl/issues/1832

when I go to a random shopify page, I see the behavior described in that issue: for small images they use jxl, for larger ones they use webp

it's not illogical: doing it with some pixel size cap means they can start deploying jxl without paying much extra cpu and storage

as long as only a small fraction of clients support jxl, deploying jxl at full scale is from an economics pov not very wise

it's cool that they even tried it in the first place, though

PhotoQt 3.1 on Linux (not on Windows yet) is now able to show EXIF metadata in JXL files. Metadata is parsed via Exiv2 library. https://photoqt.org/news/photoqt-3.1

does it also work for brotli-compressed metadata?

Usually no, because released Exiv2 0.27.6 doesn't support it yet. But in main branch, they already have EXIV2_ENABLE_BROTLI option. So in the future it will work.

cool, just a matter of time then for support to percolate then

only some images on shopify sites are jxl files such as small to medium images while larger images are always webp with some small logo images being png

the site I sent as an example has almost all jxl images

since almost all the images on that site fit the criteria to be jxl and or avif images with shopify's automatic system

Dolphin uses kfilemetadata. If you wish, you can add new extractor there which uses libjxl directly, and the JXL metada will be complete in dolphin.

jxl bare codestreams don't have any EXIF data so this is outside the scope of exiv2 tbh

if I read the issue https://github.com/Exiv2/exiv2/issues/1503 it seemed like they wanted to read image size at least, even for a bare codestream

For other formats Exiv2 prints image dimensions even in situation that EXIF is missing.

They need someone like <@853026420792360980> who knows how to parse JxlBasicInfo from the codestream.

for just width and height you only need to read like 8 bytes at most iirc

I lied, 11 bytes at most

it's not particularly hard, here's some pseudocode

``` signature = read 16 bits; if (signature != 0x0AFF) return "not a JXL"; div8 = read 1 bit; if (div8) { height = (1 + (read 5 bits)) * 8; } else { ctrl = read 2 bits; switch (ctrl) { case 0: height = 1 + read 9 bits; break; case 1: height = 1 + read 13 bits; break; case 2: height = 1 + read 18 bits; break; case 3: height = 1 + read 30 bits; break; } } ratio = read 3 bits; if (ratio != 0) { switch (ratio) { case 1: width = height; break; case 2: width = height * 12 / 10; break; case 3: width = height * 4 / 3; break; case 4: width = height * 3 / 2; break; case 5: width = height * 16 / 9; break; case 6: width = height * 5 / 4; break; case 7: width = height * 2; break; } return (width, height); } if (div8) { width = (1 + (read 5 bits)) * 8; } else { ctrl = read 2 bits; switch (ctrl) { case 0: width = 1 + read 9 bits; break; case 1: width = 1 + read 13 bits; break; case 2: width = 1 + read 18 bits; break; case 3: width = 1 + read 30 bits; break; } } return (width, height); ```

Assuming they want lossy compression, -e 4 currently gives the best filesize in most cases at very good speed. If they want lossless then it's just a case of picking what balances best, or sticking with WebP. If it's jpeg source files, then the re-compression usually takes a second at most for me even at -e 9. Probably worth mentioning that many sites still reference or use old versions of libjxl, so that could be a factor too

luckily, it appears the size header always fits into 9 bytes

but not 8

specifically it's always at most 68 bits

so there's very little that has to be read

84 bits if you include the signature

it's a pain that's what it is 😄 usually you do that with a combination of reading bytes and using bit shifts and bit masks to remove the unnecessary bits

<@456226577798135808> if you want to dive into coding (may be you want), I strongly advise you to pick a language (python, C, javascript), find a toy project you start from scratch... like reading the header of jxl file 😄 but you rarely learn insightful skills when just reading an overly complex existing project 🙂

nah, most formats that were not designed by a committee that enjoys adding 4 zero bytes "for future extensions" that have *never been used in 20+ years* (I'm looking at you, ICC) do some form of bit packing 🙂

the answer to what makes JXL's headers smaller is that we managed to standardize a version of the headers that didn't have huge "designed by committe" components (because *what if you want to reuse your color image as your alpha image? with heif you could!*)

https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41664

this is definitely not tor's territory when they ship ways to limit even font selection & js support due to advantages of reduction of attack target surface

like you'd expect them to remove stuff sooner than add any

It's amazing how quickly opinions can be changed

yeah. internalizing & trusting someone who provide wise & well-sourced perspective works that way

I mean, literally in the links Thorin posted it says "We don't know why they disabled support since it never got a chance to live"

But it does make sense TOR won't add it. Chicken and the egg situation, can't add it until it's widespread, can't be widespread until it's added

rip. this stuff is truly silly

Knowing Elon, just tweeting at him and saying "Hey, wanna help a direct jpeg replacement" would probably make him flip the switch overnight

It's because they're freaking lazy.

Most of these people are just looking for ways to not work as much as possible.

That honestly might work

Sure you can! MIT allows relicencing, so you you are free to use it under GPL. If it is an issue I don't mind putting that code under an even less restrictive licence (CC0 I guess?).

I need to spend some more time on pyJXL. I'd at least like it able to get header information from a raw codestream.

Yes, that's how it works now.

https://github.com/Alex313031/Thorium-Special/releases?q=android Thorium 110 for Android with working JPEG XL

Should mention that the support is essentially completed and done after merging the patches that have already been tested in other firefox forks

It's infuriating that progress is stalling and halted for essentially no reason and when people ask why, completely unaccountable people respond with some non-sequitor "avif, avif!" response and this has nothing to do with avif

completely unaccountable people in leadership roles who can't answer a question about JXL without bringing up a non sequitor that nobody asked about or frankly cares about as much. It has basically zero usage across the web despite being fast track enabled in every browser

If "too much effort" is really the issue, I think we can find plenty of people who can do the actual work (which is not much, all the integration code is already written). But I suspect that "too much effort" is often just a polite way to say "nah, I don't want it". Maybe not in this case, but in the case of mainline Chrome and Firefox, it's hard to believe they really cannot spare the effort when some of their tiny forks have can.

there's zero enthusiasm because nobody asked for yet-another-format that brings absolutely nothing game changing to the table

TBH I do think avif brings at least one game changer: it beats GIF by an order of magnitude. Then again, they could also just have allowed video formats in an img tag instead of wrapping it in an avif container...

exactly...

what is the point of yet another container format...

nobody wants that or asked for that

they could have done that instead of making webp too

At least JXL *can* beat GIF most times if you just want a blanket conversion, although with pre-existing highly dithered ones you really have to crank up the effort (although thankfully GIFs are usually small too because they're so bad)

And they didn't need to invent such a ludicrous name, they could have stuck with the .mkv suffix convention

.mp4 used to be the guaranteed "this will work" file extension, now in the limbo of transition it's kinda a dice roll (ignoring HEVC)

personally I don't name any files .webm, I use the normal, long standing convention of mkv for video and mka for audio

mp4 is complete trash

I record to MKV by default and remux when I need to share files

moov atom normally at the end of the file so playing the file is impossible unless you have the end of the file

Having to re-write the entire file just to move the moov

the only reason mp4 is still used is probably apple, idk why anyone would actually want to use such a dumb format

It's essentially entwined with H264, accepted everywhere no questions asked

and I'm sure apple had a lot to do with that

If you hand someone a .WEBM or .HEVC, some people might not even know they're videos

mkv doesn't have any weird surprises or idiosyncrasies.

It just does what it's supposed to

But it's also rarely supported anywhere outside of recording or editing

It even works on Windows now

Huh, that I'll have to test

yeah, windows has built in support

I'm surprised how long it took for Apple to support flac

for the longest time apple refused to add flac support

then they silently added it recently

now flac is supported ootb on all apple devices

but it took this damn long

for such a simple thing

even though it was by far the most popular lossless format and it was unbelievably superior to apple's terrible ALAC

I should also really rethink my videos. I've got 600GB+ of MKVs sat on my one and only 2TB drive, just sitting there doing nothing apart from archival purposes. Had 2 HDDs die in as many years but don't have the money for a big SSD to last a few more years

if you are looking for a new ssd I recommend getting a hynix

I swear that's not a sexual word

they're one of the big 3 manufacturers of memory along with samsung and micron

Either too small or too expensive

My use case is literally perfect for HDDs, large, long term, low use storage. But with 2 dying for no reason, with no errors, in a year each, I'm not sure I trust them anymore

what brand?

hitachi? fujitsu? wd?

the hynix drives are pretty decently priced 2TB drives, that's why I mention them.

SK hynix?

Seagate, which I know had a bad reputation, but 0 errors and dead in a year? Come on....

Looking at prices it seems most M.2 drives are around the same price at 2TB now, about £120

A bit different to the £350 I paid for the SATA SSD I'm running now

I think you are still better off with hard drives. You can get a 2 TB hard drive for £50, so if you just want to reliably archive data you would be better off just buying two, one as a primary and one as a backup.

I have one Seagate from 2009. Still running fine.

That's what I had, then they both died after a year

Ideally I'd just be cloning my main drive occasionally and have a secondary drive for replaceable data

How would I know?

One was SMR the other was PMR by the looks of it

index at the end of the file is a great idea

matroska is *full* of weirdness

it's an absurdly complex specification that contains a truckload of weirdness

For encoding, yes. Not for streaming decode though...

Yea, but you can move it to the front if you really need to do that

Not a good idea. There's no point in having two, since, in cold storage, you would not be able to tell if one of them fails unless you are testing both of them regularly.

in practice it seems to "just work" with no surprises.

having had to debug matroska weirdness in mpv I assure you that it's not true that generic matroska files "just work"

in any way that ISOBMFF doesn't

From the end-user's perspective it is different.

hey what's better for streaming, moov atom at the top or fragmented?

from and end-user's perspective practically all containers are the same

depends on if you expect the user to have the start of the file. fragmented has slightly more overhead but you can start in the middle of a file

from an end user's perspective mov/mp4 is trash

how?

have you ever seen software or websites not work with mp4 files with H.264/AAC embedded inside

How?

Not being able to play a partial file.

not being compatible with certain codecs

by comparison mkv just works as a universal "I-don't-give-a-shit" format that does not give a shit about partial files or arbitrary codecs

MP4 is "hurr durr I don't like that codec combination and I can't play the file until the whole thing is downloaded"

I mean there's many containers, MKV sure is the best one but I'd rank MP4 on at least 2nd place due to its vast compatibility, and you can get around the index problem thing by moving the moov atom to the top or fragmenting it (Avidemux example)

mp4 is an international ISO standard. And recently it supports both opus and av1 and even vp9

Mp4 is much simpler. While mkv contains the whole EBML markup language, literally html inside

It uses a binary version of XML.

the great compatibility of mp4 is only contingent on what your target playback environment supports, which is usually very strict and picky. It's not like just because a device "supports MP4" it necessarily supports your use case.

Most playback environments only support an extremely specific usecase of mp4

so compatibility is not really anything special in mp4's favor

from an end-user point of view, I can tell ffmpeg to put any combination of a/v/subtitle codecs I want into a matroska file and never had a problem with incomplete/partial files

remuxing and demuxing matroska with ffmpeg has always been extremely straightforward, reliable, and predictable.

the format itself has very low overhead as well.

the files work just fine in browsers, and in the built in tools on Windows.

They can be played back even if part of the file is missing.

I have not read the format specification but from this perspective as an end user it could not be more straightforward to use.

mp4 on the other hand is fragile garbage that feels like something a committee must have voted on.

you can't remux fragments of mkv with ffmpeg

same issue with streaming

or specifically, mkv doesnt work at all without the header

>>><#794206087879852106>

It's kind of disappointing that after https://github.com/mozilla/standards-positions/pull/741#issuecomment-1414685282 and some sensible questions from Jyrki, they just locked the thread as "too heated" instead of answering...

Also the combination of > We don't make these assessments lightly, and > our assessment is not based on our own testing is quite strange. How can you make any assessment without doing at least some amount of testing? Are they really that short-staffed that they cannot have even just one person spending an afternoon encoding some images, looking at the results, either with metrics or with eyes or both, and forming some opinion of their own?

Rather unfortunate that someone came in & started being rude

Yes, that is very counterproductive. But it is not really an excuse to ignore polite questions.

> Why do you follow Google every goddamn step? Why do we need Firefox if we can have the SAME stuff in Chrome? Considering Chrome is the one that shot JXL in the first place, I'm not even sure what they were trying to say

if you oversimplify & zoom out enough that may look weird, but following chrome and adopting format that happens to be jointly developed with some google research devs and non-google devs is not the same thing

like modular part of it isn't from google at all

maybe some things contributed though but FLIF/FUIF research that led to large parts of it wasn't from google

not to mention that mainstream google and google research are kinda different politically

Question about Google Chrome. I see, that many JPEG XL developers also work at Google. Do I understand correctly, that these devs have no or very little influence about JXL adoption in Chrome, even thou they work directly in Google? Thanks.

Yup.

Same company, very different divisions

Google is a pretty big company.

Ok, thanks for clarification 🙂

( continuing discussion from <#803645746661425173> message link: https://discord.com/channels/794206087879852103/803645746661425173/1086853850079694929 ) <@238552565619359744> it might be better to just try to add support directly to blender itself, I don't see much of a reason why they would decline

the webp implementation could possibly be used as reference https://archive.blender.org/developer/D1598

Huh, I didn't know they were essentially hosting github locally, that explains why I couldn't find much info about issues/updates in the past https://projects.blender.org/blender/blender

it's gitea, pretty cool!

Did librewolf apply the jxl patches or is it still buggy?

It's way easier to have zero accountability and not answer sensible questions. Way less work.

Of course they will choose the easier option.

What's more ridiculous and frustrating, is... in the time it took to type this excuse, the patch could have been reviewed and merged.

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

I just installed librewolf on my Steam Deck. It's so awesome!

I love how the default settings are very forgetful.

So I don't have a bunch of cache junk taking up space on my Deck's SSD

<:HYPERS:677894832424878137> ARCH ffmpeg has jxl enabled by default now https://github.com/archlinux/svntogit-packages/commit/f2ea8e9559bf9e8c2d5d6f4b673d30de676bb900

<:poggies:853085814032302122>

I guess the maintainer finally changed their mind...

I'd like to see output of: ldd /usr/lib64/qt5/plugins/kf5/kfilemetadata/kfilemetadata_exiv2extractor.so

Sorry, I do not see problem here.

https://github.com/brave/brave-browser/issues/28411#issuecomment-1480668264

> Brave follows upstream Chromium's release schedule very closely; Brave Nightly is built on Chromium 112.0.5615.29 as of 5 days ago. We've also been actively working on the upgrade to Chromium 113 since even earlier this month. > > As far as I can see, the libjxl patches are only available for 111.0.5563.69. For my draft PR, I had to branch off of Brave 1.51.43, which was the last version on Chromium 111. > > We'll definitely need to see a faster update cadence of the libjxl Chromium patches for this to be feasible.

<@795684063032901642> can we do something here?

I'm surprised to see the patch failing so quickly, what changed in chrome? Did they update highway again?

maybe it's due to how the thorium devs setup their patches/repo? as it seems that the thorium-libjxl github has both patch files and just modified pre-patched files sitting in the repo and for the brave draft pr they didn't see or use the patch files and manually created them based on the pre-patched files in the thorium-libjxl repo

also doesn't help that it seems like the patch files and pre-modified files aren't kept in sync

I commend the efforts of the thorium devs trying to keep a repo for easily apply-able jxl patches for chromium however I'm not sure if they are up to the task fully or at the very least there are some problems that have to be worked out

holy dll hell...

Can Chromium on Android be patched like it was on OpenMandriva out of the box for certain ROMs?

Why not. It is possible

Are they any websites providing content in JXL ? I asked Vivaldi for supporting JXL but they asked which websites use JXL, and unfortunately I don't even know one <:KekDog:805390049033191445>

chicken and egg problem 😄 but fundamentally broken argument... you cannot expect websites to use some format is browsers dont support said format Thats like asking if Vivaldi should support Javascript in 1995...

shopify is a particularly big-name site that serves jxl if the browser marks it as supported

(via `accept:` headers)

Shopify's support is slightly busted though it will only serve JXL files to browsers/clients that also support AVIF

that's true, but if both are sent via accept headers it does serve JXL files

also yeah Shopify is a somewhat big deal as they have many many many websites under their name/service

I came across one in the wild a few days ago

and a friend also came across one a few days ago and messaged me saying they saw a jxl file (they use waterfox)

does mercury support JXL? the thorium for firefox

don't think it does yet. there is this issue page for it currently https://github.com/Alex313031/Mercury/issues/6

ah ty

hmm, I checked this and sadly no mention of JPEG XL https://cdn.shopify.com/

every single shopify site supports serving jxl files, here is a small list of random shopify sites as an example: https://victrola.com/products/the-nerves-one-way-ticket https://magicholz.de/ https://www.tentree.ca/pages/about

Thanks !

that last one especially

you should mention, that it uses .jpg extension even for JPEG XL 😄 i thought it doesnt work until I tried to save the image

what browser are you using? because if it's palemoon or waterfox you can press CTRL + i and go under the media tab and it will tell you what format each image is

think you have to wait until the site is fully loaded though

waterfox, thx

<@693503208726986763> i have read you new comment, maybe add link to this: https://chromium-review.googlesource.com/c/chromium/src/+/4257656 and this https://bugs.chromium.org/p/chromium/issues/detail?id=1416530 they dont have to maintain it much, they just have to merge this prepared commit that enables JPEG XL in chromium

Ok thank you very much ! I'll add it

wait !

ok

xD

but still, quite interesting to have a patch to reenable JXL in chromium <:YEP:808828808127971399>

those commits/pages do lay most of the ground work for adding JXL support back to chromium however they aren't a full drop in solution

ohh, sorry for my misunderstanding

it's fine

something like this https://github.com/Alex313031/thorium-libjxl or this https://github.com/OpenMandrivaAssociation/chromium-browser-stable/blob/master/chromium-restore-jpeg-xl-support.patch would be a more "full"/easier solution

however I have noticed the thorium-libjxl repo isn't setup the best and has the possible problem of licensing as the repo is put up under "GPL 3.0", I haven't really checked out that other patch though

made issue request about licence https://github.com/Alex313031/thorium-libjxl/issues/8

the person behind thorium seems to be someone who is very into FOSS so unsure how much they would be willing to change the license

we will see, asking cant hurt

yeah although for me personally I usually get pretty bad anxiety around asking stuff so I usually try to gauge how likely the answer to a question/request is "yes" before I ask

it's probably hindered me a lot over time

Isn't chromium GPL? Or am I misremembering?

Ah I guess it is BSD now.

I was thinking that KHTML was GPL, but I guess they have rewritten most of it.

Which I guess they would have to as Chrome doesn't distribute its source.

https://elk.zone/disobey.net/@gianni/110102992288181670

https://github.com/Alex313031/Mercury/issues/10

There is not a single program on android that I could watch JPEG XL ?

tateyomi ?

a comic reader compatible with jpegxl

died from my image

lol

is the problem in tateyomi or in your image 😄 I think the developpement is open, you could try to speak with the devs

I also asked my friend with a more powerful smartphone. it just died

lol

meh. the question remains - There is not a single program on android that I could watch JPEG XL ?

a phone is kinda linux so i think libjxl should be available

no, it doesn't work that way. Because my smartphone is 5 years old

manufacturers dont update them

problem is that libjxl doesnt have memory limited option

Well, no. I don't need an update. after all, as usual, they shat shit into it. I have returned the old factory version which is why my smartphone is still working. I have already been updated, I have a smartphone j4 2018. after updating to android 9, its price dropped 3 times in a couple of months because it became impossible to use the smartphone

and. well, also. OneUI is vile

It's not a problem. And there is no need to make such mechanisms. From any image, be it Jpeg or Png, you can make a bomb. because memory is spent not on Decoding, but on Rendering an already decoded image, which is stored in memory in its pure form Better tell me how to open a JXL image on android

edit: an humonguous JXL image

would it work in PNG ? isn't the issue in the image buffer ?

☝️ any according to the documentation

try it yourself

in png ?

in all

I'll try... but my smartphone is almost as old as yours 😄

a lot of memory is spent on the decoding

I'm sure that's not a problem

an 8MP image can take just 24mb in memory, but will take hundreds of mb from libjxl

because of that, on https://embed.moe i had to hack in a swapfile in the container so it wouldnt crash instantly on any image

you just need to read the resolution of the image before decoding. and count the number of pixels

and do what?

not decode it?

yep

so you would want your viewer to not show you your image?

I have 48 megapixels of jpeg xl when decoding in the browser use 1 gigabyte of memory. it also means that for my personal work I limit myself to 100 megapixels in general

well that's a you issue

everyone else would want to be able to see it

You wanted to say the solution?

not sure what you're complaining about

no. you can not be able to see 100000x100000 image

??

like why the f does it become obsolete in like 2 years

YOU say that you have crash