Looking for API to get "version info" of supported image formats

[andypost]

Describe the bug
There's no "introspection API" to get which formats supported and which libraries' versions provides it

Faced with it working on php/php-src#7526 - no way to get libavif version if external GD used

To Reproduce
Steps to reproduce the behavior:

1. visit https://libgd.github.io/manuals/2.3.3/files/gd_version-c.html
2. Expected kind of "gdFormatsVersions"

Expected behavior
The function could return some structure with library versions (not sure static/dynamic linking)

Actual results
There's no way to get supported image format and its libraries version

Environment (please complete the following information):

• OS: Alpinelinux
• Version: 2.3.2
• All libraries used by GD and their respective version (eg. Freetype 2.2.5) - changing

Additional context
Looking for helper function to debug easier dependencies

[pierrejoye]

Good morning

It could be easy to implement but I am not sure it makes sense for libgd to provide as all of them are compile time defined. f.e. pkg-config (or in php's case, configure) defines that list.

We could define multiple struct with name, version, etc but that means every single scripting language would have to map it anyway, instead of using their own collection surrounded by the HAVE_* macros.

Libraries and codecs have also completely different meta info. Then they have options, some have plugins (like AVIF) which may be dynamically loaded at runtime. etc.

What we could do is one function specific for each codec. As each would have different information as well. Something like:

gdVersion<Major|Minor|String|..> or gdSupport etc. But again, almost all of this are compile time settings from a libgd point of view. The codecs options are runtime and here I am on a new encoding/decoding APIs allowing to access all options of a codec without us having to map each single of them using a new function (SetOption( of Name/value).

Happy to add anything that helps our users, if you have suggestions please let me know :)

[pierrejoye]

@cmb69 @vapier thoughts?

[cmb69]

I still think that libgd should provide this info to clients, because the client usually just includes gd.h, and not the individual headers of the used libraries. And, at least if there are several clients who would use this info, the same/similar code would need to be written only once.

[pierrejoye]

ok, not sure which format, to be useful programmatically for a caller.

…

On Mon, Oct 4, 2021, 5:28 PM Christoph M. Becker ***@***.***> wrote: I still think that libgd should provide this info to clients, because the client usually just includes gd.h, and not the individual headers of the used libraries. And, at least if there are several clients who would use this info, the same/similar code would need to be written only once. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#782 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACE6KBW5BEYRKWO6UQV66DUFF6TLANCNFSM5FGZ73RQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[vapier]

this needs to be more precisely defined

are we just talking about what features gd itself was configured with ? so restoring the FEATURES tracking what was dropped w/gdlib-config ? that is discussed in #345.

or are you asking the gd pass along the underlying library info too ? so for libavif, it should take care of calling & passing back the libavif version ? and do so with both the compile-time & runtime settings ? that's a bit more questionable.

[pierrejoye]

@vapier exactly, it is tricky.

A basic one with

png: true
tiff: true
..
would be possible.

However we need to add hash table or new structure for this. This structure will be copied/transformed anyway in the caller side to match, f.e., php hashtables or object (or lua, perl, etc)

I am really not sure it is worth it.

On the other hand, exposing each codec version and options using codec specific APIs makes sense.

[vapier]

if it's purely informational purposes, we could include a large string.

if we want something semi-programmatic, we could provide a const char * const tags[] that the caller would have to walk over and determine what to do. it'd have the same form as the old GD features setting.

i don't care much about that level of simple support, but expecting gd to query & expose underlying libraries directly seems too much for me.

[cmb69]

Frankly, I'm not sure what info to provide, and whether to add something ar all. But I really don't want clients to include headers which they would otherwise not. Maybe it's just that, in this case, PHP shouldn't bother.

[pierrejoye]

if it is only informational, easy to do as @vapier said. simple strings tuple name/value, both as string.

[andypost]

Other thread suggested to use gdSupportsFileType() but I can't figure from there about is .avif support exists only for read or encoder also present

[vapier]

are you asking about gd or the underlying library ? if gd is configured to call out to the underlying library (e.g. libavif), and that library is configured in a way to not include encoders, that seems to be getting into an area i don't think gd should venture. the underlying library could be reconfigured & reinstalled with encoder support and the gd library wouldn't change. so we'd have to write custom gd code to try and query the underlying library to see what it supports, assuming of course that it even supports such introspection itself ?