IJG libjpeg vs libjpeg-turbo

[Tomasz Pala]

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).

-- 
Tomasz Pala <gotar at pld-linux.org>