JPEG quality estimation

cédric (dev) said on 09/03/2018

pingo 0.98.7 is now able to estimate the input quality of a JPEG, which could let the tool to be much faster while processing files — and to avoid multiple pass with the same settings. if the input quality is lower than what the user requested (or the default), pingo will not try to transform the image data. few points:

  • if the estimation failed, file will be processed anyway
  • all non-critical data, like comments, GPS position, etc. could be still removed even if quality is lower
  • if you use -nojpgcheck, the file should be always processed — there will be no estimation
  • this is automatically disabled if you ask the conversion to grayscale or the JPG scaling

if original has lower quality

on this specific sample, the evaluation of the quality from the input file is ≈ 82. since it is lower than pingo's default, it will not try to transform the image data. 0.98.7 is 10 times faster than 0.98.6 while processing this specific file

pingo 0.98.7 vs 0.98.6
original (quality factor, app: 82) optimized
290,04 KB 273,85 KB

on this specific file:

0.98.6 output — pingo try the transformation, but failed
pingo - (0.40s):
-----------------------------------------------------------------
1 file => 16.18 KB - (5.58%) saved
-----------------------------------------------------------------
0.98.7 output — pingo *do not* try to transform
pingo - (0.04s):
-----------------------------------------------------------------
1 file => 16.20 KB - (5.58%) saved
-----------------------------------------------------------------

test on 1200 JPG files

comparing with older pingo:

0.98.2

0.98.2 output
pingo - (65.49s):
-----------------------------------------------------------------
1200 files => -21.09 KB - (-0.02%) saved
-----------------------------------------------------------------
Kernel Time 3.806s 5%
User Time 122.523s 187%
Process Time 126.329s 192%
Global Time 65.508s 100%
Physical Memory = 37 MB

the result here is really bad: pingo 0.98.2 could create negative results because it always write the JFIF, and took more than 1 minute to process files

0.98.7

0.98.7 output
pingo - (3.67s):
-----------------------------------------------------------------
1200 files => 0 KB - (0.00%) saved
-----------------------------------------------------------------
Kernel Time 1.123s 30%
User Time 5.491s 148%
Process Time 6.614s 179%
Global Time 3.690s 100%
Physical Memory = 4 MB

0.98.7 is much faster, because it does not process the image data, and should not create negative results

comment this