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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
