decide whether or not we care about ABI compat

[bdaehlie]

In mozjpeg 1.0 we broke ABI compatibility with the new configuration options. At the same time we've talked about trying to make it possible for our library to be a drop-in replacement for other libjpeg libraries. These are in conflict. We should either maintain ABI compatibility or give up on the idea that existing users might be able to, or should, use our library as a drop-in replacement.

I'm currently leaning towards the latter because most library users are better off sticking with libjpeg-turbo. This is because most users care about decoding and we aren't planning to invest in the decoder. Furthermore, the deployment context for our software, which is focused on the Web, will rarely involve mozjpeg being used in library form. Maintaining ABI compat is extra work we don't benefit much from, and it might give the wrong impression about replacing existing libjpeg usage with mozjpeg.

[kornelski]

I think mozjpeg as a replacement for system-wide libjpeg is an interesting option, e.g. I'd like to swap /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib in OS X to get Preview.app etc. to save JPEGs better (although it already has _Apple_IsOptionalFeatureAvailable symbol, so I'm not sure if that's feasible).

[ace-dent]

The goals of this project, IMHO, make it unsuitable for common library use.
+1 for dropping ABI compatibility.

[fwenzel]

FWIW, an interested party could probably write a wrapper from the libjpeg API to mozjpeg to create a drop-in replacement, but I concur that this shouldn't be a requirement for this project, as it'll unnecessarily restrict the ability to apply more "daring" changes.

[kornelski]

OK, sounds reasonable.

[dwbuiten]

As I noted in #63 (before I realize it was a dupe), if you guys choose the latter option, please allow some way for us downstream developers to differentiate between mozjpeg and vanilla jpeg headers... not providing one makes it really a pain in the butt to support mozjpeg a an option for downstream API users.

Aside: I do wonder why you'd choose IJG/jpeg-turbo to fork if the point wasn't to make a drop in replacement... it's API is... not the nicest.

Furthermore, the deployment context for our software, which is focused on the Web, will rarely involve mozjpeg being used in library form.

As someone who works on a fairly popular website (Vimeo), I would tend to disagree 😄.

EDIT: I forgot to mention a lot of people (I reckon perhaps the majority, but not us) of people use ImageMagick's convert utility, linked to libjpeg62 to generate JPEGs.

[kodabb]

@pornel be careful with that, all ImageIO libraries (libjpeg, libpng etc) functions are prefixed with cg_

[njdoyle]

I would also like to echo @dwbuiten in saying that I am much more interested in this as a library (particularly with ImageMagick compatibility) than I am in using it as an isolated tool.

[bdaehlie]

I've been discussing this with people for a while now, I think we're going to aim for ABI compat with libjpeg-turbo in v3.0. DRC, the primarily developer of libjpeg-turbo, has sent me a proposal for ABI extensions. We'll publish a plan soon, hopefully.

This issue is about deciding whether or not we're going to care about ABI compat. I think we've decided "yes", so I'm going to close this out and file a bug on coming up with a plan an implementing it.

[kornelski]

I can't find the DRC's proposal for the ABI extensions. Could you point me to it/share it?