libjpeg vs. libjpeg-turbo

[Ryan Schmidt]

On May 24, 2015, at 9:43 AM, René J.V. Bertin wrote:

> On Sunday May 24 2015 02:16:06 Ryan Schmidt wrote:
> 
>> I don't currently plan to keep a functional jpeg port around. If it turns out later that some port or someone absolutely requires the original libjpeg we can add a new port for it at that time, but based on other distributions adopting libjpeg-turbo I don't foresee that need arising.
> 
> I think I made it clear that I have this requirement, but I suppose I'll just keep extending my own port repository.

No, sorry, I missed that you have this requirement. Why do you need libjpeg instead of libjpeg-turbo?

> I might decide to downgrade port:jpeg to v8 just to bring it in line with the alternatives,

If we do keep a port for libjpeg after replacing jpeg with libjpeg-turbo, I would probably make it for version 8 instead of 9. If we need it, I imagine I'll create a new port libjpeg (as opposed to the existing jpeg port which will be marked replaced_by libjpeg-turbo) and make it install into a nonstandard prefix so that any who need it can get to it but so that it won't be used automatically.

> but I think I won't. I'm just not convinced that recent/fast machines will see any measurable gain from the whole exercise.

...which exercise?


>> MacPorts does not currently keep track of library version information. I'm not saying it would be bad to do so, just that we currently don't. Are you proposing that the jpeg library ports alone should track this (what makes them special?)
> 
> The issue is moot if port:jpeg is discontinued. If it's not, it's special in that there are 3 alternatives that each provide one of two ABI versions, and only port:jpeg being unambiguous about what version it provides.
> Anyway, I think it's something that can be decided upon on a case-by-case basis. There is precedence; gstreamer comes to mind.

gstreamer1 and gstreamer010 are named after the project version number, not any included library's version number. There are many many ports named after the project version number, but none that I know of that are named after an enclosed library's version number (except of course in cases where those are the same number, but they usually aren't).


>> (such as is the case for libjpeg-turbo vs. mozjpeg).
> 
> About that: the libjpeg-turbo site makes a rather strong point that mozjpeg isn't suitable (or at least not a logical candidate) as a generic libjpeg replacement.

Yeah, I just read that yesterday... There was also some concern that software compiled with mozjpeg would not be compatible with libjpeg-turbo, but I think that's outdated information and that it's not a problem anymore since mozjpeg 3, though I'll try to confirm that.

But if we don't let the user choose between libjpeg-turbo and mozjpeg, how then is a user who wants to use mozjpeg going to do that? Imagine I want to compress a bunch of images using ImageMagick, and I want them to be as small as possible, and I don't care if it takes longer to encode them. That's what mozjpeg is for. I had envisioned that in this situation, I would force-deactivate libjpeg-turbo, activate mozjpeg, and then use ImageMagick as planned. Then when I was done I would deactivate mozjpeg and re-activate libjpeg-turbo. Though thinking about it now, I guess for that use case it wouldn't really matter if ImageMagick declared its dependency on path:lib/libjpeg.dylib:libjpeg-turbo or just port:libjpeg-turbo; either way, libjpeg-turbo will have to be forcibly deactivated.