1 Short README, perhaps not too useful.
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
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.
21 qscale is not novel in any way, nor is it perfect (far from it; it's more like
22 a proof of concept) -- it is mainly a piece of engineering.
23 However, the following techniques deserve some kind of mention:
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
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,
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.) It takes care to align the image data and memory
41 accesses on the right boundaries wherever it makes sense.
42 - qscale recognizes (like almost any decent scaling program) that most
43 practical filter kernels are separable, so scaling can be done in two
44 sequential simpler passes (horizontal and vertical) instead of one. The
45 order does matter, though -- I've found doing the vertical pass (in
46 cache-friendly order, doing multiple neighboring pixels at a time to
47 exploit that the processor reads in entire cache lines and not individual
48 bytes at a time) before the horizontal to be superior, in particular
49 because this case is easier to SIMD-wise.
50 - qscale understands that JPEGs are typically subsampled; ie., that the
51 different color components are not stored at the same resolution. On
52 the web, this is typically because the eye is less sensitive to color
53 (chroma) information and as such much of it can safely be stored in
54 a lower resolution to reduce file size without much visible quality
55 degradation; in the JPEGs stored by a digital camera, it is simply
56 because much of the color information is interpolated anyway (since
57 the individual CCD dots are sensitive to either red, green or blue,
58 not all at the same time), so it would not make much sense to pretend
59 there is full color information. qscale does not ask libjpeg to
60 interpolate the "missing" color information nor to downscale the
61 already-downscaled color channels as ImageMagick does, but instead
62 does a single scaling pass from the original resolution to the final
63 subsampled resolution. (This is impossible for any program working
64 in RGB mode, or chunked YCbCr.) This increases both speed and quality,
65 although the effect on the latter is not particularly large.
67 The following optimizations are possible but not done (yet?):
69 - qscale does not do the IDCT itself, even though there is improvement
70 potential over libjpeg's IDCT. (There is an unmaintained and little-used fork
71 of libjpeg called libjpeg-mmx that demonstrates this quite well.) In fact,
72 since the DCT can be viewed as just another (separable, but not
73 time-invariant) FIR filter, the quantization scaling and IDCT could probably
74 be folded into the scaling in many cases, in particular those where the
75 filter kernel is large (ie. large amounts of scaling).
76 - qscale does not use multiple processors or cores (although different cores
77 can of course work on different images at the same time).
79 Finally, a word of advice: Even the fastest scaler can never be as fast as not
80 scaling. If you can do less work, or move it to a time where it is less user
81 visible, do that no matter how you scale your pictures. In particular, cache
82 your downscaled pictures if you can, preferrably ahead of time. If you cannot
83 predict in advance exactly what size (or sizes) you'll need, consider making
84 mipmaps (ie. one image of half the resolution each way, another one of a quarter
85 the resolution each way etc., down to a reasonable size) and scaling from them
86 instead. It will be much faster (primarily due to less loading time) and the
87 difference in quality is nearly impossible to detect, at least in my tests.
89 qscale is Copyright 2008 Steinar H. Gunderson <sgunderson@bigfoot.com>, and
90 licensed under the GNU General Public License, version 2. The full text of
91 the GPLv2 can be found in the included COPYING file.
projects / qscale / blob