IJG libjpeg vs libjpeg-turbo

[Jan Rękorajski]

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.
> 
> http://sourceforge.net/p/libjpeg-turbo/discussion/1086868/thread/f4639c19/
> http://sourceforge.net/p/libjpeg-turbo/discussion/1086868/thread/701941fc/
> 
> 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[89] 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/
baggins<at>mimuw.edu.pl
baggins<at>pld-linux.org