the two are mainly to provide a well-known reference, and to demonstrate that
more specific tools than usually be made faster than generic tools.
-qscale is not novel in any way, nor is it perfect (far from it; it's more of a
-proof of concept than anything else) -- it is mainly a piece of engineering.
+qscale is not novel in any way, nor is it perfect (far from it; it's more like
+a proof of concept) -- it is mainly a piece of engineering.
However, the following techniques deserve some kind of mention:
- qscale recognizes that JPEGs are usually stored in the YCbCr colorspace and
- qscale can utilize the SSE instruction set found in almost all modern
x86-compatible processors to do more work in the same amount of instructions
(It can also use the SSE3 instruction set, although the extra boost on top
- of SSE is smaller. In time, it will utilize the SSE extensions known as
- SSE4.1, which can help even more.) It takes care to align the image data and
- memory accesses on the right boundaries wherever it makes sense.
+ of SSE is smaller.) It takes care to align the image data and memory
+ accesses on the right boundaries wherever it makes sense.
- qscale recognizes (like almost any decent scaling program) that most
practical filter kernels are separable, so scaling can be done in two
sequential simpler passes (horizontal and vertical) instead of one. The
filter kernel is large (ie. large amounts of scaling).
- qscale does not use multiple processors or cores (although different cores
can of course work on different images at the same time).
- - qscale does not make very good use of the extra eight SSE registers found
- on 64-bit x86-compatible (usually called amd64 or x86-64) machines. In
- fact, out of the box it might not even compile on such machines.
+
+Finally, a word of advice: Even the fastest scaler can never be as fast as not
+scaling. If you can do less work, or move it to a time where it is less user
+visible, do that no matter how you scale your pictures. In particular, cache
+your downscaled pictures if you can, preferrably ahead of time. If you cannot
+predict in advance exactly what size (or sizes) you'll need, consider making
+mipmaps (ie. one image of half the resolution each way, another one of a quarter
+the resolution each way etc., down to a reasonable size) and scaling from them
+instead. It will be much faster (primarily due to less loading time) and the
+difference in quality is nearly impossible to detect, at least in my tests.
qscale is Copyright 2008 Steinar H. Gunderson <sgunderson@bigfoot.com>, and
licensed under the GNU General Public License, version 2. The full text of
projects / qscale / blobdiff