- From: Marcos Caceres <w3c@marcosc.com>
- Date: Mon, 16 Sep 2013 12:04:00 +0100
- To: Frédéric Kayser <f.kayser@free.fr>
- Cc: public-respimg@w3.org, Jason Grigsby <jason@cloudfour.com>
Hi Frédéric, On Friday, September 13, 2013 at 7:34 PM, Frédéric Kayser wrote: > Pardon by French, but apparently these people don't even have a clue of how JPEG compression internally works: no word about chroma subsampling effects and use of a 300x200 pixels image sample that doesn't fit nicely into MCUs. > Here are a few explanations about it: > - the file size of about 20 images at different sizes ranging from 240x160 to 300x200 pixels (resized using ImageMagick convert -resize XxY\! -quality 76% -sampling-factor 2x2 -unsharp 1.5x1+0.7+0.02 —a rough equivalent to Photoshop Save For Web quality 50—), notice the inflections point around 240x160, 264x176 and 288x192, some images at 288x192 or 264x176 weight even less than their 255x190 and 261x174 counterpart! > - a sample 288x192 image with its DCT matrices count > - the same at 291x194 where new DCT matrices have been added into the JPEG file to hold the 3 extra columns and the 2 extra rows (now guess why the file size made such a jump between 288x192 and 291x194) > - finally all the pixels the file holds in the outer matrices even those out of the visible frame (JPEGsnoop (http://www.impulseadventure.com/photo/jpeg-snoop.html) can display those but sadly only for sequential JPEGs). I've be surprised if anyone in this list has a clue about the above. It all sounds very interesting (though a bit like rocket surgery), but it will be hard for us to apply the information above in a useful way. If you can articulate the above as tests or in a manner digestible to the CG, that would be helpful. Kind regards, Marcos
Received on Monday, 16 September 2013 11:04:31 UTC