# Finishing AVIF support in getimagesize() - Thread: https://externals.io/message/116543 - Original archive: https://news-web.php.net/php.internals/116543 - Started by Ben Morss via internals on 2021-11-30T23:52:54+00:00 - Messages: 10 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #116543 — Ben Morss via internals — 2021-11-30T23:52:54+00:00 URL: https://externals.io/message/116543#116543 Hello everyone! Earlier this year, I added support for AVIF images to libgd . My ultimate goal was to bring support for this new image format to PHP, so that the world's top CMSs could let sites serve AVIFs. A few of you kindly guided me as I made my first contributions to the PHP codebase, propagating libgd's new AVIF support into PHP's bundled gd fork, and adding AVIF awareness to non-gd functions like `getimagesize()` and imagecreatefromstring(). Unfortunately, when I worked on `getimagesize()`, AVIF experts advised that there was no compact, reliable way to determine the size of an AVIF image without relying on an external library like libavif. We decided that it was useful to return the information that a given image was an AVIF, but simply to return 0 for the actual dimensions and other details. The user would simply need to decode the image to determine this information. Of course, users would really like to use `getimagesize()` to return the actual size. So a colleague has kindly created standalone code (that doesn't depend on libavif) to do this, with the goal of adding it to PHP. The code comprises several hundred lines. But - it works, and it works well. Would it be ok to submit a PR containing this code to add this functionality? Or does someone have a superior approach? Thanks, and all best, Ben --- ## #116587 — Christoph M. Becker — 2021-12-08T11:40:37+00:00 URL: https://externals.io/message/116543#116587 · In reply to: #116543 > Earlier this year, I added support for AVIF images > to libgd > . My ultimate goal was to bring support for > this new image format to PHP, so that the world's top CMSs could let sites > serve AVIFs. A few of you kindly guided me as I made my first contributions > to the PHP codebase, propagating libgd's new AVIF support > into PHP's bundled gd fork, > and adding > AVIF awareness to non-gd > functions like `getimagesize()` and imagecreatefromstring(). > > Unfortunately, when I worked on `getimagesize()`, AVIF experts advised that > there was no compact, reliable way to determine the size of an AVIF image > without relying on an external library like libavif. We decided > that it > was useful to return the information that a given image was an AVIF, but > simply to return 0 for the actual dimensions and other details. The user > would simply need to decode the image to determine this information. > > Of course, users would really like > to use > `getimagesize()` to return the actual size. So a colleague has kindly > created standalone > code (that > doesn't depend on libavif) to do this, with the goal of adding it to PHP. > > The code comprises several hundred lines. But - it works, and it works well. > > Would it be ok to submit a PR containing this code to add this > functionality? Or does someone have a superior approach? Thanks for your and your colleague's work! It's highly appreciated. Anyhow, a respective PR[1] has been submitted now, and I'm in favor of bundling libavifinfo. I'm not too concerned regarding the additional size of the PHP binaries which would result by linking it in, but if others are, we could still introduce a configuration option (e.g. `--with-libavifinfo`). Thoughts? Objections to bundling libavifinfo at all? [1] -- Christoph M. Becker --- ## #116590 — Pierre Joye — 2021-12-08T16:02:33+00:00 URL: https://externals.io/message/116543#116590 · In reply to: #116587 Good evening, > > > l > > Thanks for your and your colleague's work! It's highly appreciated. > > Anyhow, a respective PR[1] has been submitted now, and I'm in favor of > bundling libavifinfo. I'm not too concerned regarding the additional > size of the PHP binaries which would result by linking it in, but if > others are, we could still introduce a configuration option (e.g. > `--with-libavifinfo`). > > Thoughts? Objections to bundling libavifinfo at all? > > [1] > On a general principle, I understood that bundling libs should be avoided. I am not totally sure aviinfo is stable enough to be bundle either way. The format will be widely used in a near future so i would rather allow it if libavinfo js available rather than bundling it. best, Pierre > > -- > > To unsubscribe, visit: https://www.php.net/unsub.php --- ## #116591 — Yannis Guyon via internals — 2021-12-08T18:22:42+00:00 URL: https://externals.io/message/116543#116591 · In reply to: #116590 > > On a general principle, I understood that bundling libs should be avoided. > libavifinfo was designed more as a copy-pastable snippet than a library. Unfortunately AVIF is complex and avifinfo.c is lengthier than expected, although I believe 700 lines are still reasonable and way below a library's scale. I am not totally sure aviinfo is stable enough to be bundle either way. > What would you call "stable enough"? There is a test , it is currently internally fuzzed and was successfully run on more than 60k crawled AVIF images. I do not plan on modifying or testing it further until the AVIF format changes. The format will be widely used in a near future so i would rather allow it > if libavinfo js available rather than bundling it. What would be the pros and cons of using a javascript version of libavifinfo rather than the C one? Thanks, Yannis --- ## #116592 — Christoph M. Becker — 2021-12-08T18:40:26+00:00 URL: https://externals.io/message/116543#116592 · In reply to: #116591 > > […] > > libavifinfo was designed more as a copy-pastable snippet than a library. Thanks for clarifying. > Unfortunately AVIF is complex and avifinfo.c is lengthier than expected, > although > I believe 700 lines are still reasonable and way below a library's scale. > > > […] > > What would you call "stable enough"? > There is a test > , > it is currently internally fuzzed > > and > was successfully run on more > than 60k crawled AVIF images. I do not plan on modifying or testing it > further > until the AVIF format changes. > > > […] > > What would be the pros and cons of using a javascript version of libavifinfo > rather than the C one? I think that "js" is a typo, and should have actually been "is". :) Anyhow, that is the point. If there will be no (widely available) libavifinfo, it makes sense to either bundle it, and have the full `getimagesize()` functionality for AVIF, or to not bundle it, and have only the most basic `getimagesize()` support for AVIF (as it is now). Christoph --- ## #116608 — Nikita Popov — 2021-12-09T19:45:37+00:00 URL: https://externals.io/message/116543#116608 · In reply to: #116587 On Wed, Dec 8, 2021 at 12:41 PM Christoph M. Becker wrote: > > > > […] > for > > […] > sites > > […] > contributions > > […] > it > > […] > (that > > […] > well. > > […] > > Thanks for your and your colleague's work! It's highly appreciated. > > Anyhow, a respective PR[1] has been submitted now, and I'm in favor of > bundling libavifinfo. I'm not too concerned regarding the additional > size of the PHP binaries which would result by linking it in, but if > others are, we could still introduce a configuration option (e.g. > `--with-libavifinfo`). > > Thoughts? Objections to bundling libavifinfo at all? > > [1] > Assuming no licensing concerns, bundling libavifinfo sounds reasonable. The library is small, our avif functionality is incomplete without it, and we can't expect this to be available as a system library at this time. Regards, Nikita --- ## #116609 — flaviohbatista@gmail.com — 2021-12-09T19:59:58+00:00 URL: https://externals.io/message/116543#116609 · In reply to: #116608 > On Wed, Dec 8, 2021 at 12:41 PM Christoph M. Becker > wrote: > > > […] > support > > […] > that > > […] > image > > […] > but > > […] > user > > […] > use > > […] > PHP. > > […] > > Assuming no licensing concerns, bundling libavifinfo sounds reasonable. The > library is small, our avif functionality is incomplete without it, and we > can't expect this to be available as a system library at this time. > > Regards, > Nikita > Although I'm not a core contributor, my 2c is that even with libavifinfo bundled, a configuration option is very welcome, the same way we have for png, jpeg, xpm and webp. As *cmb* said, thanks for your and your colleague's work! -- Atenciosamente, Flávio Heleno --- ## #116615 — Ben Morss via internals — 2021-12-09T21:30:11+00:00 URL: https://externals.io/message/116543#116615 · In reply to: #116608 Thanks for the discussion, everyone! Fortunately there are no licensing concerns, as the author is making this code available to be copied and pasted freely. And we've already got the build flag for avif. I'll be excited to see `getimagesize()` actually return the size for AVIF images ☺️ > On Wed, Dec 8, 2021 at 12:41 PM Christoph M. Becker > wrote: > > > […] > > Assuming no licensing concerns, bundling libavifinfo sounds reasonable. > The library is small, our avif functionality is incomplete without it, and > we can't expect this to be available as a system library at this time. > > Regards, > Nikita --- ## #116616 — Christoph M. Becker — 2021-12-09T21:56:50+00:00 URL: https://externals.io/message/116543#116616 · In reply to: #116609 > > > > […] > bundled, a configuration option is > very welcome, the same way we have for png, jpeg, xpm and webp. Whether AVIF support should be included for ext/gd is already configurable. This is solely about the getimagesize(fromstring) and image_type_to_* functions which are part of ext/std. We do not have configuration options for these for the other image formats either. -- Christoph M. Becker --- ## #116619 — flaviohbatista@gmail.com — 2021-12-10T00:39:09+00:00 URL: https://externals.io/message/116543#116619 · In reply to: #116616 > > > > […] > wrote: > > […] > fork, > > […] > that > > […] > The > > […] > we > > […] > > Whether AVIF support should be included for ext/gd is already > configurable. This is solely about the getimagesize(fromstring) and > image_type_to_* functions which are part of ext/std. We do not have > configuration options for these for the other image formats either. > > -- > Christoph M. Becker > Got it! I was refering to the general avif support, glad to see that it's already there =)