Kompressor.app is an application to create highly compressed bitmap images using my Wavelet Image Compression Library. These images have the extension .wko and can be progressively transmitted or even truncated at any point while still providing the best possible quality in some sense.
Essentially, you open an existing image and then modify the settings until you're satisfied with the end result. At that point, you can then save the image with the current settings.
When opening existing images, you have the choice of a color-space into which the image should be converted. This selection only applies when opening non-".wko" images that have at least 3 channels. The RGB color-space leaves the source as it is, while both variants of the YCoCg color-space perform a conversion. For natural images (and most others, too) the YCoCg color-spaces result in (sometimes much) smaller files. The YCoCg color-space incurs a mean-square error (MSE) of about 0.25 compared to the original image, which in nearly all cases is perfectly fine. If you still need bit-perfect reconstruction, you can use the reversible variant YCoCg-R.
You can add more channels (i.e. images) to the current document provided that they have identical dimensions. This can either be done with the Add File... option in the Edit menu, or via the clipboard.
There are two ways of influencing the quality of the resulting image. One is with the File Size Slider on the side of the drawer, where the top position selects lossless compression and positions near the bottom result in smaller (but non-identical or "lossy") files.
The other option for modifying the outcome of the compression algorithm is the Quality Slider for each individual channel. If we are in lossless mode (i.e. the File Size Slider is at the very top) then the Quality slider prescribes the absolute quality required for each channel. On the other hand, if we are in lossy mode, then the Quality Slider assigns an importance to each individual channel; the higher the importance of a channel, the more bits are spent while compressing it — and thus representing it more accurately than channels with a lower importance.
The image view displays both the original image as well as its compressed kin at the same time. They are separated by a thin gray line. You can move this separator by dragging it across the image. As soon as you drag the divider line close to the center of an edge of the view, it will switch orientation as appropriate.
By default, the channel selection is not reflected in the image view as that proves rather distracting when changing quality settings for individual channels. As only up to three channels (from the same color-space) can be displayed at the same time, you can examine individual channels — as dictated by the selection — by enabling Display Honors Selection in the View menu.
Sometimes it is easier to spot compression artifacts (or determining acceptable quality) by flipping between the original and the compressed image. The Swap Original & Compressed option in the View menu allows you to do exactly that, by swapping on which side of the divider line original and compressed image are displayed.
Although the format and the library itself is very flexible — many settings can be changed at compile time, for example support for deeper pixel formats (up to 61 bits per channel) — this version is currently compiled for
Worker threads are used when loading channels (as the initial error estimation can take some time) to distribute the work-load between available processing cores.
Each channel is compressed individually and losslessly as soon as it is loaded. When we change any file size or quality settings, we ask the library how many bits would have been allocated to each channel without actually doing any compression. A correction to this bit-budget is applied (because the individually compressed channels do not need to store a channel index as there is only one) and only that many bits are decompressed from each channel. This allows us to parallelize the decompression / display loop as well.
When loading ".wko"-files, the original scheduling information is available — but not the error estimates used to create it. So we create a new schedule with proper error estimates but possibly sub-optimal scheduling information (e.g. it might include blocks and bit-planes which had been discarded in the original file) and then manually combine the two to form a near-optimal schedule.