I guess what I meant was that libpng is (currently) the only implementation that attempts to fit a libpng-shaped hole. Not in the sense of being API or ABI compatible, but in the sense of being a free-floating multiplatform library solely dedicated to PNGs, rather than a higher-level multiformat library or OS API.
Because of this, libpng gets linked in by a lot of the higher-level multiformat libraries (like SDL) or graphics toolkits (like WxWidgets) when their aim is also to be “portable” free-floating multiplatform libraries, rather than libraries that have special per-OS code-paths for everything. (Which becomes especially important in things like embedded OSes/unikernels, or sandboxes like Emscripten, where there aren’t any OS image APIs.) And these portable libraries and toolkits then get used by runtimes that want portability, like Erlang or Love2D; or by software that can’t access the OS’s SDK to link to system libraries, like game-console homebrew.
In these cases, the feature-set of libpng determines the PNG features that these higher-level libraries support. SDL supports loading animated images—but not from APNG, because libpng doesn’t provide SDL with that capability. SDL isn’t going to do the work of adding their own APNG support; they’ve got enough on their plate just making sure all their components stay glued together. But if there was a “better” PNG library than libpng, that ticked all the same portability boxes? They’d switch.
Because of this, libpng gets linked in by a lot of the higher-level multiformat libraries (like SDL) or graphics toolkits (like WxWidgets) when their aim is also to be “portable” free-floating multiplatform libraries, rather than libraries that have special per-OS code-paths for everything. (Which becomes especially important in things like embedded OSes/unikernels, or sandboxes like Emscripten, where there aren’t any OS image APIs.) And these portable libraries and toolkits then get used by runtimes that want portability, like Erlang or Love2D; or by software that can’t access the OS’s SDK to link to system libraries, like game-console homebrew.
In these cases, the feature-set of libpng determines the PNG features that these higher-level libraries support. SDL supports loading animated images—but not from APNG, because libpng doesn’t provide SDL with that capability. SDL isn’t going to do the work of adding their own APNG support; they’ve got enough on their plate just making sure all their components stay glued together. But if there was a “better” PNG library than libpng, that ticked all the same portability boxes? They’d switch.