- From: Frédéric Kayser <f.kayser@free.fr>
- Date: Mon, 16 Sep 2013 14:53:09 +0200
- To: public-respimg@w3.org
- Cc: Marcos Caceres <w3c@marcosc.com>
- Message-Id: <1BBA8609-4BF3-4527-8E18-A8E64414C7CE@free.fr>
Hello, in an extremely simplified manner it says that some JPEG image dimensions are "better" (you can pack more pixels at practically the same file weight) than others (the file size jumps by about 4% for only a couple of added columns or rows). This is due to the fact that internally JPEG does not work on individual pixels but on small chunks of 8 by 8 called data units (or DCT matrices). For instance if you have a few thousand pictures (3:2 ratio) and want to produce a thumbnail or a low definition version of them, you could choose between these four image sizes: - 282 x 188 - 285 x 190 - 288 x 192 - 291 x 194 Which thumbnail dimension would get you more bang for the buck? 282 = 35x8 + 2 -> JPEG will add some padding data and treat it as a 288 (36x8) by 188 = 23x8 + 4 -> 192 (24x8) picture and crop it to 282 x 188 at render time. 285 = 35x8 + 5 -> JPEG will add some padding data and treat it as a 288 (36x8) by 190 = 23x8 + 6 -> 192 (24x8) picture and crop it to 285 x 190 at render time. 288 = 36x8 -> Perfect dimensions, nothing to add, 192 = 24x8 -> nothing to crop afterwards. 291 = 36x8 + 3 -> JPEG will add some padding data and treat it at least as a 296 (37x8) by 194 = 24x8 + 2 -> 200 (25x8) picture and crop it to 291 x 194 at render time. The first 3 dimensions will be treated has if it had been 288 x 192 their file size will probably be in the same ballpark (usually the image size / file size order is kept), the last one will necessarily pack more data and result in sensibly bigger files. Now if you want to perform a test you can try to resize different pictures at the dimensions mentioned (quality settings, blur/sharpening, resize methods should not interfere a lot as long the same settings are kept). Chroma subsampling will shift inflections points around dimensions that are multiples of 16 and not 8, if you don't know what chroma subsampling is you can try to read this: http://frdx.free.fr/JPEG_for_the_horseshoe_crabs.pdf (not really ready for prime time but the chroma subsampling part is not too bad). If you're comfortable with fast paced French you may enjoy watching this presentation: http://www.youtube.com/watch?v=V7LvgXqsh60 (again it's a work on progress) Regards -- Frédéric Kayser Marcos Caceres wrote: > 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 12:53:39 UTC