Is JPEG-XL DOA? Topic is solved

Talk about code development, features, specific bugs, enhancements, patches, and similar things.
Forum rules
Please keep everything here strictly on-topic.
This board is meant for Pale Moon source code development related subjects only like code snippets, patches, specific bugs, git, the repositories, etc.

This is not for tech support! Please do not post tech support questions in the "Development" board!
Please make sure not to use this board for support questions. Please post issues with specific websites, extensions, etc. in the relevant boards for those topics.

Please keep things on-topic as this forum will be used for reference for Pale Moon development. Expect topics that aren't relevant as such to be moved or deleted.
User avatar
sidology
Moon lover
Moon lover
Posts: 79
Joined: 2021-12-04, 22:07

Is JPEG-XL DOA?

Unread post by sidology » 2022-11-22, 12:58

Will Pale Moon implement AVIF support because it seems JPEG-XL is already dead:
Google's Chrome team said it will remove support for JPEG XL, a photo format that offers space saving and image quality advantages.
https://www.cnet.com/tech/computing/chr ... one-space/

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35473
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Is JPEG-XL DOA?

Unread post by Moonchild » 2022-11-22, 13:33

Just because Chrome decides to focus on a format they have more control over, does not mean "the format is dead".
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
sidology
Moon lover
Moon lover
Posts: 79
Joined: 2021-12-04, 22:07

Re: Is JPEG-XL DOA?

Unread post by sidology » 2022-11-22, 13:51

If Chrome doesn't support it, who will use it on their web site? Would you replace Pale Moon (png) screenshots with JPEG-XL ones, so Chrome users can't see them? Am I missing something?

User avatar
jobbautista9
Keeps coming back
Keeps coming back
Posts: 782
Joined: 2020-11-03, 06:47
Location: Philippines
Contact:

Re: Is JPEG-XL DOA?

Unread post by jobbautista9 » 2022-11-22, 14:09

Facebook wants JPEG-XL. A lot of large corporations are backing this format. I'm pretty sure you can check for JPEG-XL support via JavaScript's window.createImageBitmap object, and if it doesn't, then serve ordinary JPEGs instead.

The benefits of JPEG-XL compared to JPEG are too significant to ignore. Google may think it's possible to get away with spitting on open standards and pushing their own proprietary ones like they did with WebP, but such a tactic has limits, and I think they have committed a blunder this time. AVIF doesn't really have any real support other than Chrome pushing it, and Firefox's support is still in Nightly. And the benefits of AVIF doesn't really compare to JPEG-XL. Sure, AVIF may be a bit better in compressing images, but can it do lossless recompression of existing JPEG images like JPEG-XL does? Can AVIF do progressive decoding (which is a must for large images on the web)? Etc.
Image

merry mimas

XUL add-ons developer. You can find a list of add-ons I manage at http://rw.rs/~job/software.html.

Mima avatar by 絵虎. Pixiv post: https://www.pixiv.net/en/artworks/15431817

Image

User avatar
sidology
Moon lover
Moon lover
Posts: 79
Joined: 2021-12-04, 22:07

Re: Is JPEG-XL DOA?

Unread post by sidology » 2022-11-22, 14:10

Understood, thank you.

BenFenner
Astronaut
Astronaut
Posts: 588
Joined: 2015-06-01, 12:52
Location: US Southeast

Re: Is JPEG-XL DOA?

Unread post by BenFenner » 2022-11-22, 18:01

The announcement has hundreds of important players clamoring for Chromium to reconsider on the feature request issue:
https://bugs.chromium.org/p/chromium/is ... 78058#c209

I didn't expect the feature to come so quickly to Pale Moon. I wonder if the recent commotion stoked the fire a bit.

Regardless, I've submitted a story to Slashdot if anyone wants to vote for it in the Firehose:
https://slashdot.org/submission/1692509 ... age-format

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35473
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Is JPEG-XL DOA?

Unread post by Moonchild » 2022-11-22, 19:48

BenFenner wrote:
2022-11-22, 18:01
I didn't expect the feature to come so quickly to Pale Moon. I wonder if the recent commotion stoked the fire a bit.
No, We actually already planned to have it a lot earlier (like several months ago) but the jpeg-xl lib (or rather Google's "highway" lib dependency) didn't like Microsoft Visual C++ from Visual Studio 2015 so we couldn't land this until we had upped our game to VS 2022. It landing in this version had nothing to do at all with Chrome's decision-making process.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35473
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Is JPEG-XL DOA?

Unread post by Moonchild » 2022-11-22, 20:11

jobbautista9 wrote:
2022-11-22, 14:09
I'm pretty sure you can check for JPEG-XL support via JavaScript's window.createImageBitmap object, and if it doesn't, then serve ordinary JPEGs instead.
I'm not sure why people jump to using JS for everything.
There is this thing called "content negotiation" (aka "conneg") which is and has been a standard part of HTML that does not need scripting to determine what a client accepts.
Some people in the Google corner have (predictably) tried to snuff it but it's too powerful™ so it has survived the assault.
Basically, conneg sends a header to the server which mime types are accepted for the request, and the server can easily serve up appropriate content as a result.
Our JPEG-XL support is advertised to servers this way through the image.http.accept pref which advertises specific support for webp (and now also jxl) as well as png, explicitly, before a fallback value (basically telling the server "if not any of these, then use whatever you have" which normally means formats everyone and their grandmother supports). Servers can easily check this header to see whether a client supports a specific image format and serve the appropriate response, accordingly.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
__NM64__
Lunatic
Lunatic
Posts: 359
Joined: 2013-10-17, 05:29
Location: Northeast Ohio

Re: Is JPEG-XL DOA?

Unread post by __NM64__ » 2022-11-23, 04:19

Since nobody linked to this excellent article, I suppose I will:

Also, it's slightly amusing that the palemoon forum software doesn't seem to allow putting a .jxl image within [img] bbcode.

jobbautista9 wrote:
2022-11-22, 14:09
Sure, AVIF may be a bit better in compressing images
It's actually looking like this is only true with very compressed images and, the higher the quality is set, the more JPEG-XL wins by vs AVIF.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35473
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Is JPEG-XL DOA?

Unread post by Moonchild » 2022-11-23, 11:48

__NM64__ wrote:
2022-11-23, 04:19
Also, it's slightly amusing that the palemoon forum software doesn't seem to allow putting a .jxl image within [img] bbcode.
The forum software pre-dates the JPEG-XL format. The main issue is that for it to handle images properly for the img tag, it needs to be able to sniff the dimensions of the image from the file, and it's not able to do so with an unknown format.

I didn't write phpBB. I'm just using it. And like many people out there running a phpBB forum, not the latest version of it either because they kept screwing with it and breaking customizability more and more.

As for comparing it with other formats like AVIF, just look at the description the JPEG=XL group themselves:
JPEG XL (.jxl) is the next-generation, general-purpose image compression codec by the JPEG committee. It was based on Google's Pik proposal and Cloudinary's FUIF proposal (which itself was based on FLIF).
So they have already combined several modern format proposals to come to this format which actually should make service providers happy that want to save every bit of bandwidth they can.
I personally think AVIF is just doing WebP again, as in taking a video format (AV1) and making a still/keyframe from it into an image format. vp8/vp9 just happens to do well in that scenario but doing it a second time won't really add anything useful. Kind of a one-trick-pony deal.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

jangdonggun1234
Fanatic
Fanatic
Posts: 104
Joined: 2013-06-06, 01:29

Re: Is JPEG-XL DOA?

Unread post by jangdonggun1234 » 2022-11-29, 08:40

JPEG-XL is actually a very good format, it gives better image quality than AVIF, a bit bigger file and, and faster compression speed so low-end server can do on-the-fly compression.

Recently I found a lot of Chrome fanboy running around bashing JPEG-XL to be a failure project because Chrome rejected it, lmao, ignoring the fact is big bois like Intel, Apple, Facebook support it (Source: https://connect.mozilla.org/t5/ideas/su ... di-p/18433 ).

It is very promising imo, just wait and see who will be the winner once server-side start to adapt it, big bois like Apple, Facebook start to implement it, and Intel and AMD start to product hardware (just like they produced GPUs that heavily optimized for deep learning) to optimize it.

So what is the keys of JPEG-XL:
- Good quality instead of garbage quality like AVIF
- Decent file size, yes bigger than AVIF but not a concern when quality is much better
- Faster compression speed which is a big deal for server-side, imagining that you need to run a server with 10.000 active user and they upload image daily, with such horrible compression speed AVIF is unusable unless you spend a tons of money to upgrade your server.
- Big bois do support it: https://connect.mozilla.org/t5/ideas/su ... di-p/18433

vannilla
Moon Magic practitioner
Moon Magic practitioner
Posts: 2183
Joined: 2018-05-05, 13:29

Re: Is JPEG-XL DOA?

Unread post by vannilla » 2022-11-29, 11:55

jangdonggun1234 wrote:
2022-11-29, 08:40
a failure project because Chrome rejected it
Unfortunately that will have a big impact on adoption unless peer pressure manages to make Google cave in and add support back in.
I mean, sure, this new format will likely be used for non-web uses, like maybe as the default output of phone cameras, but most people really only care about sharing their photos through web-based platforms, so being unable to see them in Chrome means 90% of people using a web browser will be left out of those photos, something these platforms can't do.

On a more "positive" note (it's not really positive if you look at the big picture, but it is here) since almost all of these platforms provide a mobile native application, i.e. it does not just display a web page but builds its interface using the mobile OS graphical toolkit and fetch data through a dedicated API, these applications can leverage their independence from Chrome to display the higher quality encoding.
Sure, Android applications are still limited by what Google decides can be used, but since Apple does support the new format we might expect them to add support in their mobile OS, at which point Google will be forced to also add it in, as otherwise they're going to lose a lot of people over to their competitors.

This is unrelated, but if web browsers were to still support plugins (NPAPI or whatever) this situation wouldn't be an issue. Much like current HTML supports fallbacks through the <source> element, a web developer could have simply used this mechanism to first try if the browser supported the format natively (with <source>), fall back to a plugin (with <object>) if it doesn't and finally display a low-quality version encoded on a known-supported format if the plugin was not installed.

User avatar
jobbautista9
Keeps coming back
Keeps coming back
Posts: 782
Joined: 2020-11-03, 06:47
Location: Philippines
Contact:

Re: Is JPEG-XL DOA?

Unread post by jobbautista9 » 2022-11-29, 12:14

Web developers can also use a decoder in WASM for JPEG-XL fallback. It's a bit slower of course but it should still be almost as fast as native decoding. One of the few good things about WASM I guess.
Image

merry mimas

XUL add-ons developer. You can find a list of add-ons I manage at http://rw.rs/~job/software.html.

Mima avatar by 絵虎. Pixiv post: https://www.pixiv.net/en/artworks/15431817

Image

vannilla
Moon Magic practitioner
Moon Magic practitioner
Posts: 2183
Joined: 2018-05-05, 13:29

Re: Is JPEG-XL DOA?

Unread post by vannilla » 2022-11-29, 17:07

Off-topic:
My main gripe with that approach is that adding support is still in the hands of someone else, in this case the people deciding what goes into the WASM code and people adding said code to their websites.
With a plugin, at the very least if you are not happy about something done by others, you can write your own and use that for your browsing. Additionally, website operators don't have to care about providing and keeping up to date the WASM but simply to add fallbacks in their DOM, something that can be performed by frameworks or similar with zero effort and zero additional maintenance.

BenFenner
Astronaut
Astronaut
Posts: 588
Joined: 2015-06-01, 12:52
Location: US Southeast

Re: Is JPEG-XL DOA?

Unread post by BenFenner » 2022-12-01, 01:55

I'm seeing JPEG-XL bug reports in the Linux repo thread ( viewtopic.php?p=234292#p234292 ) but this thread seems a tad more relevant.

I have a bug to report as well. On Pale Moon 31.4.1 (64-bit) when right clicking a JPEG-XL image (like found here: https://jpegxl.info ) if I choose the "View Image" option I would expect it to behave like any other image format, giving me a display of the image with a neutral grey background. Instead the browser issues the download/save dialog window, asking me where to save the file.

Is this something for the Pale Moon issue tracker, or the UXP issue tracker, or neither?
https://repo.palemoon.org/MoonchildProd ... oon/issues
https://repo.palemoon.org/MoonchildProd ... UXP/issues

User avatar
RealityRipple
Astronaut
Astronaut
Posts: 647
Joined: 2018-05-17, 02:34
Location: Los Berros Canyon, California
Contact:

Re: Is JPEG-XL DOA?

Unread post by RealityRipple » 2022-12-01, 06:21

Weirdly enough, that's not a bug, it's expected behavior. They're serving that file as application/octet-stream. Try http://demos.webmproject.org/webp/cmp/2022_10_04/comparisonfiles/subset1/small/JXL/08-2011._Panthera_tigris_tigris_-_Texas_Park_-_Lanzarote_-TP04.jxl instead. It's served as image/jxl as it should be.

User avatar
jobbautista9
Keeps coming back
Keeps coming back
Posts: 782
Joined: 2020-11-03, 06:47
Location: Philippines
Contact:

Re: Is JPEG-XL DOA?

Unread post by jobbautista9 » 2022-12-01, 08:50

Indeed, it happens in Chromium and Firefox too, so this is definitely not unique to Pale Moon.
Image

merry mimas

XUL add-ons developer. You can find a list of add-ons I manage at http://rw.rs/~job/software.html.

Mima avatar by 絵虎. Pixiv post: https://www.pixiv.net/en/artworks/15431817

Image

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35473
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Is JPEG-XL DOA?

Unread post by Moonchild » 2022-12-01, 14:45

BenFenner wrote:
2022-12-01, 01:55
I have a bug to report as well.
As others have stated this is not a bug, but maybe a bit more context is helpful. Because the webserver at jpegxl.info does not send a content type as image/jxl, the browser will not treat it as an image. Content type/MIME-type as sent by the server will always take priority over file extension or potentially content determined by inspecting the first few bytes of a file (content sniffing).
I find it equally surprising that the main website about JPEG-XL does not use the proper content/MIME-type headers for the format they promote, but it is what it is!
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

Michaell
Lunatic
Lunatic
Posts: 282
Joined: 2018-05-26, 18:13

Re: Is JPEG-XL DOA?

Unread post by Michaell » 2022-12-01, 14:58

RealityRipple wrote:
2022-12-01, 06:21
Weirdly enough, that's not a bug, it's expected behavior. They're serving that file as application/octet-stream. Try http://demos.webmproject.org/webp/cmp/2022_10_04/comparisonfiles/subset1/small/JXL/08-2011._Panthera_tigris_tigris_-_Texas_Park_-_Lanzarote_-TP04.jxl instead. It's served as image/jxl as it should be.
That loaded really fast for me. If the speed is due to the image format, I like it.
Win10home(1709), PM33.0.0-portable as of Feb 1, '24

vannilla
Moon Magic practitioner
Moon Magic practitioner
Posts: 2183
Joined: 2018-05-05, 13:29

Re: Is JPEG-XL DOA?

Unread post by vannilla » 2022-12-01, 15:16

Michaell wrote:
2022-12-01, 14:58
That loaded really fast for me. If the speed is due to the image format, I like it.
One of the goals of the new format is providing high quality with lower disk space usage, so yes, the speed is because of the format.
That picture in particular is not even 60KB, after all, despite being relatively large in dimensions.

Locked