JPEG XL

Thx. I need to get my head around its implications, then, properly. And possibilities maybe too. Because, for now, I’m much more worried by the former than excited about the latter.

what implications are you worried about?

there's no in-the-wild pre-existing Exif that will accidentally trigger this, if that's what you're wondering about

it's basically just a way to pass the Content-DPR information with image-embedded metadata instead of having to use an external http response header for it, which relies on servers knowing what the supposed dpr is, or having to use html markup (srcset 2x etc), which adds markup bloat and puts the burden on whoever or whatever is producing the html

plus it makes non-integer or non-square scaling factors possible

> there's no in-the-wild pre-existing Exif These all look like standard Exif fields to me, no? Most images I deal with have them all set (to some ancient, silly defaults, when it comes to “resolution”) > accidentally trigger this Luckily, images I deal with are sized explicitly by HTML/CSS. I hope! But the fact that their size will be now unpredictable when used “soute” is scary. > having to use html markup (srcset 2x etc)), which adds markup bloat That’s what we do now. Indeed, Picture element syntax is very verbose and the promise of less bytes there sounds cool. > puts the burden on whoever or whatever is producing the html Yep, but at least it’s there for everyone to see in plain sight. As opposed to reusing metadata that’s everywhere, but I bet 99% of tools don’t care about keeping it, let alone keeping it in sync with image operations. And Firefox won’t display this metadata for me even in its fancy Page Info>Media thingie. I just cropped a larger image to 40×40 pixels in latest ImageMagick. Exif was obviously left as-is from the original. OK, did the same in latest Photoshop and was pleasantly surprised it adjusted the values. But surprised I was. I need someone cleverer than me to explain that to me. If we would like to indeed use Exif to cut on the Picture element size (the **only** possible benefit I can imagine): would the responsibility of writing correct metadata be on our tools (good luck with that!), on image resizing CDN (again, good luck… also how to pass what we want?). And the spectre of having to rewrite metadata, or, worse, create a new set of copies with new metadata if we would want to change our dpr density steps in the future sounds…

Again, as I said, there must be something fundamental I’m missing. I would vote it would be this > there's no in-the-wild pre-existing Exif that will accidentally trigger this

The metadata has to match exactly, e.g. if the Exif metadata says the image is 500x500 and the raw image dimensions are 1000x1000, then the Exif density has to be 144dpi exactly (Since the default is 72dpi, giving a 2x downscale factor)

If it's off by even a pixel the behaviour doesn't kick in, and you get the "preexisting" sizing behaviour where the Exif values are ignored entirely

tbh sounds annoying

but maybe easier to support server side than including extra header in response

but eh. needs extra vary header either way

sounds like worse than it was before ngl

> The metadata has to match exactly, e.g. if the Exif metadata says the image is 500x500 and the raw image dimensions are 1000x1000, then the Exif density has to be 144dpi exactly Ah! That was the missing bit in my head! Thank you, The_Decryptor! This is a worse case of Silicon Valley optimism than I though, then! Not only it requires rewriting all the tooling to deal, write, reconcile and display all this metadata (so that one knows WTF just happened). But also to do it incorrectly and against the spec. Hahahahaha. No way…

It shows intent though, you're not going to set those values correctly by accident (At least, it's very unlikely), and the failure case is just how browsers handled the images previously anyway

It's a mess, but it's a backwards compatible mess, and if you're doing it from scratch then you'd just do it the way JXL has done it

https://www.quora.com/Will-JPEG-XL-lossless-make-DNG-obsolete

> "Secondly, DNG also contains essential colour matrices for correct colour rendition. The RAW image data mentioned are typically in camera colour space, there will be several conversions to make the image rendered in target colour space, e.g., sRGB or aRGB." Is this just the ICC profile, or is it something else, like the camera's response curve?

which can be mapped in an icc profile

actually, can't any format be arbitrarily implemented into jpeg xl like extensions using metadata/extra channels?

Pretty much anything I would imagine. Can you do the bayered layer? That seems the most unique bit of RAW formats. You would have to have extra space between the different pixels, or would you just leave the pixels without a sensor in that channel with a value of zero or something?

We have kCFA extrachannels for that. Just need to have some convention on how to represent what the exact layout of the bayer data is...

it’s more complicated, see https://doi.org/10.1117/1.OE.59.11.110801 for more on this

https://www.odelama.com/photo/Developing-a-RAW-Photo-by-hand/

Thanks, I'll have a read over these.

Thanks. That was a really interesting read.

I wonder why sensors generally use Bayer patterns but displays generally don't. Capture and display is pretty much symmetric, no? I mean in what is theoretically the best subpixel layout assuming that you use some kind of filter (a single area can only capture/emit one kind of colored light)

>Capture and display is pretty much symmetric, no? no. certainly not in a ways currently implemented

I don't mean how it is done (of course a sensor is not a display), but in both cases you have a 2D plane that you can divide in subpixels of various shapes and colors (typically just RGB but in principle you could add other color filters, and some sensors and displays do that)

I wonder why in sensors RGBG is very common (though of course there are all kinds of variants) while in displays RGB is very common (though there are some exceptions)

Is it because green is perceptually brighter?

So you need to capture more, but the eye/human perception does the adjustment on display?

the SPIE link seems to have at least a partial answer for the sensor side of things: > The Bayer CFA uses twice as many green filters as red and blue, which means that two values G1 and G2 associated with different positions in each Bayer block will be obtained in general. This is beneficial in terms of overall signal-to noise ratio since photosites belonging to the green mosaics are more efficient in terms of photoconversion. Furthermore, the Bayer pattern is optimal in terms of reducing aliasing artifacts when three types of filters are arranged on a square grid.¹⁴

G contributes most to luma, so a Bayer pattern is kind of similar to chroma subsampling

(why don't they do White instead of G? Should work too, no?)

It might be hard to make a photoreceptor that has an even response to a large spectral range.

I think it might have to do with: > For example, better signal-to-noise performance is achieved by reducing the overlap of the response functions, which corresponds to a characterization matrix with smaller off-diagonal elements. [10–12]

but not sure

> "since photosites belonging to the green mosaics are more efficient in terms of photoconversion" This seems to suggest that green is easier to collect with photoreceptors.

https://doi.org/10.1117/3.725073 might have a word or two about this, let me check

So for the visible part there it looks light green would be well received, though it seems mostly flat.

You might struggle a bit with the longest wavelengths of red though.

G is captured well by both L and M cones

i thought some do RGBW?

Yes or RGBM or RGBE (where E is C)

I just sent and updated patch to the ML for ffmpeg

I'm hoping it gets merged today or tomorrow

after that it'll be time to write the encoder wrapper

Cool!

Got merged I heard?

No, it has not been merged yet: https://git.ffmpeg.org/gitweb/ffmpeg.git/shortlog

Oh, well I hope it will happen soon then

Also, is something broken in the JXL patches for Firefox? <https://phabricator.services.mozilla.com/D122158> <https://phabricator.services.mozilla.com/D122159>

i did a rebase and fixed something but im not sure how updating it works. the patch should still work

nope, it's been sitting in the ML for a day now

no comments

https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg127081.html https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg127082.html

Oh, I'm a dev now? Nice

I did typo the commit message but that can be fixed when it's committed

since whoever applies it can simply do a git rebase -i and then rename it before they push

so I won't need to send an updated patch for that

jpeg xl is not supported in android fo example in those apps

https://mauikit.org/blog/maui-2-1-0-release/

i tied index it has no jxl and avif suppot

not as advetised

pix said it should be on 2.1.1

it has very basic functionality

you can't hide you explicit folde

so how i use those apps

who is this maiu

is a person, and english person

or is just some things they do on linux, ex, a set of software ported to android or a framework that uses a similar interface and code.

i installed those apps but they didn't look user friendly to me

Nice! https://github.com/libjxl/libjxl/pull/836#issuecomment-966419483

HOLY MOLY that is one heck of a speedup for these functions.

<a:FurretSpeed:832307660035850310>

Well doing things with int16 vs float32 makes quite a difference, in particular on ARM. The instructions are faster, the simd width doubles, the memory/cache halves, ...

yeah the problem is precision with larger DCTs

I think to begin with I'll only figure it out for up to 32x32

Tbh I think limiting things to 32x32 is not a very big limitation - usually those big blocks can only really be used for smooth areas anyway, and in that case likely the LF coeffs are enough, and those LF coeffs would be identically encoded regardless of whether it is done as multiple 32x32 blocks or a single 64x64 or other bigger block.

(there are cases where big blocks can be useful for areas with more HF activity, but I think that's relatively rare in practice)

well interpolation would be different

True - but if the original is basically just a simple gradient, then either way the LF coeffs alone will be more than enough info

any gallery/file manager on android (not firefox nightly or chrome) yet with jxl support?

I'm not aware of it, yet

<:Thonk:805904896879493180> <https://encode.su/threads/3397-JPEG-XL-vs-AVIF?p=71536&viewfull=1#post71536>

This got me interested so I ran some tests.

So as long as you use falcon you can beat imagemagik's speed whilest getting significantly smaller files.

But if you care about CPU time rather than real time you do have to drop to thunder.

Still much smaller than png.

Also seems to mostly hold for much smaller images, though you might need to go for thunder to definitely beat it.

That said, I'm sure you could get both going much faster if you really tried.

the above example reminds me that we should make compressed exif/xmp work and do it by default

(which will make encoding a bit slower, but those 10 KB of metadata probably compress to 1 KB or so)

we can in principle make a faster than lightning lossless encoder too, that might still get close to PNG in compression density. But it would take quite some coding effort; atm our encoder expects input as float channels (would have to make it take int input directly, to avoid the unnecessary `* (1.f/255.f) * 255.f` conversions), and atm it buffers all tokens, computes histograms per ctx, and then writes all tokens. For better speed, it could use a fixed prefix coding per context and just start writing tokens directly (but that's code that still has to be written).

from https://github.com/thebombzen/FFmpeg --enable-libjxl enable JPEG XL de/encoding via libjxl [no]

i hope soon ...

It's got some more work to do, unfortunately

There have been some news in WebKit enhancement: https://bugs.webkit.org/show_bug.cgi?id=208235 👍

I tried to answer the question. The answer is probably going to be hard to understand though for someone who "never really understood what color management is tbh", but maybe it'll help.

> I was skeptical about a new image format, but the fact that Firefox and Chrome both implemented it as an experimental feature seems reason enough for WebKit to do the same. At least it seems clearly more popular than JPEG 2000. heh

milestone reached: "clearly more popular than JPEG 2000" 😜

looks like that initial webkit integration is just ignoring color management completely, just getting an uint8 buffer and passing it on without getting the icc profile

they don't really have color mgmt worked out for non-apple stuff it seems

the world has been "meh, everything is sRGB anyway" for too long, I guess...

otoh i think apple is the only vendor to attach icc profile to screenshots. could be a privacy issue though?

Apple has at least P3 screens in all of their products afaik, so they kind of have to put a profile in it, otherwise it would be interpreted as sRGB.

mmhmm

Is that conversation public? 👀

its from link from post above that message

<https://bugs.webkit.org/show_bug.cgi?id=233113#c15>

What is needed to get JPEG XL in Photoshop? Is the org communicating with Adobe?

Leonard from Adobe has told me that it's on the roadmap for Photoshop, but I don't have a timeline - I expect they at least want the ISO standard published first

Feel free to make a pull request for jpegxl.info 🙂

https://forest.watch.impress.co.jp/docs/news/1372376.html

kimageformats with jxl support landed on archlinux repo

not sure whether it works as dolphin simply refuses to show .jxl thumbnails for me but eh

KDE?

Thumbnails are working for me. But I've compiled the package manually.

For thumbnails in dolphin you need to edit /usr/share/kservices5/imagethumbnail.desktop Add image/jxl; to the list.

I've added that already. Also shouldn't this be upstreamed considering plugin supposedly is

Also it seems some files conflict with `qt5-jpegxl-image-plugin-git` package so I have that uninstalled. Was thinking that it being in kimageformats should've already made things work

The imagethumbnail.desktop was updated, it has image/* now. But it belongs to kio-extras package which different release schedule.

I think it will be in 22.04

no idea tbh. i know too little of insides of whatever is in kimageformats atm to tell whether it fully replaces qt5-avif-image-plugin or not

The plug-in in kimageformats is almost identical. The AUR package of qt5-jpegxl-image-plugin have one extra thing - it installs .desktop file for thumbnailner. Next year, after release of kio-extras, it won't be needed.

https://github.com/mozilla/standards-positions/issues/522#issuecomment-1001521329

> also support JPEG XL in firefox already ffs

haha

`it's more of a bug than a feature, it works with SOME avif images in their software (including edge) adding anything that isn't in the video codec (like alpha channels or animated AVIF) breaks it.`

`animated AVIF`

Why would video AVIF break it? It's just normal AV1.

Maybe multiple av1 bitstreams doesn't work? IIRC that was the original idea in avif: intra-only, separate payloads per frame

Gonna go all in on jxl the moment ff and chrome have it on by default, and just let the other browsers catch up.

What other browsers <:kekw:808717074305122316>

safari <:kekw:808717074305122316>

internet explorer <:kekw:808717074305122316>

There are only three contemporary browsers: chrome, safari and firefox

Yeah everything else is a skin over one of the three

Microsoft likes to modify Chromium to keep things interesting

Chrome has 65% market share, Safari 20%, Firefox 4%, and the remaining 10% are mostly Chromium-derivatives which regarding image format support are likely to just follow Chrome.

(there's also non-Safari-webkit, IE, and a long tail of exotic browsers, but these have no real influence on defining the web platform)

WebKit without safari is.... GNOME Web and what else?

> WebKit is also used by the BlackBerry Browser, PlayStation consoles beginning from the PS3, the Tizen mobile operating systems, and a browser included with the Amazon Kindle e-book reader.

IOS browsers I guess but those are more 'safari skin' than independent codebase with independent codecs

> KDE's Rekonq web browser and Plasma Workspaces also use it as the native web rendering engine. WebKit has been adopted as the rendering engine in OmniWeb, iCab and Web (formerly named Epiphany) and Sleipnir, replacing their original rendering engines.

All iOS browsers are Safari

there's wpe webkit which is optimized for embedded theoretically

Safari uses Apple's CoreMedia library for all image and video decoding. That means to get a new format supported in Safari, both iOS and MacOS need to be updated first to have OS-level support for it.

It's an approach that slows down browser innovation, but it has the advantage that things Just Work Everywhere once they work somewhere — in big contrast to WebP which used to work in Chrome but nowhere else...

does anyone still use a non android blackberry?

<:kekw:808717074305122316>

Firefox vs Chrome vs Chrome vs Safari vs Chrome vs Chrome vs IE

wait nvm that's ie, when did microsoft make it all blue?

edge ticks all the boxes in mozillas comparison table <:kekw:808717074305122316>

Desktop+Mobile

Desktop only, Safari is only 10% and everything else is more

Mobile only, Safari is 26%

https://twitter.com/jyzg/status/1477322811983204355

So apparently Firefox devs are considering not adding any new formats and hoping AVIF will just fix their issues? 😧

<:Hsss:806131225278152756>

I think it's annoying that browser devs consider themselves to be the gatekeepers of what should be the image formats one should use

Why is supporting JXL so difficult though? Like, there are definite advantages to supporting JXL over AVIF, the biggest one for them being the possibility of using JXL to replace the standalone libjpegturbo decoder.

On the one hand, they still support BMP even though it's 1) not as simple as it looks on first sight, and 2) it's clearly not a great codec for anything, least of all for the web

On the other hand, they are very hesitant to add anything new

At this point, I think the main showstopper for jxl adoption is the combination of three misconceptions: 1. There can only be one winner of the format wars. 2. AVIF can be improved (this much is true) to outperform JXL (compression-wise that is questionable, feature-wise that is false). 3. Being an AOM member (which all browser vendors are), in order to protect this important strategic alliance, everything has to be done to make AV1 successful (and by extension, AVIF), including sabotaging competing codecs.

why can't AOM get behind JXL? it's an _open media_ format, after all

"not developed here" syndrome, I suppose

AOM was created because they were fed up with the patent bullshit

... which they associate with MPEG, and I suppose ISO in general

alleged AVIF dev who doesn't think the lossless performance is something they should address, and agrees that JXL is superior: <https://www.reddit.com/r/AV1/comments/rkcx0o/we_need_to_rethink_avif_lossless_mode/hp96l1l>

AOM is an alliance for open media, but it's also an alliance including many hardware companies that are now heavily invested in hw av1 implementations

They likely assume that if jxl gets adopted, the value of their hw will decrease

TIL <@!321486891079696385> is an avif dev

he's everywhere :dorime:

Wait, you DIDN'T know? Wtf

So this means all your work was pointless because JPEG XL will never really be used?

I hope not. But I don't think browsers will be the quick road to adoption, unless they change their minds.

Just means all of us and other supporters (Facebook/Instagram, Adobe, and others) will need to put our collective weight into pushing browser devs to support it. The division means there is a decent amount of support, it will likely just take a bit more outside encouragement to get it over the finish line. *Keep it professional, though.

imo, this will not be the final time this comes up. JXL is too good and this is just one persons account of what happened internally. And it seems like JXL has advocates inside Mozilla.

Chrome and Firefox have support behind a flag already, so it's not like there was no movement on it. Just that it may have stalled out.

Has there been any work towards getting libjxl to decode jpegs?

I know the internal machinery exists, but is an interface being designed for it?

The `enable-jxl` flag in Chromium expires in version 100, which has almost come into canary. I think someone needs to extend this flag.

iirc it's been extended before

For now in the source code it looks like this: ```{ "name": "enable-jxl", "owners": [ "deymo", "firsching", "lode" ], "expiry_milestone": 100 }```

what i'm saying is that it used to be less than 100 and they extended it before reaching the version that it would've expired on. at least, that's what i remember hearing about.

Yeah, so it needs to be done again 😄

I personally use Chromium, currently it's v99 and soon it will be 100. Don't want to lose the flag.

oh yeah all i meant was that there's precedent for extending it, i don't think they actually want to remove it

Well, let's hope they fully enable JXL with V100 🙂

I think that's their goal <:kekw:808717074305122316>

Crossing my fingers <:CatSmile:805382488293244929>

<@!532010383041363969> Do you have any good news?

Idk if it's the right channel to ask, but I can't get jxl working in Firefox 95.0.2 even after enabling the image.jxl.enabled flag

My build is from Manjaro tho, could they have disabled it at compile time?

it only works in nightly

is that manjaro build specifically FF nightly? not sure how that works

It's not nightly, but the flag is still there

Hmm good to know

I thought some sensors in phone cameras were RWBW, with W capturing mostly broadband luminance and R and B being used to derive chroma coefficients as well as contributing to luminance in those zones?

there might be an AUR package for it

There is, I did test that and it worked there

Which is in fact what I had done.

What I use daily is the Manjaro repo version of Firefox. But I did install Nightly from AUR earlier to test it out.

I don't use nightly because I don't update my system as often as I should, and I find updating AUR packages too often to be a hassle.

it's not like you have to update nightly

i only update it on an average of every 2 weeks

i build my own ff because video in ff isnt color managed

if I need color managed video I just play the URL with mpv, which is not usually

I barely ever play video in Firefox at all, I use mpv

yea, I figured, I meant, "since you're on manjaro you probably have AUR access, try that"

paru makes it very nice

paru is an AUR manager written in rust (yo) that is better than basically every other one I've seen

we're all familiar with mpv

it's just, if you care about color management then FF is kind of irritating

since FF's color management is "there is none" they just throw pixels at the screen and ignore any metadata about color

what would be the dream is if FF switches to a libplacebo-based renderer for images/video

Me too, I have a pre-made filterchain in my bashrc which applies pre-emphasis, compression and bass cut so I can watch videos on my TV with the volume being fairly leveled and without bothering people with videos that have unnormalized and uncompressed audio

I have a mpv hotkey that adjusts the filter kernel size and a hotkey to switch to area upscaling, for those pesky low-res emulator captures... I still get compression artifacts but no blurry pixels

Wish there was a way to adjust FFmpeg filters while in mpv, like add filters to the chain and adjust parameters... is there a way through Lua scripting?

Also could I have a script to append files/URLs to the playlist by simply dragging/pasting them into the mpv window? This could even be a native feature itself since it'd be useful to so many people

Yup I use paru, but I'm bothered with build times and with AUR packages that fail to build.

My CPU is a potato. I normally just set-and-forget but sometimes I don't even feel bothered to review PKGBUILDs and hate to see packages that fail to build and I'm usually not bothered to look for a solution.

We should maybe move over to <#806898911091753051> tho

I think like that, too. I tried to push on the approach/strategy of doing jpegs with libjxl. However, it didn't get support from other libjxl devs. Currently our priority is to get '1.0' ready and less the browsers. Once 'libjxl 1.0' is ready, we will came back to thinking about browsers and how to find more support there.

mostly the 1.0 relates to having a proper API to do most of the things that are available in the format

this work is mostly done in Google Research

im not sure if replacing battle-tested performance-optimized jpeg decoder with experimental jxl one with unknown performance and security downsides will be priority for browsers anytime soon. eventually, maybe, if jxl one will be actually better, but i don't think that'll be happening soon

our directors have had stronger beliefs in neural coding than incrementally improving classic approaches, so it has been a challenge to maintain investment in this area

i don't actually know how jxl vs jpeg-turbo compares but at least that's what id think if i were to have to decide on matter, until proven otherwise it sounds not rly strong option

neknekk, yes, it is controversial -- opinion depends on mood, users temperature measured from arm pit, prioritization of quality vs. war testing etc.

that exactly why we ended up not prioritizing it

I would have liked it very much and also solving the HDR with classic JPEG at the same go

Jpeg decoding would be very useful, it would reduce overall lib size, it would also be possible to use unified API, but yes, in order to be interested in replacing decoder, it should have some advantages over current implementations and have some additional features and maybe even be faster (or at least not slower) Maybe it's not the highest priority, a convenient and stable API is more important in my opinion, but still, also a very necessary thing

If the API is not yet fully stable, I can see why browsers haven't enabled jxl yet. Too much work to depend on a non stable API, especially one that is not yet mature, as it gets too many improvements between versions to just leave it on an old one.

browsers often vendor libs like these wholesale so i don't think it's a big problem

but api instability kinda gives a bad image about ready-ness of library overall so it still can kinda be negative contributing factor

The decode api is quite stable for a while now though

https://bugzilla.mozilla.org/show_bug.cgi?id=1539075 SmugMug and Flickr give support for JXL, too

Current state: 😄 ```{ "name": "enable-jxl", "owners": [ "deymo", "firsching", "lode" ], "expiry_milestone": 105 }```

<:SadCat:805389277247701002> ```const base::Feature kJXL{"JXL", base::FEATURE_DISABLED_BY_DEFAULT};```

How much percent of the API is done or when would you roughly estimate 1.0 to be ready?

I think we're quite close to final in the api definition itself. The implementation of the render pipeline (for more optimized decoding) is the main thing left to finalize and test/fuzz that I think we want to have done before the 1.0 release. Unless I am missing something.

I'm hoping for 1.0 to be ready end of February

Can we expect some versions before 1.0? 0.7, 0.8 or 0.9 ?

I think every version is some extra work from both the team and from the field

better to wait for end of Feb -- and for 1.0 -- I think

I think we should have a 1.0-alpha or 1.0-rc1 or something, without maintenance promises

Adding a real 0.7 release means we have to keep backporting security fixes to it, etc

0.x releases are usually not backported to security fixes

1.0 and above make that promise

0.7 users will be suggested to upgrade to 1.0 (or above)

in my experience any release will cause two weeks of hassle, better to postpone it to 1.0 🙂

https://github.com/BestImageViewer/geeqie Does someone know this viewer?

yeah i use it

Know it? I use it, but only for its similarity search.

geeqie supports JPEG XL, I had only to enable .jxl extension.

geeqie has different UI design than gwenview. It is no problem, it is easy to use. Performance is very good. geeqie has support for color management, that's important. I have impression that it is not supported for all formats yet. For example I think that JPEG XL files are loaded without color profile. That is probably easy to fix. Animated JXL is not played in geeqie (only first frame displayed).

The Guardian supports jxl in firefox (supposedly... guy did not use his work email) https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c27

<:BlobYay:806132268186861619>

<:JXL:805850130203934781>

<@810102077895344159> did you do that? 😉

Can't say I didn't have an idea, but also Mariot is amazing and I just happen to agree with everything he said! Would be sad to see Firefox suddenly join Safari in the joke corner... Obvs, FWIW – Guardian is no Facebook (thanks, Spaghetti Monster!).

TBH, I wish firefox had more market share, especially on mobile. Though I tend to use chrome myself most of the time (i have safari and firefox and the unstable versions of all three ready to test stuff, but I use stable chrome for normal use)...

I use FF on mobile because they didn't remove the bottom url bar like chrome

bottom url bar is indeed comfy

Its very nice.

My only real complain about Firefox on mobile is that it unloads tabs really aggressively.

So if I open five or six tabs with articles to read, then walk out of WiFi range it will be fine for the couple most recent, but then it will try and reload the tab when it gets to the older ones, so I can't read it.

that comment is pretty unhelpful without trying to justify why jpeg xl is "major and game-changing"

https://firefox-source-docs.mozilla.org/bug-mgmt/policies/triage-bugzilla.html < Details a bit about the priority levels. but it's aimed at devs instead of end users

that's still a lot better than chrome not supporting extensions at all

i don't really know why the hell they are restricting set of extensions what can be installed though, i mean one can always just uninstall if it's not working properly

I think the real reason is probably something roughly along the lines of "we had to hurriedly move to the new version of ff mobile to cut costs, and we don't want everybody to be able to install any random extension yet until we're ready for it because it'll cause us more support trouble than it's worth"

prolly similar reason for restricting mobiles about:config to beta/nightly channel users

Minimalistic viewer qView has out-of-box JXL support (at least in Win64 build which I tried) qView-5.0-win64.exe from https://github.com/jurplel/qView/releases/

<:YEP:808828808127971399> I've been using it for JXL since you released your qt JXL plugin

jxl got bumped from P5 to P3 in firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1539075

https://twitter.com/JavaPDF/status/1483066411505401862?t=rdR9oKsFI2OJXQOtaF66rA&s=19

java encoder/decoder?? <:monkaMega:809252622900789269>

they better mean libjxl bindings <:Hsss:806131225278152756>

I wouldn't mind if they would actually make a new implementation, but I doubt it's what they meant :)

i have the (jpeg xl, not pdf 2.0 🤦) spec pdf through certain methods. idk if it's okay to post here.

is it very different from FDIS

Just do it™️ <a:DogeEvil:821038587176419381>

My friends says that it'd be interesting to read this spec for bedtime, PM me too plz? 🙂

also requesting PM by anyone because lol i like having things though idk if itll be much use if its exactly the same as FDIS

honestly id like some encoding things to be clarified because i ended up needing to dig into implementation. stuff like not specifying exact types for enums. also explicit mention that some types are struct would be nice too, something i probably going to bring up if v2 will be done out in open

This is the most recent draft of the CD of 18181-1, 2nd edition

please ping me if you find anything that is unclear or incorrect, or just phrasing that can be improved etc

also please do not redistribute this pdf publicly

obtained. kind thanks.

if it's not bundle, and is blank, then what

I don't think that happens?

i guess basically there should be no such fields

but fair point

<@!794205442175402004>

I think the "if default is not blank" should just be removed because that should be always true

could be just shortened by removing ", if default is not blank", yes

i would also suggest explicitly specifying whether field is struct or enum, because when all i can see is unfamiliar field type, it's kinda unclear, until i get used to checking presence of default value

not to mention that some enums are encoded different than using default enum encoding

enums should now all be explicitly have a type Enum(something)

there are also "fake enums" that are encoded just using u(1) or u(2) or something, but that's basically just a field where some table defines how to interpret the numerical value of it (e.g. orientation, encoding, frame_type are fields like that)

yes, im talking about these

but there I think the type should now always be set to u(n)

so basically the field type should now always be either Enum(something), u(n), U32(), U64(), F16(), Bool(), or if it's something else then it's always a bundle

https://twitter.com/JavaPDF/status/1483727908443234306

now i wanna test their heic library <:kekw:808717074305122316>

It would be pretty neat to see an alternative implementation, especially for the decoder. Just got to make sure they implement all of the bitstream features.

i'd rather it were in anything other than java though

well not _anything_ i guess

i don't care in what language it is, what I care about is if they can implement it from the spec (as opposed to translating the libjxl code to another language)

because that's the real test for a spec, and we haven't had that test yet

I remember reading a speculation (?) that chrome would enable jxl by default starting from a certain version. Am I misremembering or...

iirc it had something to do with their release types (stable, beta and such)

https://chromestatus.com/feature/5188299478007808#details

I think the link to the ISO spec should be added there

Also not sure if "No signal" is accurate for firefox, I would say it's at least "In Development" given that it has been available for a while now in firefox nightly behind a flag

https://docs.google.com/document/d/e/2PACX-1vRikx3FbTlbAj_vkyIx4QITkMO-rnB7AV0kjzjRPPKTIBr-Ll1i3Ue5CJ5eHir-0ifmHwB8gRYisKbg/pub

> There is evidence of publicly linkable positive statements of support from developers or framework authors not associated with or not speaking on behalf of a browser vendor: > > Online social networking sites like Twitter. > Version control sites like GitHub. > Discussion boards like WICG Discourse. > Personal sites like blogs. > Support sites like StackOverflow. > Bug trackers like crbug (including the "star" signal[1]). > Working Group call minutes that included industry participants like this. > Authorized quotes from an important partner that they will try it and why like on blink-dev@. > Client-side implementations of libraries that (in part, if not fully doable on the client-side) do what the feature proposes, like, for example, NoSleep.js for the Screen Wake Lock API. > Feature reached TC39 stage 3.

why do we have "Web Developers: No Signal"?

I think we should be able to point to quite some significant web developer signals, including Cloudinary, Facebook, Adobe, Flickr, Cloudflare, The Guardian

even a link to a twitter poll can be considered a signal from web developers

starting a poll in that case

https://twitter.com/jonsneyers/status/1484249993645076485

Interesting how the proportion of "No" steadily increases as the poll starts to reach people outside my bubble

https://twitter.com/jonsneyers/status/1484595211493953536?t=Y7DDGsiZewkI_f_2vYVWiw&s=19

Strange how webp gets more votes than avif here. Is it because of lossless?

It's also probably because webp is now widespread in production too - thus more people use/know of it

It has a great near lossless mode. (Though for photos on the Internet I would always prefer JPEG XL.)

https://twitter.com/jonsneyers/status/1484249993645076485?t=HiAEf4qABnxZ3JTHSsTgtg&s=19

That's about 90% in favor of jxl, if you don't count the abstentions

But of course as <@710762823986446367> pointed out, if the question is "do you want to have a new thing or not", most web devs would say yes, no matter what the new thing is, I guess

So perhaps this other poll is more interesting then. It isn't finalized yet: https://twitter.com/jonsneyers/status/1484595211493953536?t=Lv9j1Qb-vDjiIT_owi4aSg&s=19

Interestingly, webp is getting more votes than avif on that one

Lossy webp is strictly worse than avif (vp8 is 2 generations behind av1), though maybe the faster encode is a practical advantage. Lossless webp is better than lossless avif, but there are not that many reasons to go full lossless on the web. When it's png vs jpeg, png is used when jpeg is just ineffective (like logos with hard edges and just a few colors) and when alpha is needed - but those things can also be done well with a modern lossy codec...

I imagine it is where people know the format, and don't want to deal with learning the intricacies of another new image format. I suspect a lot of people might still say JPEG if that was an option.

Hi! Apologies if I'm asking this in the wrong channel. I work in the medical imaging field and am looking to use JPEG XL in a browser based image viewer. For this use case, you are scrolling through hundreds of images stacked and most will not need to be loaded beyond their first progression as the clinician isn't interested in that slice. To control the amount of data transferred/performance I'm looking to be able to index the byte ranges of the file that correspond to the progression layers so the viewer can request the number of progressions required. From reading the API I can get the status from the decoder when it has finished decoding a full progressive step, is there a way to do a similar thing with the encoder in which I could capture the byte offsets in the codestream for each progression during encoding? The goal here is to be able to do byte range requests. Any tips or pointers would be greatly appreciated!

Imo, we should add an api function to get byte offsets from the TOC after reading the frame header, and/or a detailed encoder return status that includes the offsets of LF and each HF scan.

Yes that sounds like a great solution. Being able to get the offsets during encoding would be extremely useful so these can then be stored in the encapsulating DICOM file as it's being streamed. What's the process for an API modification? I'd love to contribute but my c++ skills are more than a little rusty, would I be best to create a GH issue with this commentary?

I have seen there is interest in the Dicom working group 4 (compression) on adopting jpeg XL into the DICOM standard as an official transfer syntax but I'm not sure how that's progressing

Pinging <@597478497367359500> and <@930856143885045771>

Probably a good idea to make a GH issue with a feature request to add such api functionality

good news someone who makes filetype plugins for paint.net (null54) is planning on making a jpeg xl plugin once libjxl's api is stable https://forums.getpaint.net/topic/119407-jxl/?do=findComment&comment=591551

Please someone tell them not to use `.ajxl` file extension because JPEG XL is supposed to use one extension, `.jxl`.

Done

wait... doesn't the "a" in .avif already stand for animation? "Animated Video or Image Format - AVIF" or did I just see that on some trolls teeshirt?

AV1 Image File Format

The A in avif stands for Alliance, I guess

AVIF = AV1 Image Format AV1 = AOMedia Video 1 AOMedia = Alliance for Open Media

Alliance Video Image Format

https://c.tenor.com/s8X-v3i3ioAAAAAM/wow-for-the-alliance.gif

https://tenor.com/view/spinning-top-inception-movie-gif-12483894

this kills me

yeah it's a limitation of paint.net's plugin system for example I remember back when paint.net didn't support 32-bit bmp files so someone made a plugin for 32-bit bmps that registered itself as ".bmpx"

so when ever I wanted a 32-bit bmp I had to export it as a ".bmpx" and remove the x at the end

It's strange that GIF also requires AGIF, because almost no one uses static GIFs

Static gif... imagine using that <:KekDog:884736660376535040> ~~sadly seen people using it for screenshots of in game errors and sometimes it was very hard to even read the red error text <:KekDog:884736660376535040>~~

<a:DogeScared:821038589201612820>

jxl support in GIMP got improved: https://www.gimp.org/news/2022/02/25/gimp-2-99-10-released/#jpeg-xl

> Compression slider is disabled for lossless. Isn't there a slightly lossy lossless output mode? 🙁

So no lossy modular?

This was never supported in GIMP and not disabling the slider was just confusing.

Also, these modes aren't controlled via the distance slider in the first place.

I noticed on the new GIMP 2.99.10 the bit depth is selectable for lossy JXL. I though that lossy jxl doesn't have bit depth, due to not being stored as integers. So what is this selection doing for lossy jxl? <@!886264098298413078>

The bitstream still signals some nominal bit depth also for lossy, basically as metadata so you know what would be a good bit depth to decode to

It's just a header field in case of lossy, without impact

any advantage to signaling a higher bit depth than the input was?

Like 8bit videos encoded with ~~x265~~ hevc 10bits?

yeah but that's advantageous because it affects the encoding process

I don't think so. The other way around makes more sense to me, e.g. if you have something that can be represented well enough in 12-bit Rec.2100 PQ, but your input format (after image processing, say) is actually 16-bit half-float or 32-bit float, then it would make sense to pass the accurate input to the encoder but to signal that it's fine to decode to 12-bit integers.

right, makes sense

It also influence precision of data sent to the encoder.

Thanks for the info

But the Gimp exporter for 16-bit lossy jxl has the problem that you cannot preserve details in the shadow. They always set intensity_target = 256. I opened an issue here: https://gitlab.gnome.org/GNOME/gimp/-/issues/7884 Please feel free to propose a better fix than I did.

you can use 16 Bit for SDR content as well, thus the intensity target should be unrelated to this setting.

But if you have a true 16 Bit image, it would be nice to achieve fewer artefacts in lossy compression. At the moment, there is a big gap between exporting lossless and lossy (with the highest quality) 16-bit images in Gimp 2.99.

It's probably more a question of transfer curve than of bit depth, and also what kind of brightness adjustments you are going to do when viewing or editing the image

This. JPEG XL is a great chance to move from 8-bit to (at least) 16-bit pipeline even for SDR images.

**For lossy** wouldn't it be easier (and better for the quality) to just always send 32-bit float? The bit depth slider would be then responsible for tagging the file only.

E.g. if someone wants to process a raw file from camera, especially after high quality debayering and denoising (e.g. DxO PureRAW or Adobe Enhance Details + Topaz DeNoise AI), 8 bits would introduce unnecessary and totally avoidable banding. If the source is high quality to begin with, why not send it to the encoder at full internal quality (16-bit integer or 32-bit float) and tag the lossy file to be decoded at 16 bits?

The current libjxl encoder will internally use float anyway, so there is no point sending buffers using less precision (to save memory or something) since they will get converted to float anyway.

While we're at it, I also encourage everyone editing images with GIMP to make more advanced editing in 32 bit float (or at least 16 bit integer) if you're going to export to JPEG XL since it enables efficiently storing that data and reduces generation loss from various effects applied to the image.

When sending 16bit integers to libjxl, values use sRGB curve but when using 32bit float, image has to be converted to linear profile first.

What happens if you select "Save original profile"?

I had this always selected when exporting files.

aight, I've been very busy with things like

school

etc.

but I've finally fixed the parser for ffmpeg and sent another patch to the ML

fingers crossed

Please.

That would be sooo awesome.

Imagine getting native JXL support before the AVIF patch gets merged in.

seems better now, passes all conformance samples with format hint (`.jxl` or `-f jpegxl_pipe`). unfortunately it seems still broken on pipe detection; for example, `ffprobe - < grayscale/input.jxl` returns `pipe:: Invalid data found when processing input`. `ffprobe -f image2pipe grayscale/input.jxl` returns `Failed JPEG XL Signature Check` but then apparently successfully probes it?

this causes `mpv grayscale/input.jxl` to return `Failed to recognize file format.`. `mpv --demuxer-lavf-format=jpegxl_pipe grayscale/input.jxl` works fine

also av_log needs `\n`, which doesn't really make sense to me

also let me introduce you to our lord and savior, `__VA_ARGS__`

where can I find `grayscale/input.jxl`

https://github.com/libjxl/conformance

also what is `__VA_ARGS__`

You are at least the third person to ask this same question... please check <#822120855449894942> next time.

https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html

thanks

apparently this is cause I assumed the image header was byte-aligned but it was not. the frames are, so the image header is byte aligned provided that there is no ICC profile

the presence of the ICC profile is what messed up the parser

thanks for pointing that out

oo, this is nice, although I'm not sure if they permit `, ##__VA_ARGS__)`

I'll have to ask on IRC

where's that from?

the page you linked <:kek:857018203640561677>

apparently if you put `##` before the `__VA_ARGS__` then GCC will remove the trailing `,` if the variadic arguments are empty (i.e. zero size)

so it doesn't replace it and then immediately fail

ah I thought you found that in libjxl 😄

I pushed a change to my github branch `thebombzen/FFmpeg.git` branch=libjxl

I believe it should work now, if you notice anything else feel free to let me know. if not I'll send an updated patch to the ML

probably better to do `#define jxl_parse_err(...) av_log(..., "At position %d, invalid %s\n", jxlr->gb.index, __VA_ARGS__)`, then you also save ~20 bytes per error

then how do you pass arguments, like, `invalid width and height`

and actually print the invalid width and height

you'd need two separate macros to do it this way, since you can't overload them

er, right. oops

I thought of that too but I got tripped up by the inability to overload

I think it's probably fine but I'll have to check with the devs first

seems like alpha_nonpremultiplied, alpha_triangles, blendmodes, and spot still fail to decode from pipe? `xargs -a main_level10.txt -n1 sh -c 'ffmpeg -loglevel quiet -hide_banner -i -<$1/input.jxl -f null - && echo "OK " $1 || echo FAIL $1' --`

lemme check

level10? that might be the issue

I currently do not parse jxli

though if it's inside a container the prober should work anyway

That's what all are adopting

There are like 3 mentions of this

why avif and jpeg xl doesn't wok fo me

im on windows

Because digiKam needs ImageMagick with jxl support or at least JPEG XL Qt plug-in (according https://invent.kde.org/graphics/digikam/-/tree/master/core/dplugins/dimg ) but Windows version was built without them.

<@!853026420792360980> So, with your current patches, is it technically possible to create a video stream with libjxl in ffmpeg?

No, because several jpegxl files concatenated together is a valid JXL file

and it will eat the stream as the first frame

I don't have an easy solution for this at this time

I believe I will need to invent a way to skip an ANS stream and then it will be potentially do-able

Seems like the next digiKam release (7.7.0) will include libjxl in bundles https://invent.kde.org/graphics/digikam/-/commit/de8e399e0efdb7d45426dd726000bcc1dbbc2b92

Yes, I already tested new Windows build and provided feedback how to avoid crashes I got also under MSYS2. But it will not play animated JXL yet, it will need support in ffmpeg.

digiKam development builds: https://files.kde.org/digikam/ JPEG XL should work out of box there.

Pretty sure my now I ironed out most of the bugs in my parser

it passes all of the conformance tests except `spot` which I believe is actually invalid

<@!765599758559215616> you seem interested in testing this, so if you have any other tests let me know

the problem with `spot` is I believe it illegally lists `modular_16bit_buffers` as `false` which is not allowed in a raw codestream (or any level 5 codestream, for that matter)

we might need to wrap it in a container and up the level to 10

Yep

haven't tested your new patches yet, but on the previous version i had an issue where images with large pre-codestream chunks (e.g. exif, jbrd) would spam "Invalid JPEG XL" something-or-other but still open properly. i think it is correct, but the message needs reduced log level

it was incorrect, it was only identifying it by filename

should be fixed now

all the conformance now passed on pipe input at this point except for `spot` since it's bugged

sounds good

conformance tests are fixed for me too (except spot) but i'm still getting "Failed JPEG XL Signature Check" spam when probing files with big metadata

e.g. `cjxl <(curl https://upload.wikimedia.org/wikipedia/commons/2/25/An%C3%A9mona_de_mar_com%C3%BAn_%28Anemonia_viridis%29%2C_Parque_natural_de_la_Arr%C3%A1bida%2C_Portugal%2C_2020-07-21%2C_DD_07.jpg) x.jxl && ffprobe x.jxl` "Failed JPEG XL Signature Check Last message repeated 2220 times"

i think either the severity of this message should be reduced when the failure is due to EOF, or it should be reduced in general, or maybe it is possible to check if the buffer is known to be incomplete

interesting. any time you see that, that's a bug

at least, that's what I thought

It shouldn't actually be printing ever though, to be honest.

it should never get to this point

<@!765599758559215616> I believe my latest patchset fixes this

``` $ cjxl <(curl https://upload.wikimedia.org/wikipedia/commons/2/25/An%C3%A9mona_de_mar_com%C3%BAn_%28Anemonia_viridis%29%2C_Parque_natural_de_la_Arr%C3%A1bida%2C_Portugal%2C_2020-07-21%2C_DD_07.jpg) x.jxl && ./ffmpeg -i ./x.jxl % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0JPEG XL encoder v0.7.0 9bc1e88b [AVX2] 100 9.8M 100 9.8M 0 0 11.4M 0 --:--:-- --:--:-- --:--:-- 11.4M Read 3385x3385 image, 11.7 MP/s Encoding [Container | JPEG, lossless transcode, squirrel | JPEG reconstruction data | 842-byte Exif | 12091-byte XMP], 4 threads. Compressed to 9083270 bytes (6.342 bpp). 3385 x 3385, 24.82 MP/s [24.82, 24.82], 1 reps, 4 threads. Including container: 9096808 bytes (6.351 bpp). ffmpeg version N-105810-g4ca37b6794 Copyright (c) 2000-2022 the FFmpeg developers built with gcc 11.2.0 (GCC) configuration: --disable-doc --disable-stripping libavutil 57. 21.100 / 57. 21.100 libavcodec 59. 22.100 / 59. 22.100 libavformat 59. 18.100 / 59. 18.100 libavdevice 59. 5.100 / 59. 5.100 libavfilter 8. 27.100 / 8. 27.100 libswscale 6. 5.100 / 6. 5.100 libswresample 4. 4.100 / 4. 4.100 Input #0, jpegxl_pipe, from './x.jxl': Duration: N/A, bitrate: N/A Stream #0:0: Video: jpegxl, rgb24, 3385x3385, 25 fps, 25 tbr, 25 tbn At least one output file must be specified ```

seems to be working in my tests now, thanks

update: just added ICCP support to both the libjxl decoder and the encoder, and tested it

if I don't see anything else I'll send the patch to the ML today

Nice 🥰

https://ffmpeg.org/pipermail/ffmpeg-devel/2022-March/294286.html

Any decent image viewers with JPEG XL support for Linux out there? Don't want to open them in GIMP or in browser...

yes.

EOG if you have libjxl built with the GdkPixbuf plugin

Gwenview.

That can't display JPEG XL files, can it?

doesn't work for me

It can if you have the QT libjxl plugin.

https://github.com/novomesk/qt-jpegxl-image-plugin

damn, that works 👍

http://ffmpeg.org/pipermail/ffmpeg-devel/2022-March/294431.html

Oh boy, the IRC stuff spilled into the mailing list it seems.

I saw this, which peeves me a little bit cause Lynne was present for the discussion about commit access

where it was agreed I would not get it

I'm discussing it with him now though, he's giving me solid feedback

👍

It can be disabled using JPEGXL_ENABLE_PLUGIN_MIME option. But even in duplicate registration, there won't be any problem. For example AVIF is already in s-m-i, but libheif add another registration via another XML. It works together.

<@!886264098298413078> it looks like ur GIMP plugin ignores the ICCP inside jxl files, unless I'm mistaken

which GIMP does successfully read inside of a PNG

i.e. `djxl test.jxl test.png && gimp test.png` produces the right colors, but `gimp test.jxl` directly does not

same is true about firefox nightly, interestingly enough

anyway, fingers crossed https://ffmpeg.org/pipermail/ffmpeg-devel/2022-March/294785.html

I will test later, but are you trying with GIMP 2.99 and not with GIMP 2.10?

I don't know

lemme check when I get home

Because those plug-ins are different and I worked only on 2.99.x version.

2.10, so never mind

JXL and AVIF are now in the nomacs image viewer for good, mainly JXL. https://github.com/nomacs/nomacs/commit/539959ec46e1ecb594aded0d0a7f58412f05b51e