> We could emulate the libjpeg v9 API/ABI easily enough, but why? The only purpose would be to support applications or O/S distributions that had upgraded from jpeg-8 to jpeg-9, but it is our opinion that no technical justification exists for this upgrade.
This "only" justification might have made sense for that moment in time, but a new reason now might be a newer project that picked up a recent IJC library and inadvertently became dependent on the newer ABI. Not because they depend on newer features, but just by virtue of the devs coding against what was there.
Today libjpeg and its various forks are a bit of a potential DLL hell type issue. I think a lot of people just pick a favorite version, bundle it with their source tree and link statically.
BTW, libjpeg turbo had been selected by JPEG (the group) as the reference implementation.
There's no reason to entertain the old incompatible libjpeg fork. It didn't have any worthy compression improvements, and if you can use something less universally compatible, there's JPEG XL and AVIF, or even the old JPEG with arithmetic compression or Lepton recompressor.
This "only" justification might have made sense for that moment in time, but a new reason now might be a newer project that picked up a recent IJC library and inadvertently became dependent on the newer ABI. Not because they depend on newer features, but just by virtue of the devs coding against what was there.
Today libjpeg and its various forks are a bit of a potential DLL hell type issue. I think a lot of people just pick a favorite version, bundle it with their source tree and link statically.