libjpeg vs. libjpeg-turbo

[Mihai Moldovan]

On 24.05.2015 04:43 PM, 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. I might decide to downgrade port:jpeg to v8 just to bring it in line with the alternatives, but I think I won't. I'm just not convinced that recent/fast machines will see any measurable gain from the whole exercise.

TLDR: you're making a great fuzz about essentially nothing; deeper explanation
below.


I see you are concerned about getting the exact same output out of an encoded
JPEG image. libjpeg-turbo fulfills this purpose. Iff all algorithms are
implemented adhering to specification, a JPEG decoder will always produce the
same raw output. The "magic" lies within the JPEG encoder, but that's not
breaking anything, given that encoders should adhere to the specifications (and
libjpeg-turbo does that, being a fork of the original IJG jpeg software anyway.)

Naturally, new features as implemented in IJG jpeg won't be supported, but those
are not formally standardized yet and I don't see this happening either. They
are informal, experimental extensions and are not reviewed with much love in the
standardization committees.

Your whole "fear" gets even important when keeping in mind that the JPEG decoder
used in OS X as implemented in Apple's ImageIO framework is not IJG jpeg or even
a fork of that anyway, but a totally new implementation. If this whole stuff
concerns you so much, the fact that native Cocoa stuff uses an entirely
different implementation should have been driving you the walls for a long time
already now.

And that's not even keeping in mind cross-platform issues potentially coming
from *other* platform's software again, like Microsoft's own implementation in
the Windows API (or wherever exactly they implemented it.)



Mihai

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <https://lists.macosforge.org/pipermail/macports-users/attachments/20150524/b58e62de/attachment.sig>