From b87136c2c7b9f9545c4ced25e7435e373b4760f7 Mon Sep 17 00:00:00 2001 From: DRC Date: Fri, 18 Jan 2013 06:12:51 +0000 Subject: [PATCH] Include justification for not supporting SmartScale, DCT scaling, and the libjpeg v9 ABI git-svn-id: svn+ssh://svn.code.sf.net/p/libjpeg-turbo/code/trunk@912 632fc199-4ca6-4c93-a231-07263d6284db --- README-turbo.txt | 46 ++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 38 insertions(+), 8 deletions(-) diff --git a/README-turbo.txt b/README-turbo.txt index 90424ee..71c3992 100755 --- a/README-turbo.txt +++ b/README-turbo.txt @@ -313,20 +313,32 @@ Fully supported when using libjpeg v7/v8 emulation: Not supported: +NOTE: As of this writing, extensive research has been conducted into the +usefulness of DCT scaling as a means of data reduction and SmartScale as a +means of quality improvement. The reader is invited to peruse the research at +http://www.libjpeg-turbo.org/About/SmartScale and draw his/her own conclusions, +but it is the general belief of our project that these features have not +demonstrated sufficient usefulness to justify inclusion in libjpeg-turbo. + -- 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. + There is no technical reason why DCT scaling could not be supported when + emulating the libjpeg v7+ API/ABI, but without the SmartScale extension (see + below), only scaling factors of 1/2, 8/15, 4/7, 8/13, 2/3, 8/11, 4/5, and + 8/9 would be available, 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. Providing support for this new format is feasible - (particularly without full acceleration), but until/unless the format - becomes either an official industry standard or, at minimum, an accepted - solution in the community, we are hesitant to implement it. + sizes other than 8x8. Providing support for this new format would be + feasible (particularly without full acceleration.) However, until/unless + the format becomes either an official industry standard or, at minimum, an + accepted solution in the community, we are hesitant to implement it, as + there is no sense of whether or how it might change in the future. It is + our belief that SmartScale has not demonstrated sufficient usefulness as a + lossless format nor as a means of quality enhancement, and thus, our primary + interest in providing this feature would be as a means of supporting + additional DCT scaling factors. -- libjpeg: Fancy downsampling in compressor cinfo.do_fancy_downsampling is silently ignored. @@ -339,6 +351,24 @@ Not supported: -- Lossless RGB JPEG files This requires the SmartScale feature, which is not supported. +What About libjpeg v9? +---------------------- + +libjpeg v9 introduced yet another field to the JPEG compression structure +(color_transform), thus making the ABI backward incompatible with that of +libjpeg v8. This new field was introduced solely for the purpose of supporting +lossless SmartScale encoding. Further, there was actually no reason to extend +the API in this manner, as the color transform could have just as easily been +activated by way of a new JPEG colorspace constant, thus preserving backward +ABI compatibility. + +Our research (see link above) has shown that lossless SmartScale does not +generally accomplish anything that can't already be accomplished better with +existing, standard lossless formats. Thus, at this time, it is our belief that +there is not sufficient technical justification for software to upgrade from +libjpeg v8 to libjpeg v9, and therefore, not sufficient technical justification +for us to emulate the libjpeg v9 ABI. + ******************************************************************************* ** Mathematical Compatibility -- 2.40.0