git.sesse.net Git - qscale/blob - README

   1 Short README, perhaps not too useful.
   2
   3 qscale (the "q" is for "quick" -- the confusion with "quantization scale" is
   4 unfortunate, but there are only so many short names in the world) is a fast
   5 JPEG-to-JPEG-only up- and downscaler. On my 1.2GHz Core Duo laptop (using
   6 only one core), qscale is 3-4 times as fast as ImageMagick for downscaling
   7 large JPEGs (~10Mpix from my digital camera) to more moderate-sized JPEGs
   8 for web use etc. (like 640x480) without sacrificing quality. (Benchmarking must
   9 be done with a bit of care, though, in particular due to different subsampling
  10 options possible etc.) Most of the time in qscale's case is used on reading in
  11 the original image using libjpeg, which is shared among the two. However, it
  12 would probably not be realistic to exclude the libjpeg time, as most (although
  13 not all) real-world scaling tasks would indeed need to read and decode the
  14 source JPEG.
  15
  16 Note: This is not to denounce ImageMagick in any way. It is a fine library,
  17 capable of doing much more than qscale can ever hope to do. Comparison between
  18 the two are mainly to provide a well-known reference, and to demonstrate that
  19 more specific tools than usually be made faster than generic tools.
  20
  21 qscale is not novel in any way, nor is it perfect (far from it; it's more of a
  22 proof of concept than anything else) -- it is mainly a piece of engineering.
  23 However, the following techniques deserve some kind of mention:
  24
  25  - qscale recognizes that JPEGs are usually stored in the YCbCr colorspace and
  26    not RGB. (ImageMagick can, too, if you give it the right flags, but not all
  27    its operations are well-defined in YCbCr.) Although conversion between the
  28    two is cheap, it is not free, and it is not needed for scaling. Thus, qscale
  29    does not do it.
  30  - qscale recognizes that JPEGs are stored with the color channels mostly
  31    separate (planar) and not chunked. Scaling does not need to be done on
  32    chunked data -- in fact, mostly, scaling is easier to do on planar data.
  33    Thus, no conversion to chunked before scaling (and no need to convert back
  34    to planar afterwards). (Note: Some SIMD properties might be easier to
  35    exploit on a chunked representation. It's usually not worth it in total,
  36    though.)
  37  - qscale can utilize the SSE instruction set found in almost all modern
  38    x86-compatible processors to do more work in the same amount of instructions
  39    (It can also use the SSE3 instruction set, although the extra boost on top
  40    of SSE is smaller. In time, it will utilize the SSE extensions known as
  41    SSE4.1, which can help even more.) It takes care to align the image data and
  42    memory accesses on the right boundaries wherever it makes sense.
  43  - qscale recognizes (like almost any decent scaling program) that most
  44    practical filter kernels are separable, so scaling can be done in two
  45    sequential simpler passes (horizontal and vertical) instead of one. The
  46    order does matter, though -- I've found doing the vertical pass (in
  47    cache-friendly order, doing multiple neighboring pixels at a time to
  48    exploit that the processor reads in entire cache lines and not individual
  49    bytes at a time) before the horizontal to be superior, in particular
  50    because this case is easier to SIMD-wise.
  51  - qscale understands that JPEGs are typically subsampled; ie., that the
  52    different color components are not stored at the same resolution. On
  53    the web, this is typically because the eye is less sensitive to color
  54    (chroma) information and as such much of it can safely be stored in
  55    a lower resolution to reduce file size without much visible quality
  56    degradation; in the JPEGs stored by a digital camera, it is simply
  57    because much of the color information is interpolated anyway (since
  58    the individual CCD dots are sensitive to either red, green or blue,
  59    not all at the same time), so it would not make much sense to pretend
  60    there is full color information. qscale does not ask libjpeg to
  61    interpolate the "missing" color information nor to downscale the
  62    already-downscaled color channels as ImageMagick does, but instead
  63    does a single scaling pass from the original resolution to the final
  64    subsampled resolution. (This is impossible for any program working
  65    in RGB mode, or chunked YCbCr.) This increases both speed and quality,
  66    although the effect on the latter is not particularly large.
  67
  68 The following optimizations are possible but not done (yet?):
  69
  70  - qscale does not do the IDCT itself, even though there is improvement
  71    potential over libjpeg's IDCT. (There is an unmaintained and little-used fork
  72    of libjpeg called libjpeg-mmx that demonstrates this quite well.) In fact,
  73    since the DCT can be viewed as just another (separable, but not
  74    time-invariant) FIR filter, the quantization scaling and IDCT could probably
  75    be folded into the scaling in many cases, in particular those where the
  76    filter kernel is large (ie. large amounts of scaling).
  77  - qscale does not use multiple processors or cores (although different cores
  78    can of course work on different images at the same time).
  79  - qscale does not make very good use of the extra eight SSE registers found
  80    on 64-bit x86-compatible (usually called amd64 or x86-64) machines. In
  81    fact, out of the box it might not even compile on such machines.
  82
  83 qscale is Copyright 2008 Steinar H. Gunderson <sgunderson@bigfoot.com>, and
  84 licensed under the GNU General Public License, version 2. The full text of
  85 the GPLv2 can be found in the included COPYING file.