JPEG XL

So, how is review progress going on the JXL integration in ffmpeg?

Sorry, I'm just too impatient 😛

sent patch v10 to the ML yesterday, nothing since

believe me I'm impatient too lol

if you're running git master anyways i reckon it shouldn't be too hard to add a patch?

every new patch I do I rebase it onto master

so yea

Development build of nomacs is showing Exif metadata from JXL files now. Perhaps I should auto-rotate the thumbnail. Or better to leave it in original position?

The thumbnail is in the exif, right? It's not a jxl preview frame?

I believe it is from exif

idea of exif thumbnails is weird & wasteful imo

also looks like it expects to be autorotated, so probably should do that if attribute for that is present in exif

We did it!

https://git.videolan.org/?p=ffmpeg.git;a=commit;h=0008c159562b877700cd9b7c96f941de4ee69af5

jxl is now in FFmpeg git master

<@794205442175402004> Ping everyone and put this in <#803379415106584626>

Yay!

👏👏 👏

<:FeelsAmazingMan:808826295768449054>

<:JXL:805850130203934781><:Stonks:806137886726553651>

epic

Does this mean jxl is in ffmpeg before avif?

Yes 🙂

Somehow.

An excellent argument to get browsers to adopt JXL NOW!!!

Only AVIF parsing is a thing in ffmpeg last time I checked.

https://git.videolan.org/?p=ffmpeg.git;a=commit;h=499e245b856733c3bbcd3ba23b406729343ed5fe

Without alpha, lol

Why do people still do things like "only 420" or "no alpha" or "no color profiles" nowadays, I wonder. It's partial support that leads to crippled de facto standards, because if full support doesn't get there quickly, you have no choice but to use the lowest common denominator if you want interoperability...

currently JXL in ffmpeg lacks a parser, but Lynne plans on writing one

Best thing is, it'll already get media player support thanks to someone who's working on a patch who just submitted one lmao: https://github.com/mpv-player/mpv/pull/10126

that was me

it was very easy

I know, there's just someone on the AV1 server who literally tried to do the same thing, but was too slow lmao.

like it took me like an hour. infrastructure already existed for the most part

it fails all the checks though because they haven't updated to FFmpeg git master yet

Huh, this is interesting: cjxl creates a very slightly smaller file vs using libjxl inside of ffmpeg using the exact same settings. Both are lossless, and yet, they are different in size.

Speed is the same, which is good.

Is there extra metadata present that is causing this? I'm using Git everything from today for reference(Git libjxl, git ffmpeg).

I'd guess just different choices in general since cjxl doesn't necessarily use libjxl

one's a raw codestream, one's inside a container

so you have slight extra overhead

it's already in the git master documentation, it just needs to be rebuilt on the website

I don't know when that is

oh that

`ffmpeg -h encoder=libjxl`

it's not in `docs/encoders.texi`

I should send an updated patch about that

well if you don't have ffmpeg git master then how are you going to use the encoder

It annoys me that https://github.com/mozilla/standards-positions/issues/522 is closed

"I'm locking this conversation as it has passed the new information stage." - well yes, if it's locked then there will not be any way to add new information, like FFmpeg support

mozilla is quite resistant to adding new features as well as fixing old ones <:PepeHands:808829977608323112>

just post it on bugzilla

To be clear, I do think it's good that browsers don't just add any proposed new feature, and that they require it to be a well thought out decision where all the pros and cons are carefully weighed. What is a bit frustrating though is that avif support was added without any discussion (as far as I can tell), while for jxl we had a discussion where the conclusion on mozilla's end was basically "let's wait a bit and see how ecosystem adoption will go" (something that never seemed to be a consideration for avif, which even today has pretty poor adoption outside browsers), which is ok for me but not if you then close the thread so no new information can be added.

I like to think that there are a lot of logistic reasons involved; I recall the debate between mng and apng where the ultimate reason (either for or against) was whether the existing library (libpng) can be reused or not.

avif does have a clear advantage over jxl that it is more or less an i-frame format of AV1 which is already supported

Well, we have adoption now <:kekw:808717074305122316>

JXL: has native ffmpeg support. AVIF: does not have native ffmpeg support.

<:YEP:808828808127971399> seems like Arch will get soon the next lib that will bring jxl support for feh(image viewer that has no border and interface/keybord driven) https://github.com/archlinux/svntogit-packages/commits/packages/imlib2/trunk right now in testing

imv is better

:P

<:YEP:808828808127971399> but imv has AFAIK no jxl support yet

unfortunately

i dont recall either imv or feh having proper color profile conversion support

so theyre kinda both eh in my book

Lossy sadly.

i think ffmpeg is always gonna decode the input before giving it to the encoder unless you use a bitstream filter or something

Soo yeah, better call libjxl separately if you want to use lossless JPEG transcoding.

I'd expect `ffmpeg -i input.jpg -c copy output.jxl` to do a lossless transcode

Maybe that's conflating the idea of a codec and container though, since you couldn't do it with a PNG source even if it's lossless

that doesn't work, you'd need a bitstream filter

this will fail

probably something like

`ffmpeg -i input.jpg -bsf:v mjpeg_to_jpegxl -c copy output.jxl`

I'm not sure if bitstream filters support chaging the codec ID

but BSFs are how you'd do lossless manipulation of AVPackets

without decoding to AVFrames

Mozilla did not add AVIF immediately. It took some time. Technically, it was not very complicated because Firefox already had AV1 decoder and it was able to parse MP4/BMFF files. When they upgraded their own MP4 parser, initial AVIF support was available. I believe they are very busy people, that's why they were not very quick not even with AVIF, the very limited implementation stayed behind the flag long time. Things are not always moving as fast as expected. It may take 2 weeks to implement an improvement, but it may take one year to contribute it to relevant projects. And it may take another two years before it is available to majority of users (until popular distros upgrade all necessary dependencies needed by the new feature). AVIF is not hindering progress of JXL, at least from my point of view it looks so. For me, experiences with AVIF implementations also helps to implement JXL support faster.

> AVIF is not hindering progress of JXL, at least from my point of view it looks so. the comments from the developers seem to indicate otherwise, when they mention they already have AVIF, why use JXL?

Which is a valid point btw, but given that avif isn't a consolidated part of the web platform yet, you could just as well ask why we need avif if there is already jxl

I don't see the problem with having both, the amount of binary size and attack surface that adds to a browser is not significant enough imo.

Step 1: make web browsers accept videos in img tags. Step 2: every video codec is now an image format, because you can just encode 1 frame long videos.

Yes, that is something I have been asking for for many years now

There is no need for avif if you can just use av1 in an img tag

Safari allows h264 in an img tag for a long time now

And Chrome allows arbitrary av1, but only if it is using an avif container

Only in firefox there is no way to use a real video codec in an img tag, apng or awebp is the best you can do there...

and maybe other video players should treat single frame video as without a progress bar (looking at you mpv)

Yes, they mentioned avif too. I feel from their reply standard chicken-and-egg reply. The fate of every new image format is very difficult (majority wait for others to implement it first).

Yes, chicken-and-egg is a very hard problem to overcome. "We'll add support once it is a widely used codec" is not a great way to get wide adoption...

update on this: I just sent a patch to the mailing list updating the docs in `doc/encoders.texi`. It doesn't change any code so it'll probably be merged without too much discussion.

lynne's parser is for something else iirc

Lynne's parser is not for the lossless transcode

and that should be implied, tbh

It doesn't seem ffmpeg currently supports encoding/decoding jxl animations, does it? 😢

I've tried it and no joy…

nope

> https://twitter.com/jyzg/status/1518596030505254912?cxt=HHwWgICsuefCkZMqAAAA I read this twitter discuss, I think I can understand why `twitter user: lyiase` have this opinion, > Sorry, I look at the images and "my subjective" opinion is that AVIF is the better quality. *1 I notice `lyiase` using 2d drawing avatar(anime), and twitter media post have 2d drawing image(anime), so I assume input image probably have chance is `"really non-photographic" non-photo(anime)` content. In my opinion, current libjxl default lossy use `VarDCT`, `pure DCT` is great for `"photo-like" non-photo` and `photo` content, but for `"really non-photographic" non-photo` content, I think `pure DCT` isn't best lossy method. Current av1 have `DCT` and `palette prediction`, `filter`, `CDEF` those features is good for `"really non-photographic" non-photo` content, but current av1 still have some `detail` and `noise` preserve issue. So I think if libjxl can implement quality improve and features for `"really non-photographic" non-photo` content, those improvement can let libjxl increase robustness for different content. > Auto switch two standalone algorithm, `VarDCT` or `delta palette` ,Jyrki Alakuijala. > Apply `VarDCT`, `Modular patch` for `text`, `Modular delta palette` in same image, Jon. > *1 full version post. > https://twitter.com/lyiase/status/1517396470122819584 > Sorry, I look at the images and "my subjective" opinion is that AVIF is the better quality. > When adjusted in Butteraugli, AVIF and JPEG-XL have about the same file size, > but "my subjective" view is that JPEG-XL looks more degraded. > So I don't know if JPEG-XL is a better quality.

Bruh, the guy is testing at abominably low file sizes.

Most people tend to compare at way too low bitrates so they can easily see the artifacts and compare them. The problem is that they then extrapolate their findings to high bitrates, which is not a good idea

For this image, at 0.25 bpp jxl gets a worse subjective score than the others, while at 1 bpp it gets a better score

Question is if many people want to compress their images to the point that there are visible artifacts (i.e. the range where DMOS < 80 or so)

https://aka.ms/AAgr9vh < JXR (tooling) sucks so I created a feedback item for JXL support in Windows

guess we have to wait to even upbote

huh, guess they have to approve it first

Yes, I don't like compare encoder quality on lower file size, for compare quality, use large file size is more reasonable. I really look forward Jon method can implement in libjxl, apply different algorithm in same image is a flexible method. and hope this improvement can reduce surprise output from non-photo content. > Apply VarDCT, Modular patch for text, Modular delta palette in same image, Jon.

av1 prediction and filter features blurry everything on low bitrate, I still don't understand why some people compare av1 on low bitrate and say quality better...

jpeg xl also have Modular delta palette for high appeal use case, but haven't implement on target distance mode.

https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/ec07b1547753864d1fb47eb2747613dddba507b2

more documetnation added

my next plan of action is to have the encoder and decoder properly tag the colorspace used if it's signaled by the bitstream

(instead of, say, an ICCP, which is already supported)

well, matrix won't need to be tagged since it only takes RGB for now

but primaries and TRC could be tagged

https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c32

Doesn't necessarily mean anything. A person was assigned to it a year ago. They are just filing the info in the bug, doesn't mean progress will be made.

Still hoping.

Likely added since the other discussion thread was closed - so that info can't be added.

Yeah, but since more and more important software supports it now, there's more and more of a reason to support JXL <:YEP:808828808127971399>

More reason to pester them <:HaDog:805390049033191445>

Then they'll prob close the bug as wont fix <:ReeCat:806087208678588437>

i prolly woulda closed long ago, absolutely hate when people tell me what to do instead of just bringing information without "SUPPORT EEET NOW"

That's the problem - when you close it then nobody can post new info. Gotta expect people will do that. Either warn them, ban them, or delete their posts. Don't block everyone from providing new information on a post that requests new information. 🤦

Hoping for widespread adoption soon, I got sold when it compressed my 13.9 already compressed PNG to 1.89MB 😄

At a fraction of the time mind you

that sounds suspicious, did you compress it in the lossless mode?

Yes, lossless

It had a lot of uniform grey background and the format found a way to take advantage of it

Was some concept art on gray bg

how did you make sure the original file already compressed? PNG compression rate can vary much by implementations...

(alternatively, you can decode it into BMP---the uncompressed form---and compare with that)

Fair, I will do that

I mean, I think a good enough PNG compressor will exploit it (less so than jxl though)

<:hmmm:853991188452868107> is there already a decoder of jxl in rust? i use this <https://github.com/qarmin/czkawka> to find duplicate pictures that i collect from webcams. Would be nice to have a decoder in rust before i write an Issue and ask for jxl support

nah, there's a wrapper to the C++ decoder though

Sometimes I use Kdenlive video editor. It uses MLT Multimedia Framework which is able to load images via Qt, but must be configured to do so. Commits are merged to MLT and Kdenlive, so it will be possible to use JXL and AVIF with Kdenlive.

2023: All software except web browsers support JXL <:kekw:808717074305122316>

I don't mind browsers being careful to add new codecs, but the difference in treatment between avif and jxl is quite remarkable.

wonder how much of that is timing

like if i'm a browser dev and i start to perceive the image compression community as coming up with a better format every few months, i might become hesitant to adopt new ones

Yeah, but I don't think it's really that.

I suspect it's more that mozilla, google, microsoft and apple are all members of AOM, so they gave avif a 'fast lane' treatment and they don't want to be seen as the ones who are the first to add a 'competitor' of avif.

right, i forgot how iirc someone practically said that?

is anything stopping AOM from endorsing JXL?

"not invented here", and maybe also hardware companies who might be worried that their av1 chips become less valuable if jxl becomes successful.

Make jxl chips then /s.

That might happen at some point, but that doesn't help the investment in av1 chip development

Not that I think av1 and jxl are real competitors, the overlap in use cases is not that big imo

also it's not like av1 needs the image usecase to be worth investing in for hardware development

Exactly. But maybe a hw manufacturer aiming at cameras thinks otherwise.

Android image viewer <:PepeSad:815718285877444619>

The problem comes from the fact that previous investments in HEIF hardware are making corporations think about hardware reuse.

I believe the problem could be solved in the future if future AOM standards were made more openly.

Joining the AOM is not so cheap, I was considering to do it just to see what's going on, but costs quite a bit to become an AOM member

Hopefully browser vendors are just a little bit scared by the 0.X status of libjxl, and they will jump on it soon after 1.0

And AVIF still took a couple years to be implemented. The spec was only finalised in Feb 2019, while JXL was Oct 2021 (though Dec 2020 if you want to go for bitstream freeze.)

Edge still doesn't support AVIF, could be an odd technical architecture problem though

Is it just me or the Microsoft's AVIF implementation, that you can install from MS Store, is completely broken?

Sadly, this world is about money, with all the negative consequences we can imagine. I've been involved in changing that for years.

It costs 822 EUR/year to be an ISO member (in Belgium)

It costs 30000 EUR/year to be an AOM member

Imo it's stupid that you have to pay anything to be able to contribute to new standards

it's a gated community and they have no interest in tearing down the walls

doesn't that depend on company size?

(well, at least you can read AOM specs for free eventually...)

I guess, I cannot find a price list but that's what it would cost for Cloudinary.

Geez

W3C is also not cheap

I wonder why not all standards can be done like how the IETF does it

Free participation, free specs

After all, all it takes in infrastructure to design and maintain a standard is basically a git repo and maybe a mailing list.

And then some hosting to publish the specs and do some general knowledge dissemination related to the specs

Total operating costs could be pretty close to zero.

I know how ISO manages to have significant operating costs: they have staff and a bunch of bureaucracy that requires staff. Also they probably pay way too much money for the proprietary platforms they're using to manage documents etc.

I don't know however what happens with the AOM membership fees. I kind of wonder what that money is being used for.

Perhaps a fund to fight patent trolls?

how about ECMA compared to ISO?

I had an impression that ECMA feels much more open than ISO (both in terms of standard availability and participation)

I dunno, https://www.ecma-international.org/about-ecma/join-ecma/

That would be 35k swiss francs for Cloudinary if they don't want voting right, 70k if they do want voting right

ECMA does seem to offer non-profit membership for free

(don't know if this also covers individual experts though)

Yes, I guess, but then you need a non-profit organization without for-profit members

Scientific journals have a similar problem of justifying their cost. Nowadays it is possible to run a journal with very low operating costs, such as arXiv, but the major ones still cost eye watering sums, which basically means that you need to be part of a large organisation to have decent access to current research.

yes, this is probably an even bigger problem because it affects all of science

Not completely, but broken, yes. And it seems that MS doesn't care, as usual.

Microsoft's AVIF is completely broken. The colors are all shifted and wrong. Bit depth more than 8bpc doesn't work at all. Lossless images have strong green or purple tint. Thin lines are displayed pixelated for no reason. It's completely unusable. Gimp for example displays my test files correctly.

based microsoft, discouraging AVIF adoptation with bad implementation and thus encouraging JXL

Perhaps MS just can't do it right. Their PNG implementation was quite broken for many years.

That's not how I think of it.

They'd rather push HEIF instead 📛

Or JPEG XR, lol

Speaking of HEIF/HEIC, MS does the same color shift there too, so the colors are wrong as well.

Maybe they didn't implement proper color management? And thin lines getting pixelated could be chroma upsampling being implemented with just nearest neighbor instead.

So it's just a lazy implementation like PNG, where alpha channel was not working in MSIE for years. Anyway, I don't use any color management. I have just a basic 8 bpc screen, nothing fancy. Everything is set to default. So I suppose the RGB values of pixels should just stay as close to the original as possible. Is that too much to ask for?

those are based on video formats, which tend to have their own color gamuts and transfer functions for various reasons

"8-bit RGB" can be 709, sRGB, Adobe RGB 1998, Display P3, DCI P3, etc.

yeah, if we were using (a single) absolute color space from the start things may have been less worse, but that didn't happen so here we are

For quite a while, sRGB kind of was the thing you could safely assume

But especially with the transfer curves there has been a lot of confusion and bad implementations

E.g. apple doing gamma 1.8 while pc does gamma 2.2, and then that sRGB transfer curve that is kind of weird

I don't really understand the concept of color profiles, but considering my pictures don't have any color profiles attached, the RGB values of pixels should generally stay intact. I don't want any color management messing with my RGB values.

Without color space, your RGB values may be intact but what they mean is undefined

at *some* stage the color conversion should happen, it just tended to happen behind the scene for a long time

if you buy a new display there is surely a color profile attached and the OS is supposed to use that

Some will assume sRGB, some will assume "whatever is easiest for me, i.e. assume I can just send the pixel values to the screen whatever the screen color space is"

Untagged images and videos are basically a recipe for inconsistent results

Which is why in jxl we made it pretty hard to do that, you _can_ have an image in "Unknown" colorspace, but libjxl will not produce that and it will probably refuse to decode it too

After all a digital picture is just an array of numbers. The purpose of image codecs is to take those numbers, compress them somehow and then decompress them to get the exact numbers (in lossless formats) or something very close (in lossy formats). And this apparently failed for me in Microsoft's AVIF and HEIC implementations.

Actually in our view, lossy formats have to do more than just reproduce numbers approximately. In the jxl philosophy, lossy compression is not about numerically being close (e.g. psnr), but perceptually. And that requires that the encoder knows what the numbers mean.

But I suspect the problem you have with the MS avif/heic implementation is something like the encoder not properly setting the colorspace metadata and/or the decoder not properly taking it into account, in a way that the errors don't cancel out.

Too often when people lazily implement a new codec, they're happy when it kind of works on some test image, but they often forget to implement everything that is needed, like properly handling alpha, grayscale, color management and animation.

I will try to do some more experiments, this is kinda new problem to me. I've noticed that cjxl assumes sRGB in untagged pictures. That's fine. It seems that sRGB is considered to be the de facto default color profile, so it behaves neutral.

Assuming sRGB for untagged is also the correct behavior according to e.g. W3C.

I recall older web browsers interpreted correctly tagged sRGB PNGs somehow incorrectly, so untagged (but sRGB-coded) PNGs were much more consistent for a while

But cjxl always turns untagged input into tagged output so the ambiguity evaporates.

maybe the same sort of thing is still happening now

ImageMagick still produces PNGs that are incorrectly tagged as gamma 2.2 with sRGB primaries, and it itself interprets that as if it's sRGB.

using gAMA chunk instead of sRGB chunk (which overrides gAMA)?

The mean SSIM formula afaik is one of the best measurements for perceptual differences

Yes

SSIM is not that much better than PSNR

Mean SSIM lmao.

It's OK when done in a perceptual space like Lab, with multi-scale, and with better pooling than just averaging

But single-scale mean SSIM in RGB or YCbCr is not very good

Ideally, we'd weigh metrics based on the worst error score 😛

Not much having a pristine image if the sky has banding and blocks around stars.

Max norm is best for fidelity, but a lower norm (but still higher than just arithmetic average) correlates better with subjective results

I think the goal of lossy compression is quite simple, the imperfections should be as unnoticeable as possible. But that's a subjective thing, not very easy to measure.

if the image gets displayed for a short amount of time, you can afford more imperfections 😉

I guess this applies mostly for video codecs. Those can get away with more imperfections. In that case it doesn't look like a good idea to use video codecs for static pictures.

I agree, yet that is exactly what WebP, HEIC and AVIF do: use a codec designed for frames shown for 40ms for still images...

there was a period of shortage of good still image formats and (otherwise suboptimal) I-frame formats filled the gap

There was JPEG-XR which was pretty good, but since nobody asked for wide broad support, we never got it.

That's the difference: there are now people who are actively pushing for better formats 😛

a(n apparent) failure of JPEG XR was surprising to me

XR is not that great imo. It aimed to be somewhere between old jpeg and jpeg 2000 in both compression and complexity

unfortunately j2k was too slow IIRC, and for XR MS could have done the same thing Apple did for HEIF/HEIC

And while it's nice that Microsoft did standardize it, they also abandoned the software for it, so all that is available is some buggy unmaintained implementation from 10 years ago

J2K was slow in 2000 when it was introduced, but for today's cpus it's not that bad

But the only decent j2k implementation is proprietary (kakadu), that also doesn't help

The foss implementations of j2k are pretty bad, which gave j2k the reputation of "meh"

When testing kakadu j2k, it usually does do similar or better than webp, which is not bad considering it is 10 years older

I mean the format is

But any format is only as good as the amount of love its implementations get

Without mozjpeg, jpeg would suck significantly more, for example

I think that plain old JPEG is still considered to be good enough by most people.

well JPEG took a long time to reach that point

keep in mind that JPEG was first released in 1992

JPEG was a quantum leap: photographic images went from basically uncompressed to 1:20 compression. It made photos on the web feasible, as well as digital cameras.

No new format can deliver an improvement that large

But when HDR becomes more mainstream, JPEG will no longer be "good enough"

At least not the current implementations of it. JPEG can actually do HDR, but updating the existing decoders is as much work as adding a new codec.

Same with alpha btw: nothing in the original jpeg spec says that 4 component images can only be interpreted as cmyk, it would be perfectly possible to add a marker to indicate that it's rgba.

But again, existing deployments would get it wrong, so it's not gonna happen.

The original jpeg spec was exceptionally far-sighted: they anticipated a need for 12-bit, 4-component images. Only nobody implemented the full spec, so we're stuck with the crippled de facto standard.

As I'm mostly interested in lossless compression, I'm looking at the lossless options of the available codecs. I was using multiple formats, BMP, PCX, GIF (for still images) and finally PNG, which I'm using until now. What I like about PNG, it has multiple indexed color formats and I have a full control over it. I can also easily edit the color palette. None of the modern codecs seems to provide such functionality.

isn't the palette a means to compression and not necessarily anything else

In jxl we see palette as a coding tool, not a property of an image. We could change that and expose palette in the api, but it would require quite a bit of plumbing to allow palette editing without re-encoding the indexed data.

Palettes in jxl can be used for an arbitrary number of channels, and single-channel palettes can be quite useful in cases where not the whole range is used.

Palettes can also be used after RCTs, and can be done globally on the whole image but also locally on single groups

The palette itself is compressed too, it's treated as an nb_colors x nb_channels image

Also indices outside the range can be used and they have a predefined meaning, so a 0-color palette is actually still useful.

And then you can have palette entries that are not absolute colors but deltas w.r.t. a predictor

So all in all it's a way more powerful coding tool than just the 8-bit absolute-colors-only palettes of PNG and GIF.

The purpose of color palettes was changed, but the concept of indexed colors originated in the old days, when computers could display just a limited number of colors at the same time.

Yes, you can see that in PNG which has a chunk to store a recommended palette to use to render a full-color image with.

I think the best approach is if image editors just detect low color count and then offer an interface for color remapping, without seeing it as something that is tied to the image format directly.

That would also allow to get rid of the arbitrary limit of 256 colors

300-color palettes can still make sense and can result in great compression in jxl

PNG is kind of bridge from the ancient formats like BMP or PCX, that were often in 16 or 256 colors. But PNG is still relevant today and can store those old pictures exactly like in the original formats.

It seems JXL could do that too but it's kinda more complex.

Well a jxl encoder could take a png8 and translate the palette directly to a jxl palette transform without going to rgb(a) pixels first. But we don't have that in the libjxl api atm.

Decode-side, it could be detected that a global palette uses at most 256 colors and no deltas, and it could then be exposed as being "the image palette"

But it's a bit of a niche/legacy functionality that isn't likely to get prioritized anytime soon, I think

I see. At least there is an theoretical option.

Lossless WebP for example uses color palettes too, but those seem to be completely hidden.

I know Firefox for the longest time only did colour management of tagged images, so tagging them as sRGB would cause them to get corrected while page elements and untagged images were left "as is"

That doesn’t sound like a very radical or intrusive thing to change/add

Why is the actual spec so supposedly difficult to implement properly? Doesn’t jpeg have a very well defined spec?

That's not the issue. The thing is the first implementations only implemented the parts of the spec that they considered most useful at the time (and in case of arithmetic coding, the parts that they could legally use without royalties)

"very well defined" is, at best, a wish xD

finalized my colorspace patch fix for FFmpeg, hoping it's merged soon

Krita digital painter/editor application added code to support JXL: https://invent.kde.org/graphics/krita/-/tree/master/plugins/impex/jxl It seems they use new API functions (it will not work against libjxl 0.6.1). When you have time, test/review their implementation.

I noticed it because of the bug report https://bugs.kde.org/show_bug.cgi?id=453572

Nice!

I would like to post this image: https://cdn.discordapp.com/attachments/856383302097043497/974185224206422086/unknown.png

and that's _before_ the actual compression, right? so assuming lossless yuv444?

what does "visual threshold" mean? 😉

deltaE < 1 🙂

https://en.wikipedia.org/wiki/Color_difference#CIEDE2000

obviously that difference metric does not take any spatial properties into account, it's just saying if two colors can somehow be distinguished or not

I guess https://github.com/libjxl/libjxl/blob/main/doc/software_support.md could use an update. Anything to add besides ffmpeg and krita?

(and what would be good links to use for jxl support in ffmpeg and krita?)

Regarding JPEG XL in FFmpeg, this could work: https://github.com/FFmpeg/FFmpeg/search?q=jpeg-xl&type=commits

Or a media report: https://www.phoronix.com/scan.php?page=news_item&px=FFmpeg-JPEG-XL-Lands

As for Krita, this might do: https://invent.kde.org/graphics/krita/-/commit/13e5d2e5b9f0eac5c8064b7767f0b62264a0797b

As for image viewers, Tachiyomi (a comic/manga reader for Android) can read locally stored `.cbz` and `.cbr` archives with JPEG XL pages. https://github.com/tachiyomiorg/tachiyomi/releases/tag/v0.12.1 https://tachiyomi.org/

https://professional.dolby.com/siteassets/pdfs/ictcp_dolbywhitepaper_v071.pdf

SumatraPDF users can vote https://sumatrapdf.canny.io/feature-requests/p/support-jpeg-xl-image-format

As a KDE user, hoping Debian developers will package libjxl soon (I'm not a Debian user but it would be nice for Debian contributors who looking forward to play with <:JXL:805850130203934781> , I'm using Arch)

they did

it's in experimental though

Ah, good to hear that

PDF doesnt support JPEG XL. They said on 2026

Can't login there (using GitHub) for some reason.

Maybe it is just broken in Firefox 😦

Yeah, it worked in Chrome/Edge

Hate when developers don't test their code in Firefox

Pdf association said JPEG XL is planned after five years, not now.

where did you find info on what the plans are for PDF?

https://youtu.be/cY5QNN946QI

31:54

Oh, that's just someone making a guesstimate, not sure if that means too much

libvips 8.13 will support ICC profile load and save plus linear float sRGB in JXL https://github.com/libvips/libvips/pull/2815 any review very welcome etc. our wishlist is now just: - exif and xmp (I see this is already in main, woo!) - progressive (eg. tile-based) read and write

The "vipsdisp" image viewer supports JXL: https://flathub.org/apps/details/org.libvips.vipsdisp It could perhaps be mentioned in software_support.md it's quite a fancy viewer: it decodes image tiles asynchronously at a range of scales to a set of textures on your GPU using a pool of background worker threads then as you pan and zoom, updates the screen at 60 fps from that sparse tree of textures result: 60fps pan and zoom of huge images (eg. 300,000 x 300,000 pixels or more) on a modest laptop It has some visualization options too, eg. false colour, log scale, brightness and contrast, animation support, plane-separated support, OME-TIFF etc.

does it support 10 bit in fullscreen or dithering to 8 bit?

it uses the gtk4 GL stack, so it's just 8 bit, unfortunately -- perhaps they'll improve this you can view HDR images and adjust the brightness and contrast as float values, for what that's worth

Hmm, this is interesting in ffmpeg(git ffmpeg, git libjxl): `[libjxl @ 0x30b97c0] Failed to set JxlColorEncoding` This happens when encoding lossless using ffmpeg libjxl.

currently working on a patch rn to redo the color logic in the wrapper

so stay tuned (TM)

or rather, it's currently dependent on *another* patch I'm working on

once I get that merged I can start on it

so Firefox JXL support is allegedly only available in the Nightly version of the browser behind a flag right `image.jxl.enabled` well finds out the flag doesn't work on the Unbranded Builds (which are marked as Nightly in the Help->About Firefox page) <https://wiki.mozilla.org/Add-ons/Extension_Signing#Unbranded_Builds>, rip

I see.

Yup, can confirm (Vulcan using Nightly as daily driver so not a big hurdle personally but still hoping for support for non-nightly Firefox to aid wider adoption)

However, the flag might be brought to mainline builds relatively soon due to the improvements in support.

Let's hope so

first I heard of unbranded builds

I think it is a relic of the times when there were issues with distributing Firefox due to the Firefox name and logo being trademarks.

Which is why you got things like iceweaslie originally. I'm pretty sure all of the legal issues have been worked out now though, so people just distribute normal Firefox.

i think it also allows unsigned add-ons

does some kind of javascript/wasm decoder for jxl images for users' browsers that don't have the a jxl flag enabled exist? if it does, why isn't it on the jxl art website? admittedly it seems somewhat pointless to serve potentially megabytes of wasm over the wire just to load smaller images... but i was thinking it might make browsing the jxl art gallery more "hassle-free" for casual users

what about using embed.moe

There is a wasm jxl decoder, it can even do HDR using the experimental HDR canvas

<@811568887577444363> we should probably demo it on jpegxl.info too.

actually I couldn't get https://eustas.github.io/jxl-demo/ working either

It's working on Android Chrome beta

It works in Chrome/Chromium if I enable experimental features flag. In Firefox the picture doesn't show (not sure what feature it would actually need).

It uses the HDR canvas

Which is currently experimental, the normal canvas is SDR

For Firefox, you need to use nightly. Then, go to 'about:preferences#experimental', and scroll down until you see the checkbox for JPEG XL.

Yeah that will make jxl work directly

This demo is a wasm-based polyfill

Could probably be made to use the standard SDR canvas as a fallback so it works on every browser regardless of flags set

In the current demo it uses the HDR canvas, which is currently an experimental feature of chrome only afaiu

I saw it was using canvas so I was confused as to why it didn't work. Seems odd that it requires HDR canvas, should work with both.

well that current demo code does this: let ctx = canvas.getContext("2d", {colorSpace: colorSpace, pixelFormat: "float16"}); let pixels = ctx.getImageData(0, 0, w, h, {colorSpace: colorSpace, storageFormat: "float32"});

which I'm quite sure will not work with a normal SDR canvas 🙂

Debian is and has always been cringe

Arch gang

Why

eternally out of date

I use Debian unstable

so only slightly out of date compared to all other distros? 😄

I use git versions for the things I am interested in, debian unstable is good enough for the rest imo

I run unstable as well. I use flatpak for most of my applications though, which keeps them up to date.

The big one that I don’t is Firefox, as I use one too many extensions that do IPC.

I'm not entirely sure that the place there is the right ask for improvements to github, but I made this: https://github.com/github-community/community/discussions/18139 to propose to allow uploading jxl images with their file extension..

please upvote, if you think it is a good idea to allow this...

Using Arch testing + unstable KDE + embracing new formats like JXL here

Vulcan can be very extreme in term of early adoption of technology <:ChizuWink:857418269647700003>

https://twitter.com/jensimmons/status/1534624072197341185?t=LK8sbe6vir4_lvWAo5h6wg&s=19

Poll is phrased quite ambiguously (those are two very different questions), but still, might be useful to use this opportunity to tell Safari devs that people want to use jxl...

The poll was not formulated well: for the first question, the answer can basically only be jpeg/png, since those are the only formats with truly universal browser support, so you'll _always_ have to provide a jpeg/png fallback. The second question is a very different question though.

I haven't tried this in detail, but it seems like it...

I would like to remind about expiration of the JXL flag in Chrome. Canary branch is already 105. ```json { "name": "enable-jxl", "owners": [ "deymo", "firsching", "lode" ], "expiry_milestone": 105 }, ```

<@795684063032901642>

I agree that it is about time for bumping the expiry milestone, wip here: https://chromium-review.googlesource.com/c/chromium/src/+/3706869

what's the eventual plan? say, is libjxl 1.0 a requirement?

for what?

uh, enabling it by default?

honestly I don't know much about Chromium development process and I guess there would be fractional rollout as well though

I think the specific libjxl version has little to do with enabling the flag by default (or eventually removing the flag). Those are somewhat independent, if I understand correctly: if there would have been a strong interest to enable the flag by default, chrome could have used a pre-1.0 version. (There are some requirements on security and stability on a release used for chrome, which is why we don't always run the latest jxl version in chrome, I guess)

https://krita.org/en/item/first-beta-for-krita-5-1-0-released/

https://invent.kde.org/graphics/digikam/-/blob/v7.7.0/NEWS JPEG XL should work out of box in those installers. Download: https://download.kde.org/stable/digikam/7.7.0/

https://www.reddit.com/r/kde/comments/vinqe7/digikam_770_is_tagged_and_will_be_released_in_a/

does anybody have any news about Firefox and JPEG XL or is it still the status quo?

<:Sadge:815191758152663062>

rip

Still the status quo afaik.

seems like the Firefox derived Pale Moon browser is preparing to include JPEG XL: https://repo.palemoon.org/MoonchildProductions/UXP/pulls/1928/

Bigger question... why don't they submit their work upstream and get it working in FF so it can filter down?

i thought about it but there really isnt a point to

my firefox jxl patches are a year old

happy birthday

<:poggies:853085814032302122>

back when we still had hope

Browser adoption may not be going as fast as hoped, but I still hope it'll get there eventually (possibly when we have a libjxl 1.0). But general adoption is going relatively fast and well imo.

Things will obviously take time, but I can imagine that in 1-2 years, giants like Adobe and Microsoft could support jxl out of the box in their products. At least I am hearing credible rumors that go in that direction. Only from Apple I get no signals at all, but that's to be expected.

Well I know they're looking into making a hw implementation of jxl, which would be mainly used in cameras I suppose. Hardware inherently moves a lot slower than software though.

Yes, that one Japanese company.

OS support takes a LONG time. That will take a while. I would guess within the next year some cameras will start adopting it. Chrome will likely be the first browser to adopt - hopefully this year. Firefox will likely have to get pushed to do so afterward. Safari utilizes OS-level support for images so it will be a while before they add it (it took a long time to get webp added and AVIF is supposedly in the works).

Literally all that browsers want is a reliable decoder. Preferably a simple one that doesn't have a million dependencies.

Any improvements you make to the encoder won't affect browser adoption at all.

Or to any APIs that are only useful for encoding

Does the latest release of libjxl provide a reliable decoder API that browsers want?

Well <@795684063032901642> and co are doing both chromium integration and the libjxl api implementation, so I think we do the things needed for browser adoption

Decoder dependencies and binary size were even considered already in the bitstream design phase

One thing that makes browser adoption trickier is that we can do progressive - decoder apis are a lot simpler if it's just "bitstream in, final image buffer out"

https://www.phoronix.com/news/FFmpeg-5.1-Released

FFmpeg 5.1 was released with JXL support

How does it integrate with a libjxl version that does not exist yet

The git version has called itself 0.7 for a while now

^

that's mostly to make it fail with distro-packaged 0.6.1

this is a directshow filter that allows you to open images in direcshow media players in windows and while it's support for jxl was added back in 2021 I figured I would still post it here https://github.com/v0lt/ImageSourceFilter

let's you basically use your media player as a image viewer (if it's directshow based)

I think we need to have more activity on https://bugs.chromium.org/p/chromium/issues/detail?id=1178058

having more comments there would help Chrome to understand the basic attitude for JPEG XL (vs. AVIF)

currently they see that JPEG XL is confusing people, and they themselves don't understand the value that JPEG XL brings

this confusion is supposedly slowing down AVIF adoption

what?

updated version

you don't get with the english, because the authors want to left it blank for some way

ok good

Can you post what you get searching jpeg xl in Google English

https://github.com/kleisauke/wasm-vips, the WebAssembly binding for libvips, is currently experimenting to support JPEG XL images, see: <https://github.com/kleisauke/wasm-vips/pull/21> It can be tested on this playground: <https://wasm-vips.kleisauke.nl/playground-jxl/>, ~~though encoding doesn't seem to work for now (due to <https://github.com/libvips/libvips/issues/2987>)~~ **Edit:** this should be fixed now, see PR <https://github.com/libvips/libvips/pull/2988>.

there's a flag in about:config in ff, `image.jxl.enabled` though when i turn it on i still can't view jxl images in browser

i've heard it only functions on nightly, but then i wonder why they put the flag in the dev version if it doesn't work

thanks

ill wait a bit, its likely going to be compiled-in soon

soon tm

it's been like 2 years

They apparently consider it experimental, so they use a conditional check if 1. the flag is set, AND if 2 the browser version is nightly. Maybe it was an accident and they meant to do an OR-check. Or maybe they are worried about exploits and intentionally want to prevent from people "just turning it on", but that's a far fetched guess.

it's likely mostly that they don't want to add binary size for default-off features, I suppose

that makes also a lot of sense

do you know when they added the flag

2020 ?

if it's only recently added then it will take even longer

<https://bugzilla.mozilla.org/show_bug.cgi?id=1707590>

1 year ago

opened 2021-04-26

inactive until 8 days ago

https://phabricator.services.mozilla.com/D154154

`Bug 1707590 - Part 4: Add references to libjxl and highway in about:license r=glandium` `Authored by saschanaz on Tue, Aug 9, 8:23 PM.`

might be soon then

I am admittedly not up to date on the progress being made but from what I understand browsers are still waiting until a stable decode API is promised and provided, right? And as far as progressive goes, I assume it would have to be implemented the same way all other image decoders are implemented in web browsers, by looking at what API browsers currently use to decode JPEG and PNG for example, and provide equivalent functions for JXL. Even non-progressive-encoded images are decoded progressively by browsers. You can watch them load from the top down to the bottom. Updating as new data comes in.

from what i remember every format is done very differently (in firefox)

lmfao

https://9to5linux.com/krita-5-1-released-with-jpeg-xl-support-full-webp-support-psd-improvements-and-more

Krita 5.1 now has JXL support.

i really really like that mascot

Sus

https://www.reddit.com/r/jpegxl/comments/ws4jim/jpegxl_on_by_default_in_thorium_chrome_optimized/

https://www.omglinux.com/krita-5-1-0-released-with-webp-jpeg-xl-support/

I'm considering it a good sign for the broad adoption of jxl that software like Krita is announcing jxl support now already (1.5 years after informal bitstream freeze, 5 months after ISO/IEC 18181-1 was published), at the same time it is announcing WebP support (11 years after it was created).

https://blender.community/c/rightclickselect/K8pn/?sorting=hot

I added a comment to that <:kek:857018203640561677>

https://github.com/image-rs/image/issues/1765

I am using Kdenlive video editor and JXL images can be now used as input. https://kdenlive.org/en/2022/08/kdenlive-22-08-released/

Adobe has now posted on the Chromium bug as well and are requesting support for JXL and announcing one of their products will soon support it! https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c61

I read the entire libjxl code in 22:58 minutes with music

130.000 deletions in libjxl-tiny

That's pretty big news about Adobe. I have been wondering about them, because they haven't really done much with HEIF or AVIF. Very exciting

Not really, they've already signaled support for it ( https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c19 ), along with Facebook/Instagram ( https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c18 ), Smugmug/Flickr ( https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c23 ), The Guardian newspaper ( https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c27 ), and CDN Cloudflare ( https://github.com/mozilla/standards-positions/issues/522#issuecomment-852891626 ). Of course Cloudinary CDN is also interested being a major backer of it and I've seen a few other CDNs show interest as well and are watching carefully. It takes a while for Adobe to support new formats so it's only a matter of time before Photoshop and their other software gain support. I've also heard of internal interest from photo sites like Pinterest. I know Adobe already supports AVIF. Not sure about HEIF.

A public announcement that it will be supported in a future Adobe product is a stronger signal than an expression of interest though, so it's a nice step forwards.

(I already knew this before, but only from sources that asked me to keep it confidential)

It's really implied that it will be supported by their own software when companies express interest in it. Would be strange to promote it then not support it. As pointed out on Reddit, the next big piece of support would be the camera manufacturers chiming in.

They likely need time. There is no hardware implementation yet atm.

intel chimed in now too. build the wave, ride the wave!

Yep, Intel is in support: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c64

Well, hopefully. I looked up the name and there is a person with that name who works for Intel, but a Gmail account was used, so can't be 100% certain.

afaik that's still correct. redhat supposedly has people working on it, which would definitely be for wayland, not x11.

<https://gitlab.freedesktop.org/wayland/weston/-/issues/467>

and somehow color management is still bad in chrome

4 years <https://bugzilla.mozilla.org/show_bug.cgi?id=1539075>

4 months <https://bugzilla.mozilla.org/show_bug.cgi?id=1765908> for QOI

what's taking so long 🕘 they already added AVIF

well don't count on them adding qoi lol

mozilla already has rejected mng in favor of apng, for many reasons but including a much larger binary footprint; avif is probably similarly benefited from that

i think i know the reason

users need to come into contact with the format regularly for them to consider adoption, niche projects are not a priority

trying to see this from a developer priorities standpoint

unlike image viewers which are quick to adding them, since their purpose is to view things

not browse the web

if the formats i listed were to be supported right now nobody would really notice except the developers and everyone here

and the people that know about the formats

which is a small amount of internet users

Formats like qoi and mng don't really bring anything useful for the web imo. There's nothing you can do with them that you can't also do better with something else.

So it makes a lot of sense for browser devs to push back against those.

However I do think jxl is very useful for the web. It does many things better than anything else that is currently available on the web platform.

A photographer and Krita HDR developer are supporting JXL on Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c66

"a photographer" <:Thonk:805904896879493180>

truly

is there any deadline for the chrome bug tracker, or is it just a sit and hope for the best kind of thing?

The chrome review thing is on Monday Aug 29th, so if you want to influence that, I guess that's a deadline (and I don't know what time that review is, but probably better to not wait until the last moment).

I don't have anything to say myself, I'm just spectating it really hoping it goes through

though I would assume discord is going to be another hurdle, with only supporting a few specific image formats for their servers to embed

can't even embed animated webp's lol

there will always be a long tail of software that is slow to adopt anything new

I just hope this chrome review is not going to lead to a "no, avif is good enough" position. I'm of course hoping for a "yes", but I'm concerned that "no" or "let's wait" are likely outcomes too.

As far as I understand, it's the avif proponents who initiated the review in the first place, and I'm assuming they did not do that to get jxl support enabled, but rather to remove what they see as an obstacle to avif adoption.

Honestly, I see nothing interesting about AVIF, it's just another lossy compression, so we could just use WebP instead. I'm not going to be using AVIF any time soon.

I suggest that anyone add specific info that some on the other popular applications have JPEG XL support already: IrfanView since 2021-12-01 https://www.irfanview.com/history_old.htm digiKam since 2022-06-26 https://www.digikam.org/news/2022-06-26-7.7.0_release_announcement/ qimgv since 2021-09-22 https://github.com/easymodo/qimgv/releases/tag/v1.0.0 I also know that that darktable is preparing JXL support too ( https://github.com/darktable-org/darktable/pull/10044 ) and they are also quite known/popular application.