IJG libjpeg vs libjpeg-turbo
baggins at pld-linux.org
Tue Jan 29 11:51:58 CET 2013
On Sat, 19 Jan 2013, Tomasz Pala wrote:
> On Fri, Jan 18, 2013 at 17:41:29 +0100, Jakub Bogusz wrote:
> >> - why 7+?
> > Quoting original post:
> > the implementation of the libjpeg v7+ API and ABI would remain just
> > that: an emulation and not a feature-complete implementation of jpeg-7
> > or jpeg-8."
> - I recall no reports of missing features in turbo (shipped and used as so.8),
> so maybe they are so rarely used (if any at all) that we shouldn't care,
> - ABI is emulated, so in case of such report (3rd party app?) user
> should simply switch to IJG's .so.8 (that we shall provide as well).
> >> - are there any apps like this?
> > I'm not sure, it needs checking.
> > Also, I don't know if libjpeg-turbo supports compilation as 12-bit.
> libjpeg-turbo doesn't provide any performance advantage over libjpeg for
> 12-bit data, and it isn't possible to use libjpeg-turbo for both 8-bit and
> 12-bit data at the same time. Thus, either way, you're going to end up having
> to call two different libraries if you want to support both 8-bit and 12-bit
> JPEGs in the same application. At the moment, you're better off using the
> upstream libjpeg code for 12-bit, since they actually test 12-bit data.
> > libtiff can use both 8- and 12-bit variants of libjpeg (both formats
> > can be embedded in TIFF).
> > Should we use 8-bit libjpeg-turbo and 12-bit IJG libjpeg?
> As far as I understand it properly, 12-bit libs can't handle 8-bit
> JPEGs, so we shouldn't replace any lib with 12-bit version. IMHO we
> should have:
> libjpeg-turbo with 8-bit jpeg.so.8
> libjpeg with 8-bit jpeg.so.8 (for people that found missing/not emulated features,
> or use hardware without SIMD)
> libjpeg9 for some new apps, that might arise
> libjpeg in 12-bit variant as low-priority option (not used anyway).
I second that, it looks to be the best solution.
Jan Rękorajski | PLD/Linux
SysAdm | http://www.pld-linux.org/
More information about the pld-devel-en