JPEG XL

Will pdf support including jxl images in future? Who decides about it?

If pdf includes jxl support then these browser vendors would be forced to include jxl. Because opening pdf in browser is a common feature.

The Krita developers are very skilled, I saw their code. It is clear they are exploring many libjxl possibilities but as early adopters, they are running into issues. For example they tried CMYK with JXL ( https://github.com/libjxl/libjxl/issues/1719 )

Krita supports JXL animation but they cannot support animated AVIF such easily. That's because libheif library is used for AVIF support and it doesn't support animation. It is weird situation, because in animation, AVIF would manifest power of AV1 compression.

If I know who are those anti-JXL, pro-AVIF "proponents" I'd suggest them that instead of hindering other format(s), they can work on improving AVIF support in various places in the first place. They have many areas with huge potential of improvements and their effort would be appreciated there by consumers/customers/end-users. What I do not understand is that some Google people are involved to work related to AVIF and other Google people are close to work on JXL. It looks like Google vs Google.

The browser/codecs team within Google is involved in AVIF. The Research team within Google is involved in JPEG XL. Two very different teams. The one involved in AVIF has control over Chrome decisions.

There is another viewer vipsdisp, which (according the description) supports JXL https://www.reddit.com/r/gnome/comments/wtpzrp/new_gtk4_image_viewer/

The Google employees have said in the past that there is little to no communication between different groups/departments within Google. I'm sure this is to reduce the chances of unions forming but it also hinders the progress of the departments. I've noted in the past that Google works on a number of standards and recommendations (IAB advertising, web performance, etc.) that other parts of Google ignore - that's the reason, they don't communicate much.

Additionally, they spent a decent amount of time complaining about JXL a while back for very minor things, but did nothing to correct the record about AVIF. I've pointed out that there are numerous news sites out there that incorrectly labeled and acted as if AVIF were a replacement for JPEG. It is not, and the proponents would only state that THEY never said that, which is true, but doesn't fix the problem of the ecosystem incorrectly promoting the format's purpose.

not just standards, but I've heard that there are at least 20+ different mature configuration languages inside Google, often developed in-house per each department (lol)

WebP is absolute garbage for lossy compression vs proper AV1 though.

i plan to add jpeg xl support to my own image viewer I've been working on recently

It might be but WebP always works at least. AVIF relies on different AV1 profiles and extensions and those have to be supported by the decoder to work. The infamous example is native AVIF support in Windows, which is pretty broken at this point.

To be fair, the whole HEIF implementation in Windows is broken. How long it took Microsoft to get PNG decoding right? 20 years?

It is a fact that MS doesn't have excellent AVIF implementation. But we see it because there are other implementations and we can compare them between each other. We can see if independent developers implemented features correctly and how they understood the specification. Different implementation actually improves the format's specification because uncertain things can be further clarified and better explained. It is harder to see differences when everyone use the same library.

That is true, but imo the main causes of trouble are not decoders implementing the codec incorrectly, but one level higher, applications not properly implementing the 'surrounding' functionality besides decoding a pixel buffer: doing proper color management, orientation, not ignoring alpha or the K of CMYK, dealing with the option of more than one frame, etc.

Yes, there are also problems on the higher level. For example my implementations are also incomplete. However, in case of MS, they have problem in YUV444 -> RGB conversion. And when they decode AVIF which is already in RGB, they performed unnecessary YUV->RGB conversion and changed colors.

Yes, that kind of thing happens when coding tools like color transforms are left as an application responsibility...

I that regard, the design of JXL seems to much more robust.

New versions of PDF sepcs is written by dev. group under ISO probably with Adobe in the lead. Note that they could mandate in the next version of PDF specs to require JXL, but that would only be necessary if the viewer/writer effectively supports that PDF version. As a lot of bloat was added to the latest PDF standard (with exception of Acrobat) most viewers and especially writers don't care about a lot of features that were added in PDF latest versions.

Modular currently suck at speed 7

Super blocky

The compression is improved

But i suggest you to upgrade

Jon

To study better quality of both modes

what I don't understand is the whole reason there's a war

why we have to go "but we have image format at home"

I really don't see the particular reason AVIF and JPEG XL can't both be implemented by major browsers

I think it is mostly Not Invented Here syndrome, but with web browsers specifically there is the support consideration, as if something starts to be used widely on the web, it basically has to stay supported forever.

Like how all browsers support BMP images, despite them being completely superseded by PNG for the last 20 years.

Macromedia/Adobe flash was widely supported and now it is almost gone. Support can be removed.

although support only really needs to be removed if there's a security risk

evidently they consider BMP support to be worth the code overhead, since it's a question of "is this feature worth the extra code weight"

I think they should support both avif and jxl, and then maybe start thinking about a deprecation plan for j2k and webp.

>WebP >Depreciation plan That does not sound like a great idea TBH.

deprecation plan for j2k? I don't think any browsers support j2k unless you are talking about places/fields that make use of j2k like for medical scans, satellite images and etc

i wish it could be, but it's really just too widespread

Safari supports it, and the GTK port "recently" had to add support for it because sites depended on it, https://bugs.webkit.org/show_bug.cgi?id=186272

Instead of getting rid of WebP, they need to start planning for WebP2. I feel their latest comparison actually situates them between AVIF and JXL.

Yes.

I think deprecating gif, png and jpg is impossible because sites assume it will work, without any content negotiation or fallback.

For webp and j2k, it's possible to deprecate, just like jxr was deprecated in Edge, since they always have a fallback.

According https://w3techs.com/technologies/details/im-webp , popularity of WEBP is growing. LibreOffice added WEBP support only recently, Godot game engine last year.

Now it works in all major browsers, you can think about dropping fallback for webp, which is why I think it's important for browsers to think about a deprecation plan if they ever want to be able to get rid of it

The difference between Adobe Flash and image formats is that Adobe Flash was completely proprietary relying on a closed source plugin.

Yes, arguably Flash has never actually been part of the web platform

WEBP is shining: https://www.phoronix.com/news/Ubuntu-22.10-webp-pixbuf-loader

should be jxl instead

tired of google monopoly

cause browsers already support webp, webp is good for web content

WebP is mature. JXL will come later.

yea but jxl is better

webp cannot do lossy 4:4:4

no progressive decoding, only 4 channels

only 16k width/height max.

thats even less than jpg

WebP is slightly better for lossy than JPEG, but it can only do 4:2:0 and non-progressive. WebP is consistently better for lossless than PNG, but it can only do 8-bit.

it decodes fast so ppl use it on their websites

yeah it's definitely smaller in lossless compared to png. png gets really big if the resolution is high

its not that good in compression ratio (png)

One of the main arguments for webp was that there was VP8 decoding needed already anyway, so it was 'for free' in terms of code size and security attack surface

also i thought webp support was already in most OS

given webp is from 2010

Now I wonder if anyone still uses VP8 for video, I think it could probably be retired because av1, vp9, h264 is enough.

WebP was conceived to be a Web format, basically something only browsers and web devs need to know about

it has web in the name too

Which is I think a very bad concept

But understandable for Google engineers who basically control both the client and a large part of the server...

As WebP is already used in the wild, it makes sense to support it first.

searching webp on google, fifth result is "webp to jpg"

i guess people don't like unfamiliarity

true

surprised they havent done that until now esp. for the most used distribution

i like webp, it's very small + fast decode

i guess its a matter of time for people to notice jxl though..

webp is noticed because it's made by the largest tech company

also this doesnt really matter unless you use the default image viewer, if you download something like qimgv support is already in

qimgv is ukainin

dzgas won't use it

I like WebP lossless. The efficiency is pretty good and the encoder is fast. The JXL lossless still needs some tweaking. Unfortunately I'm using a website which accepts only JPEG and PNG, so pngout is my friend, but it's very very slow.

WebP lossless hits a very sweet spot in speed vs density, both encode and decode. Just a pity it's limited to 8-bit and 16383 pixels in either dimension.

JXL is more flexible in both features and trade-offs between speed and density, and it will take time to make encoders that fit in between fjxl and libjxl e2, and with better trade-offs in between e3 and e9

I don't mind slower encoding speed, after all I'm always using -e 9. The speed may be important for some users though.

WebP has limitations but it's still sufficient for many use cases.

I think they should wait until WebP2 comes out to deprecate WebP, then give them a large enough amount of time to convert over to other formats. When JXL is supported they should deprecate JPG and PNG, but again give something like a decade before removing it with many warnings in-between.

What is your image viewer? I am curious.

I think WebP2 is not coming soon, activity in libwebp2 repo is not so frequent. On the other side, libaom and libvpx are much active. I guess that Webp2 is an experimental research project and the results will be re-used in some future technology. Like VP10, it was not finalized but work was reused for AV1.

its not anything too special as I only started it a few days ago lol, but of is on my github

nomacs

I have been waiting for this for a while now and it's finally a thing! there is a plugin for paint.net now! https://github.com/0xC0000054/pdn-jpegxl

https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c72 <@826537092669767691> This is a valid point, and indeed <@268284145820631040>'s work-in-progress independent implementation (J40, see https://gist.github.com/lifthrasiir/137a3bf550f5a8408d4d9450d026101f) is indeed causing some spec bugs to be found. I think we're getting quite close to having a second, independent implementation though — it already decodes both VarDCT and Modular, the main thing left to do are the optional things like filters, splines, noise and patches.

However I don't think this needs to be a blocker for browser adoption. How many implementations of WebP are there?

I think WebP has been an asshole move by Google.

It does have one implementation only, and it's not a standard.

Other vendors have been forced to relent on WebP only for web compat, not because of it being a standard or good enough that they wanted to adopt it.

So let's not repeat that.

I'm currently fighting with a program using libvpx spraying memory so badly that valgrind can't even generate a valid stack trace, and ironically the same program under ASAN works flawlessly, so I'm running ASAN in production 😄

Do you have more info on the J40 implementation?

Maybe you could define a "web profile" for JPEG XL that doesn't use the features that J40 lacks?

I think J40 intends to implement everything, it just hasn't got there yet. You wouldn't want a new profile as it might end up the defacto standard ike JFIF.

The project — independent C impl based on the spec — is exactly what I'd like to see.

Level 5 is supposed to be the "web profile" for jpeg xl — it doesn't impose many restrictions though, just no CMYK, at most 16-bit, no more than 4 additional channels besides RGB, and animations are capped to 120 FPS.

I'm also happy that <@268284145820631040> started doing this independent implementation from spec, he has been finding quite a lot of bugs and unclear things in the spec, which will make the 2nd edition of the spec a lot better

It already decodes quite a lot of bitstreams nicely, so I'm quite confident that we'll have an actual standard with several implementations and not only a single implementation that basically defines the codec.

That said, I do hope that libjxl will just be good enough to be usable as-is for most use cases 🙂

In particular I'm not really looking forward to having proprietary jxl encoders that are better than what can be done with FOSS encoders — as is sadly the current situation for both J2K (where Kakadu beats OpenJPEG) and AVIF (where Aurora beats libaom/svt/rav1e).

yes, J40 intends to implement everything in the end, otherwise there would be always an unverified hole in the spec.

it's still short of being an actual library, so please account for that, but in brief: - baseline Modular: done - baseline VarDCT: done - progressive decoding: not yet implemented, in fact the current J40 will choke when TOC is permuted - restoration filters: garborish done, epf in progress - other image features: not yet implemented - upsampling: not yet implemented - colour transformation: only a slow sRGB path exists - animation and blending: not yet implemented - API: basic design in place, implementation in progress

well, I have went too far and it would be a shame if I stop here 😉

I think you'd just compile `j40.c`, not `j40.h`

oh, and `-lm` if you're using linux

for now `./j40 input.jxl [output.png]` will emit the first frame to output.png, which can be omitted just like djxl

I'm pretty sure that that will require YCbCr which is not currently implemented, but assertion makes me concerned, I will investigate later

it is also possible that it's animated, in which case there is a known bug that triggers this assertion

<@456226577798135808> just in case, could you upload that particular file?

thank you, that's more than enough information 🙂

whoops, that's entirely my fault: `f->lf_thr[i][j] = j40__unpack_signed(j40__u32(st, 0, 4, 16, 8, 272, 16, 65808, 32));` won't work because the last term has `u(32)` which may cause an overflow :S

(I think at this point it's better to continue in <#794206087879852106> )

Is it in rust?

no, it's C.

the language doesn't matter that much imo — what is important is that it's an independent implementation from spec, as opposed to a fork or translation of libjxl that would not help to reveal spec bugs since it would just inherit any discrepancies

I am the author of the Paint.NET JXL plugin. Version 1.0 of the plugin does not have support for EXIF or XMP metadata, due to libjxl 0.6.1 not having the appropriate APIs. The plugin does not support animated or multi-frame images, and only Gray(Alpha) and RGB(Alpha) color spaces are supported. All unsupported images should be rejected with an error message, but I was unable to find any non-animated multi-frame images to test with. Encoding an image with libjxl is significantly faster and uses less memory than AVIF with libaom. My Paint.NET AVIF plugin has to use a HEIF image grid (tiles that the decoder reassembles to form the full image) on most images in order to keep the AOM encoding speed and memory usage acceptable.

for viewing purposes, decoding non-animated multi-frame should be handled correctly by default since the decode api will merge the layers automatically for you if you don't tell it explicitly to not do that.

Thanks for the info.

it'd be cool if it can save and decode layers as layers

you need to set JxlDecoderSetCoalescing to false if you want to decode layers

you then do need to handle things yourself though: returned frames can have arbitrary dimensions (including larger than the frame!) and an x0,y0 offset, and there are other blend modes than just the usual alpha blending

i got a curious result for one image ``` 47M 001.png 17M 001.webp 16M 001_cjxl_e3.jxl 28M 001_pdn-jpegxl_e3.jxl```

what is that last one?

using <@833420862334042152>'s plugin

all we need now is a photoshop plugin

are you looking at lossless or lossy?

lossless

can you run jxlinfo on the last one?

could be it's using XYB, so not actually lossless and quite ineffective

> lossy, 8-bit RGB hmmmm

I am hoping that Adobe will add built-in support, based on the fact that one of their employees was asking for Chrome/Chromium to enable JXL by default: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c61

yeah i often think about making a plugin but if there's going to be official support then it'd be a waste

I wrote a Photoshop plugin for AVIF support. https://github.com/0xC0000054/avif-format The plugin does not support HDR, and I have no idea how I would go about implementing it. It appears that Adobe never documented the details of Photoshop's 32-bit float image mode in the Photoshop SDK, other than the fact that it was added in CS2. Adobe has not added official support for AVIF, despite 2 years of requests for it.

https://twitter.com/kornelski/status/1564574363835404288?t=iPdS6wGMJuWNgnk9qhJpYw&s=19 <@826537092669767691> These are valid points, but it's kind of frustrating to me that they have this double standard: WebP and AVIF were both added to Chrome quite quickly and maybe even prematurely — in the sense that the formats weren't fully frozen yet, evidence of compression performance was flimsy at best, ecosystem support and tooling was quite poor — while for JPEG XL they are suddenly taking a rather slow and conservative approach.

Point 2 is also true for WebP and AVIF, and point 3 too — you can claim that they "come for free" because most code is shared with the corresponding video codecs, but I think that's a rather short-term argument: video formats can eventually be retired more easily than image formats imo, so it's quite plausible that at some point VP8 and AV1 would be retired as supported video codecs (say in 15 years or so, when everyone is using AV4 and it is enough to keep only h264, VP9, AV2, AV3 and AV4), except they need to be kept around just for WebP and AVIF.

Anyway it's hard to get rid of the impression that WebP and AVIF have received a 'preferential treatment' in Chrome since they were 'invented there', while JXL was not.

WebP has been unilaterally and prematurely forced by Google, without standards process, without consensus. In retrospective it's been a big mistake, e.g. waiting until VP9 would have improved the format greatly.

So yeah, I hold JPEG XL to a higher standard than WebP.

The fact that Google carelessly forced one image format doesn't mean they should force another.

AVIF got in only because of AV1.

I wonder if there is a path to dropping AV1, and therefore AVIF

VP8 unfortunately got immortalized in WebRTC and WebP

God, can you imagine how much better lossy WebP would have been by then? 😂

Honestly, only the lossless part of WebP was interesting for me. I was using it for archiving some large images before I converted them to lossless JXL.

BTW, Safari seems to have a custom WebP decoder, or at least something else than vanilla libvpx

because there are libvpx-produced WebPs that don't decode in Safari

Apple has delayed adding WebP until WebP was available in macOS natively. I presume they care what happens with "Save As", etc.

Google has delayed adding AVIF to mobile Chrome until AV1 decoder shipped with Android

due to code size concerns

so I guess the path to JXL adoption needs to go through OSes first?

on desktop, it's only safari that relies on OS codecs

i'm not as familiar with mobile but no android browser _needs_ OS support for particular formats. not sure why google would've waited for android avif support (especially since the latest chrome often runs on old android that won't support avif anyway).

Yes some WebPs do not decode in Safari, both lossy and lossless. That could indeed be because they have their own implementation.

Any codec supported in Safari needs to be in Apple's CoreMedia, so MacOS/iOS support is a prerequisite for Safari support. It makes sense, tbh.

On Android, depending on system level support for anything is annoying due to the long tail of old versions that never get updated. So it is understandable that Chrome ships some codecs regardless of Android support. Same with not wanting to rely on Microsoft.

OS-level support and having a "Save As..." that works out of the box for everyone is very important imo. It makes the difference between a format people don't even notice because it's just a picture that works (which is a good thing!) and a format people hate with a passion because they get frustrated by having an image they can view in a browser but cannot use anywhere else.

So I hope Microsoft will soon announce jxl support. On Linux, we already have out-of-the-box jxl support in quite a few distros and I am sure the rest will follow easily. Windows still has a significant market share though.

https://twitter.com/kornelski/status/1564618319994421254

Complains about attack surface, but wouldn't just using some conversion tool be a bigger potential security issue than using the full implementation? 👀

I agree, I tried converting some images to lossy webp years ago and the color was wildly lost. It is a *decent* PNG replacement and good for icons but not so much for photos.

Don't get your hopes up on Microsoft. They don't even support WebP.

I was experimenting with lossy WebP mostly for animation, as an attempt to recompress heavily dithered GIFs. WebP managed to filter out the dithering by smoothing and reduced the file size. Can't tell if the result looked better or worse, though. Both GIF and WebP looked bad.

I hardly see any animated WebPs in the wild. Oddly, it seems many of them don't seem to work in Firefox while other do? Not sure what the issue is there.

I still believe that animated GIF, WebP, etc. should be done away with. Just use video.

An interesting feature is ability to mix lossy and lossless images in single animation. This is possible also in JXL.

For graphs/charts, vector-type animations, yes. It can go even further: https://discord.com/channels/794206087879852103/794206170445119489/1013920244634484816

What I am referring to are memes or any animations that just show photos, other videos.

https://packages.debian.org/search?keywords=libjxl

pulling a reason out of my ass, malaterre is probably waiting for 1.0 or at least some vaguely "stable" labelled release to move it

foobar 2.0 beta 2 now supports WIC. This means support for covers in JXL via jxl_winthumb.

Album art in jxl format?

Yeap

Chrome added progressive rendering support to JXL for non-alpha images. https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c75

my firefox patches 😢

What happened?

nothing happened

<@795684063032901642> can we make it work for alpha too? At least in the (default) squeeze case, where 8x8 downsampled alpha is actually available in the bitstream at the same time as the vardct DC...

Does this mean the decision to keep/develop JXL support in Chrome was made? And correctly, at that? 😉

No, it doesn't mean anything regarding that, afaiu

..and it got reverted?

it's pretty common for changes to get reverted from what I have seen since chromium has a lot of tests that things go through and if any of the tests fail then the changes gets reverted

so at some point soon somebody is probably going to fix whatever is causing the failing testcase and then progressive decoding will get readded

Yes, lots of build targets for Chrome, and I suppose some of the more exotic ones are not tried until the commit gets merged

Do you think there is a strong use case for progressive with alpha? I think alpha images often contain non-photographic content and in those cases the smoothing might even be worse than waiting, because it will be very noticeable.

Yep, it looks like some builds are failing. Bugs will happen.

Images that have a photo layer and vector (text maybe?) in a layer above with alpha, or a photo with alpha would still need progressive decoding.

There is not much use of alpha in photos because it only came about in WebP and now AVIF, but WebP is bad unless it's lossless so it didn't get used much. I feel it will get used more in JXL, possibly in AVIF but there is low uptake so far.

the smoothing in progressive non-photographic images right now, already might yield unexpected results when patches are used, because those patches will not be smoothed

Other use cases: A 3D (or 2D) video game character with transparent background. Believe it or not, I've seen both current ways of doing this: Making it part of a larger image (background and foreground combined into one massive image that is then split into blocks). This severely limits how designs function and completely prevents responsive sites. The other way, exporting your characters as WebP or PNG lossless which are massive (yes, I've seen sites like this that take a good 20-30 seconds to load images on a broadband connection). JXL will be a massive step for such uses. People often "cut out" things from images and would want transparency around them as well.

Alpha and photo traditionally don't mix well on the web because JPEG has no alpha and PNG sucks at photo. So current usage patterns are likely not representative for what people actually want to do.

Something like a circular cutout from a photo (without having to resort to CSS to do it) is quite widely used. Background removal tools are getting better too, so if the codecs support it in a nice way, I can imagine some nice web designs where the hero image is not just an opaque rectangle.

One of the strengths of jxl is that it natively supports alpha, including progressive interleaving of rgb data with alpha data. This is something that cannot be done in formats like heic and avif where the rgb and alpha data are separate bitstreams (they cannot do progressive in general, but even if av1 could be displayed incrementally, avif cannot do incremental display of rgba without waiting for either the full rgb or the full alpha).

Are there plans to allow setting different distance for color channels and alpha? For example, for circular cutout, lossless alpha would make sense.

Another one is a avatar for websites. Some people like to use various cut out characters or their own heads or caricatures. Using a filter drop shadow, it takes into account the fully transparent pixels and will wrap the shadow nicely around the non-transparent areas of the image.

In such cases, the alpha channel will be very simple, very low count of alpha levels, mostly fully opaque and fully transparent.

Unexpected, yes, but in some cases perhaps also desirable. Patches are great for text, so for something like a photo with embedded title or caption it could be quite cool to have readable text already in the 8x8 progressive preview.

does jpeg xl support efficiently coding text overlaid on photo with no opaque background, e.g. "impact font meme"?

From my experience, it’s exactly > [_ _wb_ _] Alpha and photo traditionally don't mix well on the web because JPEG has no alpha and PNG sucks at photo. So current usage patterns are likely not representative for what people actually want to do. In other words > [you] I think alpha images often contain non-photographic content is merely an expression of the technical constraints that JXL promises to alleviate, not a natural state. In my work, whenever there is any question of having a raster image with alpha, there is always this dread of the filesize and of having to have a required PNG8 fallback that also must go through a clever more-than-1bit transparency tech that takes ages and until recently wasn’t easily available. While the natural state would be to worry less, because the holes in the image should be cheaper than image itself, right?

Not to mention it would help CSS Shapes adoption.

It's doable, but the current encoder will not detect it so atm it can only be done with help of authoring tools, e.g. coding the text as a separate layer with alpha blending (in which the current encoder can detect duplicate glyphs and encode them only once)

I think Mozilla just doesn't want to add anything as long as Chrome doesn't.

I just published a new version that fixes a bug in the lossless mode.

My code was setting the `uses_original_profile` field to `false` when using lossless encoding.

poggers

i was wondering why it was so much slower but it was because i was doing -e 3 with cjxl and speed 3 in your plugin but i should have been doing speed 7

another quirk ``` /m/i/e/test) jxlinfo Untitled_pdn-jpegxl.jxl | grep rendering 02:27:05 Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Relative /m/i/e/test) jxlinfo Untitled_cjxl.jxl | grep rendering 02:28:40 Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Perceptual```

The encoding speed values are inverted in the plugin UI when compared to the native libjxl values, higher numbers are faster. The GIMP plugin in the libjxl repository has the same behavior. I could change it to use the native libjxl values, but I thought that lower values being faster was confusing behavior for users that are not familiar with libjxl.

what if there were two sliders that changed each other

What do you mean?

dumb idea, both speed and effort slider where one would update the other with the inverse value

probably not possible anyway

Not a problem as long it's clearly labeled.

The issue with linking the sliders would be lossless mode, the quality slider is disabled when using lossless encoding.

rendering intent being relative is important though

The rendering intent is set by `JxlColorEncodingSetToSRGB`, not sure why it is using relative as its default rendering intent. I will override the rendering intent to use perceptual for the next version of the plugin.

I don't think that's the case. They have far fewer developers and had 2 major layoffs in the past couple years. They've been falling even further behind Chrome on features recently but at the same time some of it is good as some of the features have shown to have potential to be security or privacy issues. Having extra time to review and let Chrome "test" new features exposes these. In the end I think it comes down to Mozilla's fewer resources and their more cautious nature in general. However, if Chrome adds it and usage takes off, they will be pressured to increase the priority.

By now you could use the new API and subscribe to the JXL_DEC_FRAME_PROGRESSION for your firefox patch.

For the next version of the plugin I changed the slider range to match cjxl and added a description to the UI regarding the value range.

I'll also bring up support comparison. After AVIF was announced, the only major company that is part of AOM that showed major support was Netflix. Most were there for AV1 support, but didn't speak out in support of AVIF. A number of them have now come out in support for JXL. After only 1 of the AOM companies made a large article about it, they implemented it. Since then there has been low uptake and a fair amount of anger over the slow speed, lack of features, and people realizing it wasn't meant as a JPG replacement as they many had hoped and some had advertised. However, as JXL progresses a number of people & organizations (including some large AOM members) have come out in support of it. It's suddenly called "bragging." One company & bunch of news articles with incorrect information = support. 5+ companies + many individuals = bragging. It's definitely political.

What I'm currently worried about is changing excuses. In politics it's common to come up with an excuse to not support an idea. When that excuse gets solved or debunked, they come up with another excuse. Then another. When they run out of excuses they fall back on some previous non-issue or will just start ignoring it. There is a possibility of that happening to JXL.

was that tweet about "bragging" (if I understand what you meant correctly) meant to be critical of jxl by the way?

I thought it was neutral

Felt a bit condescending or passive-aggressive to me.

I think adoption outside browsers is proceeding nicely — imagemagick, ffmpeg, gimp, krita, now Adobe and Intel also indicating support. Adoption in browsers is taking more time, which I think is partly for a good reason (don't rush adding new formats, don't repeat the mistakes of the past where webp/j2k/avif were added quite prematurely) and partly for a bad/political reason (some kind of misconception amongst Chrome devs that adding JXL support is strategically bad for AOM/AVIF/AV1/AV2 so JXL is seen as an "enemy")

https://twitter.com/ericlaw/status/1564263815063244800?t=sPEI1Q9fw34OsdC8TvZd6Q&s=19 you mean that one? I don't think it was meant in a bad way.

Here, use of the word brag is seen as a negative (even though people do it all the time). Had it been "JPEGXL is accumulating a some pretty impressive support & pressure to implement it" or something similar, it would not appear negative.

I don't think JXL is an enemy of AV1, likely more an ally since JXL has nothing to do with video. However, AVIF is meant for a smaller use case outside of what JXL is meant for, so they should compliment each other. However, I think it's just confused people as they just want to take their JPGs and PNGs and convert them but discovering that may not be the best choice in most cases. With JXL, that is the intended case. I assume they intend to (at some point) make AVIF more of a universal web format but they likely weren't expecting another format to do the same until they got to that point.

I think "brag sheet" is a single term, but I'm not a native speaker so my interpretation can be wrong

(more formal word would be a letter of recommendation)

I may be naive, and am just a user, but not sure it must be political and/or bad faith. Lacking active external body, browser teams may see themselves as guardians of the web platform. And they worry, because once giveth, it cannot be taketh away (unlike some export option in Photoshop). One more reason may be, that sadly, for some uses (low quality) AVIF may be winning over JXL. The fact that Cloudinary is researching tech to choose the codec based on image make-up is very cool. But, also, is a little sad, because it shows there is no clear winner for all use cases (so situation remains similar to last gen, even if less so). Now, should it be on browser teams' shoulders to effectively judge life/death like Roman emperors? No. Is it fair to them to have to make this decision? No. Should they decide in favour of JXL?Yes.😜

Except that the vast majority of people are not setting PS quality 10, the majority are exporting a quality 50 or above which is where JXL shines and AVIF starts faltering.

"Brag sheet" is a odd US term, not something I'd heard of before, but it's got a good meaning

I know in parts of the US and UK it's a wildly negative term. A single brag is bad enough. Multiple brags (as in a sheet of them), would be much worse.

The definition I'm seeing is something akin to a resume, showing reasons to pick it

So an "impressive brag sheet" is a strong list of reasons to pick it over alternatives

Also, as you stated in resumes, a brag is typically the person doing the work marketing it (or at least claiming they did, I've interviewed people that bragged they did work I found out others did). If others not directly related to it speak positively on it, it's not a brag, its support from the outside. Support from others is seen as a much more trustworthy source than someone bragging they did X/Y/Z.

I would relate it more to product reviews on a website. If all you saw was the company bragging about their own product's virtues and nothing from others who used the product... would you be more likely to purchase the product over the one where there were thousands of people talking about all the positive attributes?

I crashed Paint.NET while fiddling with the encoder parameters because libjxl called `abort()` when an assert failed. I was attempting to encode monochrome image with lossless and effort 9, and after hooking up the debugger the stack trace showed the `n <=255` assert in `StoreVarLenUint8` failing with `n == 256` . Edit: It looks like the crash was due to using a debug build, it works fine in a release build.

what's the purpose of JXL_DEC_FRAME_PROGRESSION? as opposed to only painting when JXL_DEC_NEED_MORE_INPUT

to have more control about when repainting makes sense.

<:thenk:349311010584395788>

We have little control over how much byte we get each time, so JXL_DEC_NEED_MORE_INPUT might be called more times than it makes sense to flush. With JXL_DEC_FRAME_PROGRESSION we indicate when it makes sense to flush, which can then be used to make that decision. At least this is the idea

oh, so if I restate, JXL_DEC_NEED_MORE_INPUT can be called multiple times when there isn't anything available such as progressive data?

if you feed the decoder one byte at a time, it will respond with NEED_MORE_INPUT every time

If the decoder in a browser feeds the decoder byte-by-byte, then your internet connection is too slow 😉 But seriously, for a large image on a slow connection the JXL_DEC_NEED_MORE_INPUT might get triggered many times

you also have a weird internet connection if data arrives one byte at a time 🙂 but I was just making a point

JXL_DEC_FRAME_PROGRESSION isnt giving me any progressive steps...

make sure your image doesn't have alpha?!

now i get 1 step

ill try more later(maybe)...

how many steps you get can be configured

Also, let's not forget that JXL doesn't have weaknesses that most video formats do.

What do you mean by weaknesses?

Things like limited frame size, or required 4:2:0 or things like that.

<:JXL:805850130203934781> has some pretty impressive limits:

👍

YCbCr mainly and availability of chroma subsampling.

I find progressive decoding to be a strong feature of JXL when it comes to the web

I agree. Unfortunately there is little available evidence to show that progressive decode is a useful thing — imo it's kind of self-evident that it is, but then people start talking about the negative properties of progressive (cognitive load, bad first impressions, extra cpu cost for more passes/renders, etc), especially people who are fans of formats that happen to be non-progressive

from what I gathered, it's a subjective matter. I guess it also depends on the context, whether you're in a situation where everything loads fast-ish anyways, or in one where images load slowly, so you actually benefit a lot more from a progressive scan compared to seeing nothing at all.

I think it's kind of silly to claim that progressive is not desirable - if it wouldn't be, then 1) browsers could just stop rendering images progressively, or offer a user preference option to select whether to do it or not — none of them ever did that afaik, and 2) web devs wouldn't bother with complicated LQIP schemes where they load a preview first and then replace it with the full image later using javascript, as a poor man's version of progressive rendering.

Imo if the network is slow, getting something rather than nothing is obviously better. And if it is fast, then still it will feel even snappier with progressive loading.

Progressive mode is nice to have and it's optional, so anybody can choose to use it or not. In PNG, progressive mode is not that great as it really hurts compression. In JPEG, progressive mode works pretty well.

Having a large image show with a blank screen I've thought that the download was broken and closed the window/tab. At least when you can see that the image is loading it lets you know something is happening rather than a broken image. That's more than enough evidence for me. Granted, I think the progressive encoding should be able to be turned off if so desired, but should be enabled by default.

it will handle just enough container stuffs to handle codestream, a major reason being compressed metadata requires Brotli proper, which requires a large preset dictionary.

I guess with jxl the metadata shouldn't effect display at all, so that shouldn't be an issue.

Don't things like EXIF orientation affect the display?

the codestream is expected to have the same orientation information as Exif metadata, if Exif ever appears in the container

In jxl, orientation is a codestream header field. Exif orientation can be there too, but it gets overridden by the codestream value (so viewers can ignore Exif).

when they are not in agreement the codestream orientation takes precedence

yeah

Which reminds me, we need to implement something that can adjust jxl codestream headers without reencoding

jxltran 😉

luckily adjusting the orientation can be done in a bit editor cause all orientation fields are the same size i.e. u(3)

but if there's an ICC Profile present then other fields could be complicated

since zeropadtobyte() doesn't occur between the imagemetadata and the icc profile

except sometimes the orientation field is not signalled at all, i.e. when `all_default` or `!extra_fields`

ah, crap forgot about that

so that would require potentially redoing the entire size header and ICC profile

at least the frame header is byte-aligned

so that won't need to be re-written

yeah, well not really redoing ICC but you do need to implement something that moves bits around (as opposed to bytes), which is somewhat annoying

I don't think there's a way to do memmove() on bits without essentially just reading a `uint64_t` and left shifting it and then writing it

or equivalent

(in an endian-dependent way)

yeah I think so

yes, it requires shifting. still pretty cheap to do, just annoying

I kind of think about hooks in J40, which would be a long-term plan, basically a set of initially undefined macros that when defined allow for more fine-grained access to the codestream

I assume chrome has yet do respond to the issue still?

afaik, yes.

Safari added AVIF support: https://webkit.org/blog/13152/webkit-features-in-safari-16-0/ Sadly, that pretty much seals it, JPEG XL lost the format war.

That was announced for a while already, no?

AVIF is 3 years older than JXL, so I think it's not too surprising that AVIF support is landing earlier than JXL support. I don't think it implies anything about "winning a format war".

I hope you're right.

The problem is that while JPEG XL has obvious advantages, it pretty much solves the same problem as AVIF and that may disincentivize browser developers from adding support

they may see it as duplication

("the same problem" meaning "better lossy image compression")

but otoh there's a precedent, webp didn't prevent avif from succeeding

so maybe you're right...

Adding AVIF into Safari doesn't change the fact that the lossless AVIF is barely functional.

i mainly (only) use jxl for lossless so for me nothing even competes

That's right. Also lossless JPEG transcoding is the killer feature that no other format has.

Lossy jxl is also quite nice — every other new lossy format (webp, heic, avif) has made big improvements to the low end (very low quality, where jpeg becomes a blocky mess) but not really to the high end (high quality to visually lossless). In fact, when evaluated properly (i.e. not through poor metrics like psnr or vmaf), webp/heic/avif might not even really improve upon jpeg, or at least not consistently, in the range of qualities that many people actually want to use (d0.5 - d2 / q80 - q95). However jxl really shines in that range.

Agreed, high fidelity lossy compression is very useful too.

It seems AVIF has absolutely nothing to offer. It's just slightly better lossy WebP. It's completely useless for me.

it should be the best animated format that can fit in an <img> tag, which is a real constraint sometimes

shame firefox doesn't support that, wonder if safari does?

> Safari for iOS 16 includes support for still images compressed using the AVIF format <https://webkit.org/blog/13152/webkit-features-in-safari-16-0/> my sides

As a replacement for GIF tor short video clips, that's the only use case of AVIF that makes sense to me. Does anybody use animated WebP? That should still do better than GIF.

youtube uses that for the short preview when you hover over a video

That makes sense and even low fidelity doesn't matter in thumbnails.

i would if discord supported embedding them

Animations are kinda specific, those have different requirements than static images.

That's also the reason why animated PNG is only used for emojis and GUI elements AFAIK.

animated gif/png/webp/jxl is not really useful for anything bigger than an emoji, imo. It's a pity that browser support for real video codecs in img tags is so messed up — safari supports h264 and nothing else, chrome supports av1 and nothing else, and firefox supports nothing.

if we could just have universal support for h264 in an img tag, that would already be a huge step forwards. Having an option for vp9 and av1 would be nice too, but the step from needing a gif fallback to not needing it would be the big jump

I recall there were OBJECT and EMBED elements in HTML, where you could insert pretty much anything, including images, sounds, videos, etc. Does this still work?

There's the video tag too. But in some use cases, it's hard to do custom html, or e.g. in emails, often only img will work, not arbitrary html.

WebP in IMG should work pretty much in all browsers now, right? So GIF fallback isn't necessary anymore. I know WebP isn't as efficient as real video but it's better than nothing. It's a substitution for non existent animated JPEG.

Netscape Navigator was the first to allow non-still-images in img, afaik

arguably that was a historical mistake, but I don't think there's a way to undo that

Just my usual cheap advocacy comment about low fidelity being important for web stuff. So I do not agree that > It seems AVIF has absolutely nothing to offer. and if it would depend on me, I would channel all resources into making JXL perform better at the low end too. Then, the last (but not sure if not most important) reason to use AVIF would sorta go away.

Yeah. It would be better if it adds some filters or hacks to hide artifacts at low quality

Do we have any sample JXL HDR pictures?

https://sturmen.github.io/posts/hdr-jpeg-xl-2022/ and https://people.csail.mit.edu/ericchan/hdr/hdr-jxl.php

thanks!

Okay. JXL needs to improve at the low end too to be really versatile. I agree with that. WebP is already used for low fidelity. 8bit 4:2:0 fits perfectly for low fidelity. What does AVIF improve there?

https://sneyers.info/tradeoff-relative.html

At the very low end (the average libjpeg q18 quality), basically mozjpeg saves 28% bytes compared to unoptimized jpeg, WebP saves 43%, jxl e6 saves 47%, and AVIF saves 50 to 60% depending on how much cpu you want to throw at it

(these numbers are according to ssimulacra2, grains of salt need to be applied of course)

question is if _that_ low fidelity is actually useful for anyone.

I use MozJPEG at 45 and WebP at 25 in production (both for DPR2 images only). I know: low. I would love an encoder that will give me **better** quality than that for all (most?) images, but lower filesize (I do hope for defo lower than MozJPEG, WebP is very variable and I may indeed be using it way too low, but for reasons).

I will choose the one that will give me lowest filesize. I would love it to also be the one that has a proper progressive mode. And the one where setting one quality value (I know: bit amateurish*) for thousands+ of different images will give me most consistent quality and filesize (WebP is so low, because even at this quality, some images are already weightier than in MozJPEG).

* amateurish = no readily available open source per-image quality setting tech that I know of

That fidelity is around SSIMULACRA2 = 50 on average, which I think is low but still reasonable for some web use cases

At levels about 20 and lower there's either artifacting or excess smoothing. I don't think anyone would like to look at that.

Maybe for dpr3 or in very bad network conditions, but yeah generally speaking I think only the range 50-90 in ssimulacra2 is useful

Very bad network could take advantage of progressive decoding.

So that's point for JXL.

tenor gifs

Interesting, --resampling=2 doesn't seem to work in the latest cjxl.

It says that the flag value is invalid.

Just a note, we don’t care about dpr>2. Based on me eyesight and eg. this: https://observablehq.com/@eeeps/visual-acuity-and-device-pixel-ratio.

yes, I agree that you probably shouldn't really care about dpr > 2, and just serve them dpr2 — <@702298678333014087> is here too btw 🙂

with one caveat: that’s assuming a viewing distance of ~70 cm

closer than that and higher dpr may make sense again

Wait, dpr2 in the css sense is supposed to be in terms of visual angle, so factoring in viewing distance already, no?

the device still has to assume one

unless we start to see devices that measure it in realtime and make the page larger or smaller accordingly, but that would be strange

yes, devices make assumptions, but I think for phones those assumptions can be relatively good in the typical case

I wasn’t just thinking about phones but e.g. 8K monitors

when I was trying one out (32"), I found that my distance to the screen ended up being much more dynamic than with less dense screens

Ah yes that makes sense. If there is more detail to see when you get closer, it makes sense to get closer, just like what you could do when viewing a painting in a museum

This is another difference btw between video and still images.

but muted, looped and autoplayed videos are basically indistinguishable from animated GIFs, so why not support them, given that GIFs are supported? Personally, I think ideally (mute) animations should be a 3rd category, besides video and (still) img. However having them as a special case img or video reduces some kind of complexity.

ive never seen looped videos as indistinguashable thing

it feels like browsers aren't optimized playing things in loop because theres always some sort of delay, or maybe it's a bit related to codec internals too (keyframes vs delta frames), and gifs often degrading in somewhat smoother, and aesthetic ways for synthetic content compared to video codecs

you didn't notice the unnoticeable? ;P When you think you see a GIF on the web, it might just be a muted, looped, autoplayed video. Imgur coined the term "gifv" for those. https://blog.imgur.com/2014/10/09/introducing-gifv/

eh? i mean that i often see differences between these fake gifs and real ones

though i dont browse imgur nor reddit which sometimes link to that

also i feel that using name "gifv" for this is deceiptive

if the original was uploaded as gif then there shouldn't be any difference.. except if upon conversion dithered gradients are smoothed out

id say giphy aint that bad - on the site they clearly label gifs and mp4 separate for download

at this point gif is no longer file format name and a term for short looped muted video

maybe we can make a backronym

its one thing when the service itself contains gif in name, especially if it can both accept and serve actual gifs. when they actually put that as file extension then it feels like its no longer just an optimization, but a bad marketing stunt

laypersons don't know about file formats, so when they see the name "gif" and a video disguised as a gif file, they would instead think that this company has somehow made gif better, not realizing it's not gif at all

yeah, and that's negative thing in my eyes, especially when the real reason is cdn bandwidth optimization, done by messing up original data. portraying that as great new thing is smart PR move for non-tech audience but at cost of more confusion for everyone, messed up quality of data and some faster downloads i guess. but overall it feels like morally broken thing to do

but then i know imgur doing stuff like this all the time, sometimes serving direct .png links as html pages with ads and other stuff to promote "engagement" aka eat up people's attention for their own benefit

i'll stop ranting about this, need some sleep.

not necessarily. You can have all the colors in a GIF, you just need to overlay together multiple frames with a 0ms delay in between, each frame can have their own palette. https://en.wikipedia.org/wiki/GIF#True_color

The problem is that 0 delay doesn't work as it should, in practice there's always some delay between frames.

converter could interpret 0 correctly.. or they could emulate browsers' behavior

There are lots of GIF animations in the wild with 0 delay, relying on the default minimum delay.

<@532010383041363969> <@795684063032901642> the chromestatus page for jxl (https://chromestatus.com/feature/5188299478007808) still has some fields that could be updated imo: > Standard maturity Unknown standards status - check spec link for status ISO/IEC 18181-1 (codestream) and 18181-2 (file format) are published international standards, so I wouldn't say that's "unknown status". > Safari views_link > https://lists.webkit.org/pipermail/webkit-dev/2021-May/031846.html Not sure if this link is very helpful. It doesn't really say anything about what Safari's view is. > Supported on all platforms? False > Web Platform Tests False Can/should anything be done to turn these into True? "Start prototyping" is marked as the 'Active stage' — why aren't we in the next stage yet of "Dev trials and iterate on design"?

Also Lode is still on the list of 'owners', though <@768090355546587137> has meanwhile moved on to other projects as far as I understand. Is that OK?

I'll apply some more updates on it

Fixed the 'unknown status' on the standard

it works only with 0.7.0 yea

speaking of that above issue, it appears the Arch Linux maintainer of FFmpeg closed the issue as "won't implement"

> ffmpeg is an audio and video utility, it is bloated enough already, please use image utilities like IM, vips or skia for this. > > Supporting some of the popular image formats we already do in case you'd like to create a video clip from a sequence of images can make sense but I hardly see the need to have that temporary image sequence as jxl instead of png for instance. Even jxl screenshots is a non issue, just save your screenshot as png then convert it to jxl using one of the above.

🤦 OS devs making more work for their users is not a good thing.

iirc the same thing happened with HTTP/2 support in curl with Arch, just decided users didn't need it

Took a while for that decision to change

Mac and Windows do not support even WebP. To be fair, it only has roughly 6-7% web market share. AVIF is less than 1%. I feel JXL is the only format likely to break the 10% barrier as it's the only one designed to replace the old jpg which is the vast majority of internet images. It also works as a great png and non-animated gif replacement. All that is likely to eventually lead to a ~80% market share.

Windows does support WEbP 😄

yeah it does

It does seem to be working now. I know when I tried it earlier this year it was not even showing a preview. I do notice that it won't let you edit metadata.

There is WebP plugin in MS Store but it seems to be installed by default.

This doesn't surprise me. Does current djxl even get it right?

Yeah thought so

Could you open an issue on the libjxl repo about this?

I think we should let libjxl detect the cmyk case (i.e. the icc profile being a cmyk one and a kBlack channel being present), and by default it should convert it to RGB so things 'just work' in applications that don't want to deal with cmyk codepaths.

Currently libjxl will just give you the cmy as if it was rgb, with an icc profile that says it is cmyk, and you manually have to fetch the k channel and do the color management to convert it to rgb for display

That should still remain an option, but imo the default behavior should make it easy for the application to just view the image without extra effort.

It's related but I think this one is more important: it's about rendering cmyk correctly by default

FFmpeg has no support for CMYK so this doesn't really surprise me

it's just based on libjxl, so the issue here is more that libjxl doesn't properly render it in RGB space when it's requested

I agree - better behavior would be for libjxl to convert it to some sufficiently wide gamut RGB space and return it like that, so applications that don't support cmyk can still view cmyk images properly.

Applications that do know how to handle cmyk can set some option to skip the conversion and fetch the k channel separately (or we could add an option for getting interleaved cmyk, just like we have that for rgba)

I think getting cmyk to work better is important for adoption in use cases where printing is a thing, like Krita. If we want jxl to be not just a web delivery format but also an interchange format, getting cmyk to work easily (even in browsers) can be a gamechanger imo.

Currently the only interoperable options for cmyk are jpeg and tiff. One is lossy and doesn't support layers, the other has very poor compression and is barely an interoperable standard (it's basically a proprietary Adobe format).

When I was doing experiments with CMYK, it seemed that everything related to CMYK relies on Adobe.

Jxl can only represent 3 channels with dct, so cannot do cmyk jpegs reversibly

The only way currently to produce cmyk jxl is to manually use the api, pass cmy as if it is rgb and k in a separate kBlack channel, set the color profile to a cmyk ICC profile, and set use_original_profile=true

CMYK in JPEG is an ugly hack.

What surprises me is that nobody bothered to define a 4-component jpeg that does RGBA. Seems more useful than CMYK to me, and it's from the codestream perspective the same thing (just 4 channels).

Right, additionally CMY uses some color transform that doesn't make any sense.

It just (optionally) does YCbCr on cmy, which does kind of make sense

They encode CMY such that 0 means full ink, 255 means no ink

Which means it behaves pretty much like RGB

Inverted subtractive color is not that different from the usual additive color: C is basically lack-of-red, M is lack-of-green, and Y is lack-of-blue.

I've seen programs decoding this YCbCr as RGB and displaying that. The colors were all off of course. The K channel was ignored.

JPEG with alpha might be useful, although DCT compressed alpha would possibly result in ugly artifacts.

oh indeed

Do you have screenshot-sw enabled?

what version of ffmpeg/mpv are you using? what version of libjxl?

use `-v debug`

try git master FFmpeg

this is a bug I thought I had fixed already

it can

if you take the bug I fixed

yup, this is the one

update: it not being backported was just an oversight

I just asked if we could backport it to the 5.1 branch, and it was

Do you have experiences with flatpak manifests? I need some help in https://invent.kde.org/packaging/flatpak-kde-runtime/-/merge_requests/104

https://bugs.webkit.org/show_bug.cgi?id=208235#c15

yes, on iOS all browsers are Safari

and Safari uses OS-level image and video decoding (CoreMedia), so it can only add support for codecs that have OS-level support

so it's pretty much an all-or-nothing approach in the Apple ecosystem: either nothing will support jxl, or everything will support it

which if you think about it may not be such a bad thing

it certainly helps to avoid the "this image doesn't work!" thing that WebP experienced

but it does mean that the ball is completely in Apple's court, there is basically nothing that we can do

Can losslessly transcoded JPEG to JXL be progressive?

(on Linux) true HDR: AFAIK no (currently not possible on X11 nor Wayland; possible with direct framebuffer access which mpv and Kodi support but not sure whether they specifically support HDR in that mode) tonemapped to SDR: Chrome, and there is ongoing work on the quality of the tonemapping

the macOS version of https://github.com/Tom94/tev (an EXR viewer) does seem to output HDR

(as do the Windows and macOS versions of Chrome)

Yes. All VarDCT jxl files have DC first, including transcoded jpegs, so in that sense they're already progressive. You can also have multiple AC scans but that's optional and currently the jpeg recompression doesn't do that (but it could in principle). But having DC first is probably the most important thing in terms of UX advantage. Gradual refinement is imo less important.

I would assume so, but it's really hard to know what Apple is going to do or what influences their decisions, they are quite secretive...

So in practice, DC in transcoded JPEG is like 8x downsampled image.

Apple is kind of alien technology to me. It doesn't have that much influence outside the US.

iOS market share by region: - Europe: 31.8% - UK: 48.8% - North America: 53.8% - South America: 12.7 % - Asia: 17% - Africa: 13.4% - Oceania: 50.7%

so yeah it's mostly an Anglo-Saxon thing, but even 12-13% is not nothing

iirc mpv with gpu-next does support it

One could also make a viewer based on libplacebo that bypasses the mpv player loop

Uh, ops

Progressive AC is kinda easy, progressive DC less so

<@794205442175402004> feel like implementing this?

If not I can also give it a shot once I find the time

Progressive DC is just a matter of doing lossless squeeze, no?

not sure, the decoder would get floats

I'd be worried with progressive DC (and at least the current implementation) that you'd get random device-dependent off by ones

It also gets floats in the non-dc-frame approach, right?

mhhhhh, at most it's float(integer)

but with dc frame it can be more complex stuff

Because of dc frames being dequanted already?

yep

https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c79 Shopify expresses support and says they've enabled jxl on all sites for browsers with the flag enabled

HDR might be the “killer feature” where jxl moves the needle enough to push adoption. The only alternatives are: - PNG, which doesn’t offer lossy compression and only mediocre lossless compression - AVIF, which doesn’t offer good fidelity, nor reasonable encode time (both of which are probably showstoppers for photographers who care about HDR) - TIFF, which has no browser support, no lossy and poor lossless compression, and probably poor interoperability when used with HDR (legacy viewers will likely get it wrong) - PSD, which is like TIFF and even more proprietary - JPEG-HDR (JPEG XT), which has poor compression and no browser support; nearly all applications will only show you the fallback SDR image

I wonder why your list does not include HDR and EXR.

Right, EXR is also an alternative, but also no lossy / poor or no compression

What is HDR?

Also JXR and J2K are alternatives but meh

https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c80

Adobe is trying to force support now - nice to see them doing what they can to back browsers into a corner.

It's kind of needed. There are not enough browsers to have a healthy competition in being the first to support new features. Basically there are only three browsers: - Chrome is by far the biggest one, but key decision makers in Chrome codec decisions are also hardcore avif proponents who seem to be afraid to allow jxl support since it might hurt avif adoption. - Safari is also important, but they are slowed down by their policy to only support codecs with OS-level support (in iOS and MacOS), meaning it is unlikely they can ship quickly (in contrast to Chrome) - Firefox is not really important enough to be the leader in something like this, they rather follow whatever Chrome will do. They also recently fired lots of people and don't really have much resources left to implement stuff, and they don't want to make their 'allies' in the AOM angry by being the first to support jxl.

https://research.google/people/105284/ <- this is the key decision maker in Chrome, being the leader of Chrome's Web Platform team including media, codecs, graphics and capabilities

I honestly don't get it at this point. There are so many good things from JPEG-XL that would heavily benefit AOM so much in a new codec that it would be stupid not to do so.

HDR: http://www.paulbourke.net/dataformats/pic/ - lossless only, mediocre compression EXR: both lossy and lossless, from my experience on panoramic images: PIZ and DWA/B can well compete against jxl lossless and jxl -d=0.1 (however, I only tested it on libjxl shipped with gimp 2.99.12)

Oh, I didn't realize EXR did lossy too.

I don't really get it either, in my view the mission of the AOM is completely compatible with JXL — making royalty-free codecs for the web. But I think they somehow have this idea that if jxl gets traction, it will hurt avif adoption (which is likely true, imo), and therefore (which is imo a non sequitur) it will hurt av1 adoption and harm the success of the AOM.

AVIF is a really weak reason for AV1 adoption.

Nah, I think it's because of something else in regards to development. Can you imagine PSNR and SSIM scores going down by integrating JXL level tools? We can't have that.

lol

I agree. Yet this seems to be the focus of Jim's team. Instead of spending effort on making the video codec better at what it's designed for (video!), they are now doing things aimed at "closing the gap with jxl", like making incremental and 'progressive' decoding work somehow for avif, or somehow making a 16-bit version of avif. I think their resources would be better spent on making the actual video codec perform better (i.e. competing with vvc, not jxl), rather than somehow trying to make it a better still image format.

Oh, yes. There I think they made a fundamental mistake by setting 3 metrics in stone (psnr, ssim, vmaf) and blindly trusting those and only those when making any decision. I can see how that simplifies some discussions by a lot (there are only numbers, no opinions), but it's a very bad approach if you care about perceptual quality and not so much about BD rate gains w.r.t. nearly irrelevant quality metrics.

it’s a great illustration of https://www.discovermagazine.com/the-sciences/why-scientific-studies-are-so-often-wrong-the-streetlight-effect

I recently came across another relevant quote, but I can’t find where it was

I think this is a typical pitfall for codecs (or anything really) that get developed by a large committee or a large number of contributors: they tend to focus on clear-cut "objective" performance indicators, because that makes the consensus process seem fair and unbiased, but the end result is that they end up optimizing the wrong objective function. Small teams, even solo devs, have a big advantage there: they can do what is the best thing to do, with progressing insights into what that is, which may be very different from setting a priori criteria and then optimizing the hell out of them.

They made this mistake with hevc (it became a psnr machine but perceptually mediocre for its complexity), and they repeated it with av1.

ah, I found it: > The attempt to give an “optimal” answer to the wrong question has been called “Type-III error.” The statistician John Tukey (e.g., 1969) argued for a change in perspective: An appropriate answer to the right problem is better than an optimal answer to the wrong problem (Perlman and Wu, 1999).

(from https://doi.org/10.1016/j.socec.2004.09.033)

Except AVIF wasn't even meant for the same reason as JXL, it's meant for low-bit images. JXL is medium to lossless. AV1 has nothing to do JXL, it's a video format. The slow adoption is because hardware is only beginning to support it and it's still the slowest encoder out there. Once it gets faster it will be adopted quicker.

even if AVIF excels more in lower-fidelity images and JXL wins in medium and high-fidelity lossy images, people will still see them as direct competitors as they are both extended-life next-gen image formats that came out at around the same time

from a workflow perspective it doesn't make sense to use AVIF for low-fidelity and JXL for medium-and high-fidelity when you could serve one or the other tbh

ultimately people will use what their application (or their client's application) supports, so for AVIF and JXL to even compete far more things need to support *both*

<@794205442175402004> Do you believe that libjxl could be fast enough on both decoding and encoding to support replacing something like JPEG XS?

I think it has more to do with software capability and complexity. You can add a rule saying if resolution is lower than x/y, use avif, otherwise use jxl. However, that's not what it's meant for. AVIF is meant for low bitrate application. However, there's no simple way for software - especially websites - to detect a 2G connection vs a broadband connection. Some CDNs will do this using either lists of IPs and associated speeds or an AI, but that is not feasible for most small websites and apps. So most will just skip that step and go with a single format.

I doubt it, JXS supports ultra-low-latency down to just 4 _lines_ IIRC, with some hard guarantees on bitstream sizes etc. That is not something jxl is designed for.

Oh I see. Wait. **4 LINES?!!!** That is so absurdly low.

fast jxl encode/decode could probably be fast enough to replace some of the use cases of a mezzanine codec like jxs (i.e. ones where latency constraints can be relaxed), but it's really a rather specific niche jxs is designed for and I'm quite sure jxl cannot replace it