New image formats support - WebP, AVIF, Heic #996

New Issue

2026-10-05T00:27:07+02:00

adam commented

2026-10-05 00:27:07 +02:00

Hi,

There are opened different issues considering support of mentioned formats (WebP,Heif) by Piwigo.
WebP and HEIC are for some time fully supported by major browsers and systems (well WebP is boycotted by apple - but this is their problem). Those formats are also supported for a long time by ImageMagick (and clones).
So implementation (for someone knowing Piwigo code) should be quite straight forward.

Soon we should also have AVIF support for all browsers - but for other tools I guess it will take some time.
Anyway - I think it's time to add those formats, and perhaps make it easier to add other new ones (without "switch" and "if's" - like it's now) in the future or Piwigo will fall behind the others.

Is this support even considered now?

Hi, There are opened different issues considering support of mentioned formats ([WebP](https://github.com/Piwigo/Piwigo/issues/223),[Heif](https://piwigo.org/forum/viewtopic.php?id=28440)) by Piwigo. WebP and HEIC are for some time fully supported by major browsers and systems (well WebP is boycotted by apple - but this is their problem). Those formats are also supported for a long time by ImageMagick (and clones). So implementation (for someone knowing Piwigo code) should be quite straight forward. Soon we should also have AVIF support for all browsers - but for other tools I guess it will take some time. Anyway - I think it's time to add those formats, and perhaps make it easier to add other new ones (without "switch" and "if's" - like it's now) in the future or Piwigo will fall behind the others. Is this support even considered now?

adam closed this issue

2026-10-05 00:27:07 +02:00

adam commented

2026-10-05 00:27:08 +02:00

Actually it seems that this should be extremely simple to do - but I'm not sure if it's the "proper" way.
To accept and generate miniatures for webp images (it would be better to make all thumbnails and intermediate images webp also - even for jpeg) it's enough to modify 2 files:

/admin# grep -ri -A1 webp *
include/functions_upload.inc.php:    if (IMAGETYPE_WEBP == $type)
include/functions_upload.inc.php-    {
include/functions_upload.inc.php:      $file_path.= 'webp';
include/functions_upload.inc.php-    }
--
include/image.class.php:    if (!in_array($extension, array('jpg', 'jpeg', 'png', 'gif', 'webp')))
include/image.class.php-    {

There is also action.php/i.php in main directory - that perhaps also needs to be modified (not sure)

# grep -i -B1 webp *.php
action.php-    case "gif": $ctype="image/gif"; break;
action.php:    case "webp": $ctype="image/webp"; break;
--
i.php-    case ".jpe": case ".jpeg": case ".jpg": $ctype="image/jpeg"; break;
i.php:    case ".webp": $ctype="image/webp"; break;

This works in my gallery.

Actually it seems that this should be extremely simple to do - but I'm not sure if it's the "proper" way. To accept and generate miniatures for webp images (it would be better to make all thumbnails and intermediate images webp also - even for jpeg) it's enough to modify 2 files: ``` /admin# grep -ri -A1 webp * include/functions_upload.inc.php: if (IMAGETYPE_WEBP == $type) include/functions_upload.inc.php- { include/functions_upload.inc.php: $file_path.= 'webp'; include/functions_upload.inc.php- } -- include/image.class.php: if (!in_array($extension, array('jpg', 'jpeg', 'png', 'gif', 'webp'))) include/image.class.php- { ``` There is also action.php/i.php in main directory - that perhaps also needs to be modified (not sure) ``` # grep -i -B1 webp *.php action.php- case "gif": $ctype="image/gif"; break; action.php: case "webp": $ctype="image/webp"; break; -- i.php- case ".jpe": case ".jpeg": case ".jpg": $ctype="image/jpeg"; break; i.php: case ".webp": $ctype="image/webp"; break; ``` This works in my gallery.

adam commented

2026-10-05 00:27:09 +02:00

Will this also generate webm for already existing images?

Will this also generate webm for already existing images?

adam commented

2026-10-05 00:27:09 +02:00

Will this also generate webm for already existing images?

Definitely not, it will also probably (just haven't checked) generate jpeg thumbnails for jpeg images, and webp only for webp images.

> Will this also generate webm for already existing images? Definitely not, it will also probably (just haven't checked) generate jpeg thumbnails for jpeg images, and webp only for webp images.

adam commented

2026-10-05 00:27:10 +02:00

I see.
I will try to develop script to convert all images and add full WEBP support.

I see. I will try to develop script to convert all images and add full WEBP support.

adam commented

2026-10-05 00:27:11 +02:00

I see.
I will try to develop script to convert all images and add full WEBP support.

Hey any update on the code?

> I see. > I will try to develop script to convert all images and add full WEBP support. Hey any update on the code?

adam commented

2026-10-05 00:27:11 +02:00

I would love this as well, especially for HEIC pics!

I would love this as well, especially for HEIC pics!

adam commented

2026-10-05 00:27:12 +02:00

Any update on this in Piwigo 11? (I don't see any detailed changelog for 11).

Any update on this in Piwigo 11? (I don't see any detailed changelog for 11).

adam commented

2026-10-05 00:27:13 +02:00

First time checking out this software. Wondering if it still uploads heic and just doesn't render it or what support it's actually missing. Curious how it would affect me as a user.

First time checking out this software. Wondering if it still uploads heic and just doesn't render it or what support it's actually missing. Curious how it would affect me as a user.

adam commented

2026-10-05 00:27:13 +02:00

There are two threads about this aberration at the forums which might give you some insight in the challenges they present

https://piwigo.org/forum/viewtopic.php?id=28440

https://piwigo.org/forum/viewtopic.php?id=29809

There are two threads about this aberration at the forums which might give you some insight in the challenges they present https://piwigo.org/forum/viewtopic.php?id=28440 https://piwigo.org/forum/viewtopic.php?id=29809

adam commented

2026-10-05 00:27:14 +02:00

For me, what I would like to see is the option to import original HEIC files. Let me put it this way. Piwigo currently doesn't serve the original JPEG files when you are browsing a gallery. It serves resized JPEG files (while keeping the original JPEG intact and available as an optional download if the user really wants the original file). I would be happy with only the ability to import original HEIC files into my gallery with Piwigo generating resized JPEGs for various resolutions (as is currently done for JPEG originals). I have no interest at all in Piwigo serving HEIC files--just the ability to import and generate JPEGs. Hope this makes sense? Perhaps I should create a separate issue for this suggestion?

For me, what I would like to see is the option to import original HEIC files. Let me put it this way. Piwigo currently doesn't serve the original JPEG files when you are browsing a gallery. It serves resized JPEG files (while keeping the original JPEG intact and available as an optional download if the user really wants the original file). I would be happy with only the ability to import original HEIC files into my gallery with Piwigo generating resized JPEGs for various resolutions (as is currently done for JPEG originals). I have no interest at all in Piwigo serving HEIC files--just the ability to import and generate JPEGs. Hope this makes sense? Perhaps I should create a separate issue for this suggestion?

adam commented

2026-10-05 00:27:15 +02:00

Piwigo mostly does not serve original files - but this depends on your skin/theme. In my case, when you enable full screen - it's an original file.
But this is not a case here. JPEG is awfully old, and it's here just like painful GIF was (now mostly eradicated). There are new, better containers and codecs and there will be more. So this should be something that could be easily extended in the future.
Now big sites (not all - but more, and more) are using webp - because it's supported for quite a long time in all browsers (so it's working for most of the users), and it allows to save traffic - just take a look at youtube (and NOT at the suffix - but the picture itself, because sometimes .jpeg contains webp images), all aliexpress/alibaba is on webp images.
There is also HEIF/C container - that can have images encoded with HEVC/H265, video etc. - but for me, since it's proprietary, it's least important stuff.
And we have AV1/AVIF in close proximity - where all the SOC already support it for future mobile usage.

With that long description I just want to point out, that this is bigger issue then just to add this picture type, or add that picture type - this should be more flexible in general.

Piwigo _mostly_ does not serve original files - but this depends on your skin/theme. In my case, when you enable full screen - it's an original file. But this is not a case here. JPEG is awfully old, and it's here just like painful GIF was (now mostly eradicated). There are new, better containers and codecs and there will be more. So this should be something that could be easily extended in the future. Now big sites (not all - but more, and more) are using webp - because it's supported for quite a long time in all browsers (so it's working for most of the users), and it allows to save traffic - just take a look at youtube (and NOT at the suffix - but the picture itself, because sometimes .jpeg contains webp images), all aliexpress/alibaba is on webp images. There is also HEIF/C container - that can have images encoded with HEVC/H265, video etc. - but for me, since it's proprietary, it's least important stuff. And we have AV1/AVIF in close proximity - where all the SOC already support it for future mobile usage. With that long description I just want to point out, that this is bigger issue then just to add this picture type, or add that picture type - this should be more flexible in general.

adam commented

2026-10-05 00:27:16 +02:00

I found in the forum that with the additional configuration it is possible to find additional format files, so with something like this

$conf['picture_ext'] = array('jpg','jpeg','png','gif', 'pef', 'orf'); $conf['file_ext'] = array_merge( $conf['picture_ext'], array('tiff', 'tif', 'mpg','zip','avi','mp3','ogg','pdf') );

files with additional extensions are added to galleries (in my case *.ORF and *.PEF - two raw image formats) and the formats also added to picture_ext are considered image formats.

Ideally all formats supported by the image converter tool (ImageMagick in my case) could be supported and be served with piwigo, as it usually resizes the files anyway. For this resizing, in my understanding, Piwigo takes the image path, modifies it with two letters indicating the resize size and gives the task to the converter to resize the file original_path to size whatever to derivative_path. From the file extension of said paths imagick deduces the desired output format - which is no problem for formats supported by imagick as output and browsers as input. It is, if e.g. imagick is not able to output those raw formats at all, and even if it could no browser could display it. Imagick can be forced to output to a certain format, even if it does not match the file extenison, but this is not really helpful either, because my browser did not display anything for a jpg file with a pef extension.

So what I tried was to append the extension .jpg to the derivative file path, if the current extension was not one of the originally supported image formats, and now imagick creates the required resized images. But it does not seem to serve the images on the first try, after reloading it works - I'm not sure wherever the derivative path is also created without the appended alternative jpg extension.

To get to the current state I:

Changed the config as described
Modified image.class.php to also contain other extensions for the image class not to die with "unsupported file extension": if (!in_array($extension, array('jpg', 'jpeg', 'png', 'gif', 'orf', 'pef')))
Added this if clause to modify the derivative path (i.php):

  $extension = strtolower(get_extension($page['derivative_path']));
  if (!in_array($extension, array('jpg', 'jpeg', 'png', 'gif')))
  {
    $page['derivative_path'].=".jpg";
  }

Now it does serve my raw files (sometimes), but I'm also not sure what else gets broken by this modification.

I found in the forum that with the additional configuration it is possible to find additional format files, so with something like this ` $conf['picture_ext'] = array('jpg','jpeg','png','gif', 'pef', 'orf'); $conf['file_ext'] = array_merge( $conf['picture_ext'], array('tiff', 'tif', 'mpg','zip','avi','mp3','ogg','pdf') ); ` files with additional extensions are added to galleries (in my case *.ORF and *.PEF - two raw image formats) and the formats also added to `picture_ext` are considered image formats. Ideally all formats supported by the image converter tool (ImageMagick in my case) could be supported and be served with piwigo, as it usually resizes the files anyway. For this resizing, in my understanding, Piwigo takes the image path, modifies it with two letters indicating the resize size and gives the task to the converter to resize the file _original_path_ to size whatever to _derivative_path_. From the file extension of said paths imagick deduces the desired output format - which is no problem for formats supported by imagick as output and browsers as input. It is, if e.g. imagick is not able to output those raw formats at all, and even if it could no browser could display it. Imagick can be forced to output to a certain format, even if it does not match the file extenison, but this is not really helpful either, because my browser did not display anything for a jpg file with a pef extension. So what I tried was to append the extension .jpg to the derivative file path, if the current extension was not one of the originally supported image formats, and now imagick creates the required resized images. But it does not seem to serve the images on the first try, after reloading it works - I'm not sure wherever the derivative path is also created without the appended alternative jpg extension. To get to the current state I: - Changed the config as described - Modified image.class.php to also contain other extensions for the image class not to die with "unsupported file extension": `if (!in_array($extension, array('jpg', 'jpeg', 'png', 'gif', 'orf', 'pef')))` - Added this if clause to modify the derivative path (i.php): ```$page['derivative_path'] = PHPWG_ROOT_PATH.PWG_DERIVATIVE_DIR.$req; $extension = strtolower(get_extension($page['derivative_path'])); if (!in_array($extension, array('jpg', 'jpeg', 'png', 'gif'))) { $page['derivative_path'].=".jpg"; } ``` Now it does serve my raw files (sometimes), but I'm also not sure what else gets broken by this modification.

adam commented

2026-10-05 00:27:17 +02:00

as it's wide adoption a lot of images are now in .heic format. It would be a big plus to have support for this format. Thank you!

as it's wide adoption a lot of images are now in .heic format. It would be a big plus to have support for this format. Thank you!

adam commented

2026-10-05 00:27:17 +02:00

Just my 2¢: I would much rather prefer JPEG XL support (issue #1407) as a "first-class citizen", with its very interesting unique feature set (lossless forwards-and-backwards-compatible conversion from legacy JPEG, built-in responsive multi-sizes, etc. etc. at 60% smaller filesizes) and the fact that it is open-source, royalty-free and unencumbered by patents.

Just my 2¢: I would much rather prefer JPEG XL support (issue #1407) as a "first-class citizen", with its very interesting unique feature set (lossless forwards-and-backwards-compatible conversion from legacy JPEG, built-in responsive multi-sizes, etc. etc. at 60% smaller filesizes) and the fact that it is open-source, royalty-free and unencumbered by patents.

adam commented

2026-10-05 00:27:18 +02:00

It might be helpful to know that there is already a PHP wrapper for JPEG XL handling:

https://github.com/joppuyo/jpeg-xl-encode

It might be helpful to know that there is already a PHP wrapper for JPEG XL handling: https://github.com/joppuyo/jpeg-xl-encode

adam commented

2026-10-05 00:27:19 +02:00

I have just installed piwigo for the first time and was very disappointed by the absence of the HEIC support. Almost all new images now in the HEIC format.

I have just installed piwigo for the first time and was very disappointed by the absence of the HEIC support. Almost all new images now in the HEIC format.

adam commented

2026-10-05 00:27:20 +02:00

It is a shame as the iOS mobile app is really good, but it insists on converting to jpeg before uploading. I don't want to lose data through a conversion.

It is a shame as the iOS mobile app is really good, but it insists on converting to jpeg before uploading. I don't want to lose data through a conversion.

adam commented

2026-10-05 00:27:20 +02:00

My $0.02. Considering that Apple iPhone sales have now surpassed Android phones, marketwise (at least in the US market), I think there's kind of no escaping the need to take the .HEIC format seriously...

My sense that it would be wise to add .heic, .webp, .avif and .jxl, just to be as compatible as possible, thereby removing reasons for new users to hesitate to migrate their photo collections to piwigo.

My $0.02. Considering that Apple iPhone sales have now surpassed Android phones, marketwise (at least in the US market), I think there's kind of no escaping the need to take the .HEIC format seriously... My sense that it would be wise to add .heic, .webp, .avif and .jxl, just to be as compatible as possible, thereby removing reasons for new users to hesitate to migrate their photo collections to piwigo.

adam commented

2026-10-05 00:27:21 +02:00

Amazing that this is even a discussion

Amazing that this is even a discussion

adam commented

2026-10-05 00:27:22 +02:00

I have added a post on this discussion https://piwigo.org/forum/viewtopic.php?pid=184432#p184432

I have added a post on this discussion https://piwigo.org/forum/viewtopic.php?pid=184432#p184432

adam commented

2026-10-05 00:27:22 +02:00

If we have https://github.com/Piwigo/Piwigo/pull/1785, it's as easy as adding the new format to the extension. I tested this with webp and it worked. (e.g. the only change needed is in the admin/include/image.class.php as in the pull request)

If we have https://github.com/Piwigo/Piwigo/pull/1785, it's as easy as adding the new format to the extension. I tested this with webp and it worked. (e.g. the only change needed is in the admin/include/image.class.php as in the pull request)

adam commented

2026-10-05 00:27:23 +02:00

It's all in https://github.com/Piwigo/Piwigo/pull/1785 now. This would support serving webp files. Maybe someone can test too?

It's all in https://github.com/Piwigo/Piwigo/pull/1785 now. This would support serving webp files. Maybe someone can test too?

adam commented

2026-10-05 00:27:24 +02:00

I have just manually made the updates from #1785 to my install of 13.3.0 using the 'Modus' theme. The uploading and display of WebP images works fine. The only problem I am seeing is the other sizes for thumbnails are not being generated. Instead I just get the 'themes/default/icon/img_small.png' image stretched to the thumbnail size.

See bottom thumbnail here, which is my test WebP image:

If I click on that thumbnail then the full size WebP is displayed fine.

I have just manually made the updates from #1785 to my install of 13.3.0 using the 'Modus' theme. The uploading and display of WebP images works fine. The only problem I am seeing is the other sizes for thumbnails are not being generated. Instead I just get the 'themes/default/icon/img_small.png' image stretched to the thumbnail size. See bottom thumbnail here, which is my test WebP image: ![image](https://user-images.githubusercontent.com/74139324/205442959-6a5655c1-2c4e-4974-a9d1-c7f7c80f42d9.png) If I click on that thumbnail then the full size WebP is displayed fine.

adam commented

2026-10-05 00:27:25 +02:00

It is the only reason why I haven’t started using Piwigo. I use iPhone and Mac, all my photos and videos are HEIC and HEVC.

It is the only reason why I haven’t started using Piwigo. I use iPhone and Mac, all my photos and videos are HEIC and HEVC.

adam commented

2026-10-05 00:27:25 +02:00

What is being forgotten is that not only is HEIF is not supported by any browser, but also that HEVC is a patent nightmare, which makes it a non-starter in my opinion. Other image formats such as WebP or AVIF are well supported with no patent problems, but they would still require some conversion from JPEG or HEIF.

What is being forgotten is that not only is HEIF is [not supported by any browser](https://caniuse.com/?search=heif), but also that HEVC is a patent nightmare, which makes it a non-starter in my opinion. Other image formats such as WebP or AVIF are well supported with no patent problems, but they would still require some conversion from JPEG or HEIF.

adam commented

2026-10-05 00:27:26 +02:00

In lieu of full support for HEIC, which is kind of a non-starter with the lack of browser support, would it be possible for Piwigo to allow them to be uploaded and just automatically create a JPEG version for display?

In lieu of full support for HEIC, which is kind of a non-starter with the lack of browser support, would it be possible for Piwigo to allow them to be uploaded and just automatically create a JPEG version for display?

adam commented

2026-10-05 00:27:27 +02:00

I have just manually made the updates from #1785 to my install of 13.3.0 using the 'Modus' theme. The uploading and display of WebP images works fine. The only problem I am seeing is the other sizes for thumbnails are not being generated. Instead I just get the 'themes/default/icon/img_small.png' image stretched to the thumbnail size.

If I click on that thumbnail then the full size WebP is displayed fine.

admin/include/image.class.php:

else if ($extension == 'webp') { $this->image = imagecreatefromwebp($source_filepath); }

> I have just manually made the updates from #1785 to my install of 13.3.0 using the 'Modus' theme. The uploading and display of WebP images works fine. The only problem I am seeing is the other sizes for thumbnails are not being generated. Instead I just get the 'themes/default/icon/img_small.png' image stretched to the thumbnail size. > > If I click on that thumbnail then the full size WebP is displayed fine. admin/include/image.class.php: ` else if ($extension == 'webp') { $this->image = imagecreatefromwebp($source_filepath); }`

adam commented

2026-10-05 00:27:27 +02:00

In lieu of full support for HEIC, which is kind of a non-starter with the lack of browser support, would it be possible for Piwigo to allow them to be uploaded and just automatically create a JPEG version for display?

I agree and this is what we're going to do. HEIC has become the default file format created by iPhone Camera and now it seems common on Android too. Piwigo really needs to support it by default. Since we can't display an *.heic file on a web browser, Piwigo will have to generate a *.jpg file as "representative" (like we do for a PDF file)

For webP (which is less urgent in my opinion) we don't need the "representative" because it can be directly displayed on any web browser AND Piwigo (thanks to ImageMagick) can generated multiple-sizes as *.webp files.

> In lieu of full support for HEIC, which is kind of a non-starter with the lack of browser support, would it be possible for Piwigo to allow them to be uploaded and just automatically create a JPEG version for display? I agree and this is what we're going to do. HEIC has become the default file format created by iPhone Camera and now it seems common on Android too. Piwigo really needs to support it by default. Since we can't display an `*.heic` file on a web browser, Piwigo will have to generate a `*.jpg` file as "representative" (like we do for a PDF file) For webP (which is less urgent in my opinion) we don't need the "representative" because it can be directly displayed on any web browser AND Piwigo (thanks to ImageMagick) can generated multiple-sizes as `*.webp` files.

adam commented

2026-10-05 00:27:28 +02:00

For Piwigo 14, we will be able to upload *.heic files. Piwigo will generate a *.jpg representative file and use it for displaying multiple sizes. The HEIC file will be kept as "original" file.

For Piwigo 14, we will be able to upload `*.heic` files. Piwigo will generate a `*.jpg` representative file and use it for displaying multiple sizes. The HEIC file will be kept as "original" file.

adam commented

2026-10-05 00:27:29 +02:00

HEIC was for me a highly important image format to support for Piwigo. It is indeed currently the default format used by iOS and Android.

Concerning WebP and AVIF : does any camera use these image format? or is "just" a format some advanced users decide to convert their JPEG files into? That make a big difference for Piwigo.

`HEIC` was for me a highly important image format to support for Piwigo. It is indeed currently the default format used by iOS and Android. Concerning `WebP` and `AVIF` : does any camera use these image format? or is "just" a format some advanced users decide to convert their JPEG files into? That make a big difference for Piwigo.

adam commented

2026-10-05 00:27:30 +02:00

It's a bit misguided point of view - perhaps Apple is forcing HEIC (but this is apple - they don't care about anything/anybody else then apple), and for some time it's at least possible to use that container/encoder on Samsung phones (I don't know if it's whole Android) as camera output. But it's (at least I haven't seen) not used at all on Internet - compare to WebP. Also I don't know full adoption of HEIC in browsers (and other tiny clients) - webp is there for a long time.
But anyway, again, I don't think adding one more codec/container to Piwigo is good thinking. At this point we should have ability to add any type(s) of container/encoder that is supported by PHP/external app - both to upload it to gallery and to be able to choose as miniature container. This solution would be flexible for future usage when other, better, filetypes will be available - or simply get popular (like AVIF).

It's a bit misguided point of view - perhaps Apple is forcing HEIC (but this is apple - they don't care about anything/anybody else then apple), and for some time it's at least possible to use that container/encoder on Samsung phones (I don't know if it's whole Android) as camera output. But it's (at least I haven't seen) not used at all on Internet - compare to WebP. Also I don't know full adoption of HEIC in browsers (and other tiny clients) - webp is there for a long time. But anyway, again, I don't think adding _one_ more codec/container to Piwigo is good thinking. At this point we should have ability to add any type(s) of container/encoder that is supported by PHP/external app - both to upload it to gallery and to be able to choose as miniature container. This solution would be flexible for future usage when other, better, filetypes will be available - or simply get popular (like AVIF).

adam commented

2026-10-05 00:27:30 +02:00

We're mixing 2 topics here:

supporting additionnal image format "as input"
using a better image format than JPEG "as output" (to store multiple size files in cache)

The support of HEIC is a response to the first issue. The fact that iphones and android phones use this file format is a very important matter. Saying "photos taken with iphones can't be uploaded in Piwigo" is clearly not an appropriate answer. I use an iPhone. So do the members of my family. Currently, the Piwigo iOS app converts the photo before upload, but a support of HEIC server-side would be much better. And sometimes, you sync your iphone with your computer and upload from the computer...

Supporting WebP would be for the second issue. As far as I see it, JPEG is not that bad of a deal. We may find better in terms of filesize with the same quality, but would we have the same support by web browsers? I'm not ready to say "it is not supported by Microsoft Edge, doesn't matter".

Do you agree?

We're mixing 2 topics here: 1. supporting additionnal image format "as input" 2. using a better image format than JPEG "as output" (to store multiple size files in cache) The support of `HEIC` is a response to the first issue. The fact that iphones and android phones use this file format is a very important matter. Saying "photos taken with iphones can't be uploaded in Piwigo" is clearly not an appropriate answer. I use an iPhone. So do the members of my family. Currently, the Piwigo iOS app converts the photo before upload, but a support of HEIC server-side would be much better. And sometimes, you sync your iphone with your computer and upload from the computer... Supporting WebP would be for the second issue. As far as I see it, JPEG is not that bad of a deal. We may find better in terms of filesize with the same quality, but would we have the same support by web browsers? I'm not ready to say "it is not supported by Microsoft Edge, doesn't matter". Do you agree?

adam commented

2026-10-05 00:27:31 +02:00

I can agree that we have two issues here - type of files we can upload and better format for thumbnails/intermediate miniatures.
But I don't feel other issue (phone one) - since I don't upload anything directly from camera. First I do post processing and I want to output it in the best possible quality (with sane size - so 32bit PNG is no go) to have ability to do something with it later - without the need to process it again. That's why I use webp (and hope to use AVIF later on).
I dont remember (this topic is that old) how Piwigo stores original image - but it should be stored unmodified - so we can regenerate thumbinails later on how it fits us (we could even generate both jpeg and avif (or heif - as uses chooses) thumbs for older and more modern browsers).
Also being able to upload image to gallery, with format changes (and/or scaling) on the way (so doing it google/facebook style) - doesn't satisfy my needs, I would say. It's a private gallery, so I should be able to configure it much more flexible then mentioned before big G/F - other wise where is the point?

I can agree that we have two issues here - type of files we can upload and better format for thumbnails/intermediate miniatures. But I don't feel other issue (phone one) - since I don't upload anything directly from camera. First I do post processing and I want to output it in the best possible quality (with sane size - so 32bit PNG is no go) to have ability to do something with it later - without the need to process it again. That's why I use webp (and hope to use AVIF later on). I dont remember (this topic is that old) how Piwigo stores original image - but it should be stored unmodified - so we can regenerate thumbinails later on how it fits us (we could even generate both jpeg and avif (or heif - as uses chooses) thumbs for older and more modern browsers). Also being able to upload image to gallery, with format changes (and/or scaling) on the way (so doing it google/facebook style) - doesn't satisfy my needs, I would say. It's a private gallery, so I should be able to configure it much more flexible then mentioned before big G/F - other wise where is the point?

adam commented

2026-10-05 00:27:32 +02:00

I agree that as long as PHP/ImageMagick can handle a format, it should be supported "as input" to give more flexibility. Piwigo storing originals as they are uploaded, this would be perfect. And the iOS and Android apps would save time and energy by uploading smaller files.

As for "as output", it is clear that Piwigo should use a format compatible with most browsers… and the iOS and Android apps which also download thumbnails.

I agree that as long as PHP/ImageMagick can handle a format, it should be supported "as input" to give more flexibility. Piwigo storing originals as they are uploaded, this would be perfect. And the iOS and Android apps would save time and energy by uploading smaller files. As for "as output", it is clear that Piwigo should use a format compatible with most browsers… and the iOS and Android apps which also download thumbnails.

adam commented

2026-10-05 00:27:33 +02:00

For the output/storage format issue: I think some of you may be forgetting that JPEG XL has these unique advantages making it an attractive storage (and eventually output) format for Piwigo:

lossless reencoding (just save 20% on your existing JPEGs, for free, reversible; or save even more if you agree to some slight imperceptible loss),
progressive decoding, and saliency
blazing fast to encode, unlike HEIC and AVIF
responsive format (multiple sizes/versions within the same file), which would be a huge deal for Piwigo's storage simplicity (see #1407)
is supported by Safari 17 (and WebKit, and all iOS and macOS devices starting Q4 2023), Epiphany 45 (WebKitGTK) and pretty much all of GNOME going forward. I'm hoping Mozilla / Firefox gets moving again towards supporting it, then you have two (or arguably three) major browser players supporting it, with only Blink/Chromium lagging behind.
is supported by pretty much all the creative graphics+photo software apps out there, the list is quite long
is royalty-free and open source, unlike HEIC

I see no reason to bother with WebP or other formats for output, once JXL gains a little bit more traction in the web browser space; presuming any such format choice is not something you want to do multiple times, and that it is not instantaneous to accomplish, my take would be that it's better to leapfrog from JPEG directly to JPEG XL that would seem much more future-proof.

For the output/storage format issue: I think some of you may be forgetting that JPEG XL has these unique advantages making it an attractive storage (and eventually output) format for Piwigo: * lossless reencoding (just save 20% on your existing JPEGs, for free, reversible; or save even more if you agree to some slight imperceptible loss), * progressive decoding, and [saliency](https://opensource.googleblog.com/2021/09/using-saliency-in-progressive-jpeg-xl-images.html) * blazing fast to encode, unlike HEIC and AVIF * responsive format (multiple sizes/versions within the same file), which would be a huge deal for Piwigo's storage simplicity (see #1407) * is [supported by Safari 17](https://developer.apple.com/documentation/safari-release-notes/safari-17-release-notes) (and WebKit, and all iOS and macOS devices starting Q4 2023), Epiphany 45 (WebKitGTK) and pretty much all of GNOME going forward. I'm hoping Mozilla / Firefox gets moving again towards supporting it, then you have two (or arguably three) major browser players supporting it, with only Blink/Chromium lagging behind. * is supported by pretty much all the creative graphics+photo software apps out there, the list is [quite long](https://en.wikipedia.org/wiki/JPEG_XL#Official_support) * is royalty-free and open source, unlike HEIC I see no reason to bother with WebP or other formats for output, once JXL gains a little bit more traction in the web browser space; presuming any such format choice is not something you want to do multiple times, and that it is not instantaneous to accomplish, my take would be that it's better to leapfrog from JPEG directly to JPEG XL that would seem much more future-proof.

adam commented

2026-10-05 00:27:33 +02:00

[switching output, ie multiple-size cache, to JPEG XL] it is not instantaneous to accomplish

Well... it's not that complicated. It's not a big rewrite of the way Piwigo manages multiple-sizes. Unless we do this:

responsive format (multiple sizes/versions within the same file

This would be complicated to implement and make Piwigo extensions compatible with this system.

> [switching output, ie multiple-size cache, to JPEG XL] it is not instantaneous to accomplish Well... it's not that complicated. It's not a big rewrite of the way Piwigo manages multiple-sizes. Unless we do this: > responsive format (multiple sizes/versions within the same file This would be complicated to implement and make Piwigo extensions compatible with this system.

adam commented

2026-10-05 00:27:34 +02:00

Made many tests on animated WEBP files today. Very very interesting. Much smaller than GIF files. Keep animation after resize.

Made many tests on animated WEBP files today. Very very interesting. Much smaller than GIF files. Keep animation after resize.

adam commented

2026-10-05 00:27:35 +02:00

Found this topic as I have just switched (finally) to HEIC on my Samsung phone, but I can't now upload (input) my photos to my Piwigo site. It is no longer just Apple that uses HEIC as their camera format (Samsung, OPPO and Xiaomi also support it). Samsung has many phones out there and the recommendation is really to use the more modern, smaller size format. So yes, I also need to input/upload in HEIC format as upload items will also be quicker than JPG. Everything else I use on Linux for editing, viewing, etc is happy with my HEIC format. AVIF is even newer but my camera does not store in it, and some software does not yet support it. So me HEIC is now my standard for stills and video.

The other matter is the back-end storage and I agree that could be WEBP for similar reasons (or AVIF?). It is already now more broadly supported and is a lot more efficient space-wise than JPG. I've started using WEBP on my WordPress site and it is very happy with that format.

Found this topic as I have just switched (finally) to HEIC on my Samsung phone, but I can't now upload (input) my photos to my Piwigo site. It is no longer just Apple that uses HEIC as their camera format (Samsung, OPPO and Xiaomi also support it). Samsung has many phones out there and the recommendation is really to use the more modern, smaller size format. So yes, I also need to input/upload in HEIC format as upload items will also be quicker than JPG. Everything else I use on Linux for editing, viewing, etc is happy with my HEIC format. AVIF is even newer but my camera does not store in it, and some software does not yet support it. So me HEIC is now my standard for stills and video. The other matter is the back-end storage and I agree that could be WEBP for similar reasons (or AVIF?). It is already now more broadly supported and is a lot more efficient space-wise than JPG. I've started using WEBP on my WordPress site and it is very happy with that format.

adam commented

2026-10-05 00:27:36 +02:00

I've been able to resize/crop animated webP (and keep the animation).

Problem found for now : webP does not support IPTC. EXIF are supported. XMP are also supported, but Piwigo does not use them. Meaning: if you want to import photos with embedded metadata, you still have to stick to JPEG+IPTC.

I've been able to resize/crop animated webP (and keep the animation). Problem found for now : webP does not support IPTC. EXIF are supported. XMP are also supported, but Piwigo does not use them. Meaning: if you want to import photos with embedded metadata, you still have to stick to JPEG+IPTC.

adam commented

2026-10-05 00:27:36 +02:00

I have merged pull-request by @Phlogi and I have then added some more code changes, mainly to support animated webP images, see this old issue #223

I have merged pull-request by @Phlogi and I have then added some more code changes, mainly to support animated webP images, see this old issue #223

adam commented

2026-10-05 00:27:37 +02:00

I close this issue, because we have added support for HEIC and WebP in Piwigo 14. I don't forget AVIF/JPEG XL. We will just need separate issues for each of them (or else this very issue would last forever)

I close this issue, because we have added support for HEIC and WebP in Piwigo 14. I don't forget AVIF/JPEG XL. We will just need separate issues for each of them (or else this very issue would last forever)

adam commented

2026-10-05 00:27:38 +02:00

When I import a HEIC format file it makes a thumb size image any way to make them larger like JPG

When I import a HEIC format file it makes a thumb size image any way to make them larger like JPG

adam commented

2026-10-05 00:27:39 +02:00

@plegall The expected behavior on v14 is for it to store the .heic somewhere, right? I'm new to this software, but mine doesnt seem to be storing them anywhere. I only see the jpegs

@plegall The expected behavior on v14 is for it to store the .heic somewhere, right? I'm new to this software, but mine doesnt seem to be storing them anywhere. I only see the jpegs

adam commented

2026-10-05 00:27:40 +02:00

I confirm the HEIC file is not converted into a JPEG file. It is kept "as original". Then Piwigo generates a "representative" (or a "preview" if you prefer) in JPEG format. We do this because an HEIC can't be reliably displaid in a web browser. So yes, you only see JPEG images, but if you download the original you get your HEIC file.

I confirm the HEIC file is not converted into a JPEG file. It is kept "as original". Then Piwigo generates a "representative" (or a "preview" if you prefer) in JPEG format. We do this because an HEIC can't be reliably displaid in a web browser. So yes, you only see JPEG images, but if you download the original you get your HEIC file.

Sign in to join this conversation.

master

issue-2560-people

translation

16.x

feat/embedding-based-contextual-tagging

issue-2576-search-include-ai-in-search-results

feat/search-ocr-ai

issue-2391-update-menu-design

15.x

detect-container

issue-2386-update-filters-users-activity

issue-2362-add-filters-options-in-admin

issue-2367-imagemagick7

issue-2225-quicksearch-help

14.x

issue-2164-BatchManagerUnitMode-Redesign

13.x

12.x

issue-1657-SVG_Support

issue-1703-historySearchMethod

11.x

2.10

2.9

2.8

2.7

2.5

2.6

2.4

2.3

2.2

2.1

2.0

1.7

1.3

1.6

1.5

1.4

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/Piwigo#996