You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ISO/IEC DIS 18181-1 is not completely done with being a standard. But this means format will not change anymore. I think it's a good time to start implementing it.
Reacted by Tim, Oleg Lavrovsky, Xavier Brochard, Alex Rogozhnikov, Martin, exu-g, Suraj and Nate Reinar Windwood
Hello, I wrote a Pillow plugin for Jpeg XL.
It's included in my Python module jxlpy which is based on Christoph Gohlke's project :)
I think it might be useful in this issue.
Reacted by Hugo van Kemenade
Reacted by Hugo van Kemenade
Reacted by doublex, kjerk, brunoais, styler00dollar, Paolo Benvenuto, Alex Rogozhnikov, Martin, exu-g, Arun, Yves Quemener and 4 more
If everyone supports it Googles arguments get even more invalid, and maybe they will re-add support. We can't let Google dictate what becomes standard.
There's already lots of software with JpegXL support.
Reacted by brunoais, buster-blue, Yay295, schrmh, Martin, TIAcode, Niko Honu, benf-write, Zoltán Nyikos, Zarxrax and 24 more
You say that but most images on my PC are already .jxl and just not all of them because some python software I use is waiting for Pillow to support JXL so they also support it.
Reacted by buster-blue, Joshix-1, Martin, Niko Honu, benf-write, Zoltán Nyikos, Zarxrax, pkrause1980, Mitchel Stewart, Alex Rogozhnikov and 5 more
The same thing that is holding back every new feature - time. While Tidelift is generous, Pillow is worked on in our spare time, and complex functionality is often sidelined while dealing with the deluge of other issues and PRs that are created.
Ideally, a PR with clear reference to documentation, and dependencies that fit within our license.
Small update: iOS 17 has JPEG XL support. Works in Safari and Photos app and reportedly (some?) third party apps.
I hope this serves as a lesson for everybody to just keep on promoting the sane standards until they get adoption and to not give up just because a major player doesn't want to support something (yet). Especially if their proposed alternatives are just worse in most areas.
By the way, imlib2 is another library used by a lot of programs that has read and write JXL support (got the author to add the latter by opening an issue).
If I weren't already busy with a bunch of other projects I would gladly try to help on the software side of widely used imaging libraries to make adoption happen quicker.
However, maybe this comment can help at making an enthusiastic developer work on JPEG XL support for pillow.
Reacted by brunoais, buster-blue, Niko Honu, h-vetinari, Duker, p13rr0m, Rob Speed, wessven, radonmiser, PalladiuM and 1 more
Both Chrome and Firefox now support JPEG-XL. That means there's a huge new audience that can benefit from JPEG-XL images. It would be great if Pillow also could support it natively.
We had a PR open to add this but it made the wheels around 50% larger, which is unfortunately too much. See #7848 (comment). I made some suggestions at #9101 (comment), but no-one showed interest. Still open to other options, and there are at least three Pillow plugins available on PyPI.
I think it’s important maintainers either give A) some direction how they want to approach JPEG-XL support or B) what additional information they need to make that decision.
31. I think it’s important maintainers either give A) some direction how they want to approach JPEG-XL support or B) what additional information they need to make that decision.
I don't think any of the wheel-shrinking efforts have resulted in "zero increase" which is about what we'd need to make JPEG-XL support in Pillow feasible, IIUC. The second best option is probably a pillow-jpegxl plugin which I think already exists ?
I'm not opposed to taking ownership of something like a pillow-jpegxl plugin in the Pillow organization, but it's not likely to happen with "4 underpaid volunteers" doing all the work.
31. I'm a lurker.
Have any of you considered delegating the read-write duties to imageio?
Delegating to imageio won't work because imageio has no image codecs of its own. It wraps other libraries, and its main backend for ordinary image formats is Pillow itself (imageio.plugins.pillow). Any JPEG XL support it has would also come from someone else's binding to libjxl. If Pillow delegated to imageio, imageio would mostly be handing the work back to Pillow or to a third-party plugin.
Delegating to imageio won't work because imageio has no image codecs of its own.[...] If Pillow delegated to imageio, imageio would mostly be handing the work back to Pillow or to a third-party plugin.
I am surprised and shocked. Thanks for making me aware of this. I was aware that it delegates to some third party libraries (e.g. PyAV for video) but did assume that it had some capability of its own.
Activity
DonaldTsang commentedon Dec 4, 2019
https://github.com/google/brunsli claims that Python is already supported.
radarhere commentedon Dec 4, 2019
It does look that way! https://github.com/google/brunsli/blob/master/contrib/py/jxl_library_patches/jxl_pillow.py
varnav commentedon Dec 31, 2020
JPEG XL format was recently frozen
DonaldTsang commentedon Jan 3, 2021
@varnav so it has been standarized and passed through, correct?
varnav commentedon Jan 3, 2021
ISO/IEC DIS 18181-1 is not completely done with being a standard. But this means format will not change anymore. I think it's a good time to start implementing it.
doublex commentedon May 11, 2021
Maybe this code could be used:
https://github.com/cgohlke/imagecodecs/blob/master/imagecodecs/_jpegxl.pyx
olokelo commentedon Jul 7, 2021
Hello, I wrote a Pillow plugin for Jpeg XL.
It's included in my Python module jxlpy which is based on Christoph Gohlke's project :)
I think it might be useful in this issue.
doublex commentedon Jul 7, 2021
@olokelo
Great news!
brunoais commentedon Dec 25, 2022
Hello!
Is there anything missing to move this from the icebox to the backlog?
aclark4life commentedon Dec 25, 2022
@brunoais Looks like we can now tentatively declare support via @olokelo 's plugin? (Thank you @olokelo !)
Joshix-1 commentedon Dec 29, 2022
the plugin had no release since over a year. There are multiple issues from people that are unable to install it
I would appreciate built-in support
doublex commentedon Jan 2, 2023
JXL is probably dead:
https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84
Joshix-1 commentedon Jan 2, 2023
If everyone supports it Googles arguments get even more invalid, and maybe they will re-add support. We can't let Google dictate what becomes standard.
There's already lots of software with JpegXL support.
brunoais commentedon Jan 2, 2023
You say that but most images on my PC are already
.jxland just not all of them because some python software I use is waiting for Pillow to support JXL so they also support it.1 remaining item
radarhere commentedon May 6, 2023
The same thing that is holding back every new feature - time. While Tidelift is generous, Pillow is worked on in our spare time, and complex functionality is often sidelined while dealing with the deluge of other issues and PRs that are created.
Ideally, a PR with clear reference to documentation, and dependencies that fit within our license.
schrmh commentedon Jun 6, 2023
Small update: iOS 17 has JPEG XL support. Works in Safari and Photos app and reportedly (some?) third party apps.
I hope this serves as a lesson for everybody to just keep on promoting the sane standards until they get adoption and to not give up just because a major player doesn't want to support something (yet). Especially if their proposed alternatives are just worse in most areas.
By the way, imlib2 is another library used by a lot of programs that has read and write JXL support (got the author to add the latter by opening an issue).
If I weren't already busy with a bunch of other projects I would gladly try to help on the software side of widely used imaging libraries to make adoption happen quicker.
However, maybe this comment can help at making an enthusiastic developer work on JPEG XL support for pillow.
rspeed commentedon Jul 19, 2023
macOS 14 as well.
[-]Preparation for JPEG XL support[/-][+]JPEG XL support[/+]j99ca commentedon Nov 6, 2023
Is there any progress on this feature? I noticed this library popped up in pypi
schrmh commentedon Nov 6, 2023
@Isotr0py is here on GitHub as well as it seems, as well as their project: https://github.com/Isotr0py/pillow-jpegxl-plugin
However, it looks like this uses Rust bindings and it doesn't look like the Pillow repo has Rust code as of now.
Maybe they still can do this
olokelo commentedon Mar 2, 2024
Hello again, for anyone interested please observe PR #7848 that enables read only support of JPEG XL images.
EwoutH commentedon Oct 12, 2026
Both Chrome and Firefox now support JPEG-XL. That means there's a huge new audience that can benefit from JPEG-XL images. It would be great if Pillow also could support it natively.
hugovk commentedon Oct 12, 2026
We had a PR open to add this but it made the wheels around 50% larger, which is unfortunately too much. See #7848 (comment). I made some suggestions at #9101 (comment), but no-one showed interest. Still open to other options, and there are at least three Pillow plugins available on PyPI.
EwoutH commentedon Oct 19, 2026
There are now multiple efforts to move JPEG-XL support further along.
libjxl_decalready saves a large portion of binary size, I proposed that here Link JPEG XL support against libjxl_dec olokelo/Pillow#3I think it’s important maintainers either give A) some direction how they want to approach JPEG-XL support or B) what additional information they need to make that decision.
aclark4life commentedon Oct 19, 2026
I don't think any of the wheel-shrinking efforts have resulted in "zero increase" which is about what we'd need to make JPEG-XL support in Pillow feasible, IIUC. The second best option is probably a
pillow-jpegxlplugin which I think already exists ?I'm not opposed to taking ownership of something like a
pillow-jpegxlplugin in the Pillow organization, but it's not likely to happen with "4 underpaid volunteers" doing all the work.crackwitz commentedon Oct 19, 2026
I'm a lurker.
Have any of you considered delegating the read-write duties to
imageio?aclark4life commentedon Oct 19, 2026
Delegating to imageio won't work because imageio has no image codecs of its own. It wraps other libraries, and its main backend for ordinary image formats is Pillow itself (imageio.plugins.pillow). Any JPEG XL support it has would also come from someone else's binding to libjxl. If Pillow delegated to imageio, imageio would mostly be handing the work back to Pillow or to a third-party plugin.
crackwitz commentedon Oct 19, 2026
I am surprised and shocked. Thanks for making me aware of this. I was aware that it delegates to some third party libraries (e.g. PyAV for video) but did assume that it had some capability of its own.