Why: JPEG XL is the future of all image formats. It is a new royalty-free image codec targeting the image quality as found on the web, providing about 60% size savings when compared to original JPEG at the same perceptual quality, while supporting modern features like HDR, animation, alpha channel, lossless JPEG recompression, lossless and progressive modes. It is based on Google's PIK and Cloudinary's FUIF, and is in the final steps of standardization with ISO.
Chromium/Chrome and Firefox's dev versions already have initial implementations, so I'm hopeful that this will start becoming available within months.
Imagemagick already supports jpegxl, and I filed a request in gd.
I think it would be worthwhile for Piwigo to prepare for this. Once it is supported across browsers (see https://caniuse.com/jpegxl particularly its "notes" tab) I believe it should be the default public-facing format for Piwigo.
It can even losslessly recompress existing JPEG images (though in the case of Piwigo, assuming it keeps the uploads/ folder's contents as standard behavior, it doesn't have to, it could probably get even better-optimized results by re-generating all the sizes in _data/i/ from the uploads folder to do it "cleanly").
Currently my piwigo uploads/ folder weighs 1.6 gigabytes and the corresponding _data/i/ folder weighs 1.4 GB. I would look forward to that data folder shrinking to 400-700 MB...
Why: JPEG XL is the future of all image formats. It is a new royalty-free image codec targeting the image quality as found on the web, providing about 60% size savings when compared to original JPEG at the same perceptual quality, while supporting modern features like HDR, animation, alpha channel, lossless JPEG recompression, lossless and progressive modes. It is based on Google's PIK and Cloudinary's FUIF, and is in the final steps of standardization with ISO.
Explanation here: https://www.slideshare.net/cloudinarymarketing/imagecon-2019-jon-sneyer
Reference implementation here: https://gitlab.com/wg1/jpeg-xl
Chromium/Chrome and Firefox's dev versions already have initial implementations, so I'm hopeful that this will start becoming available within months.
Imagemagick already supports jpegxl, and I filed a [request in gd](https://github.com/libgd/libgd/issues/699).
I think it would be worthwhile for Piwigo to prepare for this. Once it is supported across browsers (see https://caniuse.com/jpegxl particularly its "notes" tab) I believe it should be the default public-facing format for Piwigo.
It can even losslessly recompress existing JPEG images (though in the case of Piwigo, assuming it keeps the `uploads/` folder's contents as standard behavior, it doesn't have to, it could probably get even better-optimized results by re-generating all the sizes in `_data/i/` from the `uploads` folder to do it "cleanly").
Currently my piwigo uploads/ folder weighs 1.6 gigabytes and the corresponding _data/i/ folder weighs 1.4 GB. I would look forward to that data folder shrinking to 400-700 MB...
<!-- github-sync-id:880823341 -->
In case you haven't seen it, https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs is interesting. You can see JPEG XL crushing HEIC/HEIF in many aspects, not only on the patents encumbrance front, but also quality/fidelity, which is probably what would interest Piwigo rather than "extreme low-bitrate" compression.
And JPEG XL has the notion of saliency, and "responsive" images (i.e. a single image file containing all the progressively decodeable resolutions), which would be particularly interesting to Piwigo if it could reduce the amount of files to generate and store/manage on the filesystem.
In case you haven't seen it, https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs is interesting. You can see JPEG XL crushing HEIC/HEIF in many aspects, not only on the patents encumbrance front, but also quality/fidelity, which is probably what would interest Piwigo rather than "extreme low-bitrate" compression.
And JPEG XL has the notion of saliency, and "responsive" images (i.e. a single image file containing all the progressively decodeable resolutions), which would be particularly interesting to Piwigo if it could reduce the amount of files to generate and store/manage on the filesystem.
<!-- github-comment-id:951515701 -->
Thanks for the link @nekohayo
Yes, JPEG XL should be used for storing photos and AVIF / HEIC should be used for storing videos.
Thanks for the link @nekohayo
Yes, JPEG XL should be used for storing photos and AVIF / HEIC should be used for storing videos.
<!-- github-comment-id:979415060 -->
As of now, https://caniuse.com/jpegxl clearly says that JPEG XL is not supported by web browsers. This is obviously the most important feature we ask to an image format to be used by Piwigo multiple sizes.
As of now, https://caniuse.com/jpegxl clearly says that JPEG XL is not supported by web browsers. This is obviously the most important feature we ask to an image format to be used by Piwigo multiple sizes.
<img width="1429" alt="Screenshot 2023-08-18 at 18 27 07" src="https://github.com/Piwigo/Piwigo/assets/9326959/f961431d-42f4-4b39-9728-725bb8ebc3ae">
<!-- github-comment-id:1684157341 -->
One thing missing from that chart is Epiphany and all WebKitGTK-based browsers (and other desktop web applications, like Evolution, Liferea, etc.) which are getting out-of-the-box JPEG XL support "for free" with recent versions of WebKitGTK already available today... which are underrepresented even though they arguably are more popular than the long tail of niche semi-abandonware planned-obsolescence smartphone browsers in that "Can I use?" table (like Samsung's, Opera Mini / Opera Mobile, UC Browser, QQ, Baidu, KaiOS, ...).
One thing missing from that chart is [Epiphany](https://en.wikipedia.org/wiki/GNOME_Web) and all WebKitGTK-based browsers (and other desktop web applications, like Evolution, Liferea, etc.) which are getting out-of-the-box JPEG XL support ["for free" with recent versions of WebKitGTK](https://bugs.webkit.org/show_bug.cgi?id=257871) already available today... which are underrepresented even though they arguably are more popular than the long tail of niche semi-abandonware planned-obsolescence smartphone browsers in that "Can I use?" table (like Samsung's, Opera Mini / Opera Mobile, UC Browser, QQ, Baidu, KaiOS, ...).
<!-- github-comment-id:1684576909 -->
In the "caniuse" table, I mainly focus on major web browsers. As far as I see, for the current date (august 2023), there is no way Piwigo can plan to switch from JPEG to JPEG XL.
I don't say no for the future. I would be happy to have multiple size cache use less storage space :-)
Thank you for these details.
In the "caniuse" table, I mainly focus on major web browsers. As far as I see, for the current date (august 2023), there is no way Piwigo can plan to switch from `JPEG` to `JPEG XL`.
I don't say no for the future. I would be happy to have multiple size cache use less storage space :-)
<!-- github-comment-id:1684931692 -->
Having just come across this in the new release of LR, and the fact it supports HDR, progressive image loading (instead of having to pre-process multiple image sizes) this is now looking like the format I will be using going forward.
Granted its early days, but it seems its a logical replacement for JPG.
So put a flag on my continued use of Piwigo based on the implementation of jpgxl.
Having just come across this in the new release of LR, and the fact it supports HDR, progressive image loading (instead of having to pre-process multiple image sizes) this is now looking like the format I will be using going forward.
Granted its early days, but it seems its a logical replacement for JPG.
So put a flag on my continued use of Piwigo based on the implementation of jpgxl.
<!-- github-comment-id:1807323215 -->
Hello! Jumping in just to note that JPEG XL support is not only valuable in the front end, but above all in the backend!
I would be super happy to start uploading all my pictures in JPEG XL in the meantime, not to wait for widespread support of the format for browser displaying.
Hello! Jumping in just to note that JPEG XL support is not only valuable in the front end, but above all in the backend!
I would be super happy to start uploading all my pictures in JPEG XL in the meantime, not to wait for widespread support of the format for browser displaying.
<!-- github-comment-id:1902550274 -->
It is also interesting to note how other similar projects handle JPEG XL support.
Photoprism supports it in the backend already!
https://github.com/photoprism/photoprism/issues/668
<!-- github-comment-id:1902551282 -->
Currently in the process of deciding which gallery software I use to host a 400k image archive library, JPEG-XL is my chosen format, is support coming or do I need to look at other options?
Thanks 😀👍
@plegall - any updates on plans for jxl support?
Currently in the process of deciding which gallery software I use to host a 400k image archive library, JPEG-XL is my chosen format, is support coming or do I need to look at other options?
Thanks 😀👍
<!-- github-comment-id:2039278794 -->
jxl definitely is the best image format for now, the second I think is avif. Unfortunately those two formats are not supported by Piwigo. All my photos are stored as jxl, it would be amazing if Piwigo would finally support jxl and avif.
jxl definitely is the best image format for now, the second I think is avif. Unfortunately those two formats are not supported by Piwigo. All my photos are stored as jxl, it would be amazing if Piwigo would finally support jxl and avif.
<!-- github-comment-id:3489724633 -->
i can also only recommend jxl support. its also possible to losslessly encode old jpgs into jxl with space savings, and the transformation back out to a bit-perfect jpeg file is very fast, could possibly just be done on the fly, then theres space savings and more or less no downsides for non-jxl capable clients
I myself have around 20k jxl's, and would to some degree be interested in using piwigo for it
i can also only recommend jxl support. its also possible to losslessly encode old jpgs into jxl with space savings, and the transformation back out to a bit-perfect jpeg file is very fast, could possibly just be done on the fly, then theres space savings and more or less no downsides for non-jxl capable clients
I myself have around 20k jxl's, and would to some degree be interested in using piwigo for it
<!-- github-comment-id:3786979096 -->
Since october 2026 .jxl is supported by all big browsers: firefox, chrome, safari, edge, opera, etc.
Since it allows much smaller file sizes than jpg and lossles conversion of old jpg files, it seems the perfect format for a photoserver like piwigo. It officialy replaces jpg and png.
Support of jxl would be very much appreciated in great piwigo server. thank you!
Since october 2026 .jxl is supported by all big browsers: firefox, chrome, safari, edge, opera, etc.
Since it allows much smaller file sizes than jpg and lossles conversion of old jpg files, it seems the perfect format for a photoserver like piwigo. It officialy replaces jpg and png.
Support of jxl would be very much appreciated in great piwigo server. thank you!
<!-- github-comment-id:6159305832 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Why: JPEG XL is the future of all image formats. It is a new royalty-free image codec targeting the image quality as found on the web, providing about 60% size savings when compared to original JPEG at the same perceptual quality, while supporting modern features like HDR, animation, alpha channel, lossless JPEG recompression, lossless and progressive modes. It is based on Google's PIK and Cloudinary's FUIF, and is in the final steps of standardization with ISO.
Explanation here: https://www.slideshare.net/cloudinarymarketing/imagecon-2019-jon-sneyer
Reference implementation here: https://gitlab.com/wg1/jpeg-xl
Chromium/Chrome and Firefox's dev versions already have initial implementations, so I'm hopeful that this will start becoming available within months.
Imagemagick already supports jpegxl, and I filed a request in gd.
I think it would be worthwhile for Piwigo to prepare for this. Once it is supported across browsers (see https://caniuse.com/jpegxl particularly its "notes" tab) I believe it should be the default public-facing format for Piwigo.
It can even losslessly recompress existing JPEG images (though in the case of Piwigo, assuming it keeps the
uploads/folder's contents as standard behavior, it doesn't have to, it could probably get even better-optimized results by re-generating all the sizes in_data/i/from theuploadsfolder to do it "cleanly").Currently my piwigo uploads/ folder weighs 1.6 gigabytes and the corresponding _data/i/ folder weighs 1.4 GB. I would look forward to that data folder shrinking to 400-700 MB...
Interesting and maybe in competition with HEIC format, also requested. cc @EddyLB
In case you haven't seen it, https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs is interesting. You can see JPEG XL crushing HEIC/HEIF in many aspects, not only on the patents encumbrance front, but also quality/fidelity, which is probably what would interest Piwigo rather than "extreme low-bitrate" compression.
And JPEG XL has the notion of saliency, and "responsive" images (i.e. a single image file containing all the progressively decodeable resolutions), which would be particularly interesting to Piwigo if it could reduce the amount of files to generate and store/manage on the filesystem.
Thanks for the link @nekohayo
Yes, JPEG XL should be used for storing photos and AVIF / HEIC should be used for storing videos.
As of now, https://caniuse.com/jpegxl clearly says that JPEG XL is not supported by web browsers. This is obviously the most important feature we ask to an image format to be used by Piwigo multiple sizes.
One thing missing from that chart is Epiphany and all WebKitGTK-based browsers (and other desktop web applications, like Evolution, Liferea, etc.) which are getting out-of-the-box JPEG XL support "for free" with recent versions of WebKitGTK already available today... which are underrepresented even though they arguably are more popular than the long tail of niche semi-abandonware planned-obsolescence smartphone browsers in that "Can I use?" table (like Samsung's, Opera Mini / Opera Mobile, UC Browser, QQ, Baidu, KaiOS, ...).
Thank you for these details.
In the "caniuse" table, I mainly focus on major web browsers. As far as I see, for the current date (august 2023), there is no way Piwigo can plan to switch from
JPEGtoJPEG XL.I don't say no for the future. I would be happy to have multiple size cache use less storage space :-)
Having just come across this in the new release of LR, and the fact it supports HDR, progressive image loading (instead of having to pre-process multiple image sizes) this is now looking like the format I will be using going forward.
Granted its early days, but it seems its a logical replacement for JPG.
So put a flag on my continued use of Piwigo based on the implementation of jpgxl.
Hello! Jumping in just to note that JPEG XL support is not only valuable in the front end, but above all in the backend!
I would be super happy to start uploading all my pictures in JPEG XL in the meantime, not to wait for widespread support of the format for browser displaying.
It is also interesting to note how other similar projects handle JPEG XL support.
Photoprism supports it in the backend already!
https://github.com/photoprism/photoprism/issues/668
@plegall - any updates on plans for jxl support?
Currently in the process of deciding which gallery software I use to host a 400k image archive library, JPEG-XL is my chosen format, is support coming or do I need to look at other options?
Thanks 😀👍
jxl definitely is the best image format for now, the second I think is avif. Unfortunately those two formats are not supported by Piwigo. All my photos are stored as jxl, it would be amazing if Piwigo would finally support jxl and avif.
i can also only recommend jxl support. its also possible to losslessly encode old jpgs into jxl with space savings, and the transformation back out to a bit-perfect jpeg file is very fast, could possibly just be done on the fly, then theres space savings and more or less no downsides for non-jxl capable clients
I myself have around 20k jxl's, and would to some degree be interested in using piwigo for it
Since october 2026 .jxl is supported by all big browsers: firefox, chrome, safari, edge, opera, etc.
Since it allows much smaller file sizes than jpg and lossles conversion of old jpg files, it seems the perfect format for a photoserver like piwigo. It officialy replaces jpg and png.
Support of jxl would be very much appreciated in great piwigo server. thank you!