On 10 January 2013 10:44, Ismail Doenmez
Hi,
I am sorry it look such a long time to write this email. During openSUSE 12.2 development we switched to jpeg-turbo as our libjpeg implementation. This has several reasons:
I was going to ask why with the --with-jpeg8 flag since upstream, LSB and Fedora use the .62 ABI. But during this time Fedora has also changed (and reverted the change for F18?? http://pkgs.fedoraproject.org/cgit/libjpeg-turbo.git/commit/?h=f18&id=0dcdbef7939bd6e8eaeb04c70d24666a6256f544), so there is no so much point any more. If we are happy dropping support for third-party binaries requiring libjpeg.so.62. And with only having a libjpeg.so.8 version that lacks supports for (from http://sourceforge.net/p/libjpeg-turbo/code/892/tree/trunk/README-turbo.txt): -- libjpeg: DCT scaling in compressor cinfo.scale_num and cinfo.scale_denom are silently ignored. There is no technical reason why DCT scaling cannot be supported, but without the SmartScale extension (see below), it would only be able to down-scale using ratios of 1/2, 8/15, 4/7, 8/13, 2/3, 8/11, 4/5, and 8/9, which is of limited usefulness. -- libjpeg: SmartScale cinfo.block_size is silently ignored. SmartScale is an extension to the JPEG format that allows for DCT block sizes other than 8x8. It would be difficult to support this feature while retaining backward compatibility with libjpeg v6b. -- libjpeg: Fancy downsampling in compressor cinfo.do_fancy_downsampling is silently ignored. This requires the DCT scaling feature, which is not supported. -- jpegtran: Scaling This requires both the DCT scaling and SmartScale features, which are not supported. -- Lossless RGB JPEG files This requires the SmartScale feature, which is not supported. (no idea how relevant any of these features is) I am OK with it. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org