Comments on: IJG swings again, and misses http://hardwarebug.org/2010/02/01/ijg-swings-again-and-misses/ Everything is broken Mon, 30 Aug 2010 09:33:38 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Mans http://hardwarebug.org/2010/02/01/ijg-swings-again-and-misses/comment-page-1/#comment-1229 Mans Thu, 26 Aug 2010 12:20:14 +0000 http://hardwarebug.org/?p=234#comment-1229 The tests I performed used the settings suggested in the manual, downscaling on encode and upscaling on decode. The tests I performed used the settings suggested in the manual, downscaling on encode and upscaling on decode.

]]> By: Ben R-G http://hardwarebug.org/2010/02/01/ijg-swings-again-and-misses/comment-page-1/#comment-1227 Ben R-G Wed, 25 Aug 2010 20:36:48 +0000 http://hardwarebug.org/?p=234#comment-1227 I don't think this IJG has much to do with the IJG of the 1990s. Tom Lane (the former organizer of the IJG) was not involved in v7 and later releases as far as I know. I think they're almost solely the work of Guido Vollbeding, who does seem to be a bit kooky. I think you've missed the point of "SmartScale". As far as I can tell, the idea is to use smaller block sizes than 8x8. You can simulate this in the v7 library by scaling by 8/n on encode, with n less than 8, then scaling by n/8 on decode (you can even simulate it in version 6b with n=1,2,4). "SmartScale" stores the n/8 factor in the file so it can be automatically applied when decoding, kind of like EXIF rotation, and also suppresses the AC coefficients that are always zero. It doesn't add support for larger DCTs with more than 64 outputs; when you scaled by 8/n with n greater than 8 you simply lost the high-frequency components with predictable results. There is an ITU-T recommendation, T.851, which adds 16-bit samples and a new arithmetic coding mode to T.81. I had assumed that the promised improvements in v8 would be an implementation of that standard, but apparently not. I don’t think this IJG has much to do with the IJG of the 1990s. Tom Lane (the former organizer of the IJG) was not involved in v7 and later releases as far as I know. I think they’re almost solely the work of Guido Vollbeding, who does seem to be a bit kooky.

I think you’ve missed the point of “SmartScale”. As far as I can tell, the idea is to use smaller block sizes than 8×8. You can simulate this in the v7 library by scaling by 8/n on encode, with n less than 8, then scaling by n/8 on decode (you can even simulate it in version 6b with n=1,2,4). “SmartScale” stores the n/8 factor in the file so it can be automatically applied when decoding, kind of like EXIF rotation, and also suppresses the AC coefficients that are always zero. It doesn’t add support for larger DCTs with more than 64 outputs; when you scaled by 8/n with n greater than 8 you simply lost the high-frequency components with predictable results.

There is an ITU-T recommendation, T.851, which adds 16-bit samples and a new arithmetic coding mode to T.81. I had assumed that the promised improvements in v8 would be an implementation of that standard, but apparently not.

]]>