[Kde-imaging] Lossless image compression

[Dmitry Kazakov]

> > tile and the size of a pixel. The algorithm is split into two
> > classes:  KisTileCompressor2 [2] and KisLzfCompression [3]. The
> > benchmarks are placed in [4].
>
> Link [3] and [4] are identical.
>

Sorry, new ones:

KisLzfCompression:
http://quickgit.kde.org/index.php?p=calligra.git&a=blob&h=13910830b29418a81407078619a0c47e8d794d63&hb=194ee7c39975e0be1ce37bb9394456290b326019&f=krita%2Fimage%2Ftiles3%2Fswap%2Fkis_lzf_compression.cpp

KisTileCompressor2:
http://quickgit.kde.org/index.php?p=calligra.git&a=blob&h=c46843999c159f88553e1846e7d4681e375a7e3c&hb=194ee7c39975e0be1ce37bb9394456290b326019&f=krita%2Fimage%2Ftiles3%2Fswap%2Fkis_tile_compressor_2.cpp


Do you still have that 640x441 RGBA image? Which memcpy
> implementation? Also, why is memcpy of a single tile three times as
> fast as memcpy of the complete image? Did you iterate multiple times
> and measure cache performance? :)
>

I measured memcpy of the whole operation. So the less the image the less
the time. I didn't normalized that on the amount of data. And I used
QBENCHMARK which performes many cycles, but it doesn't flush the cache on
every cycle (I guess).

I've just prepared a standalone version of the test:
http://dimula73.narod.ru/compression_lzf_test.tar.gz

You can switch between two source files by changing TEST_FILE definition at
the top of kis_compression_tests.cpp

Probably, there are some flaws in the methodology of testing, if you find
one don't hesitate to point it up ;)


>From the compression rate, it looks like the compression is actually
> only done for the alpha channel, whereas the RGB data is nearly
> uncompressed.


Hm... I'm afraid you are right =( I never thought why it was 75% only.



> I am not sure how often the data actually gets written
> to disk.
> If it gets written to the disk, having a better compression rate will
> result in the speedup, not a faster compression method.


I cannot get the exact timings, because actual swapping is done by the OS.
I can either measure how often the data is written/read to/from
memory-mapped file (this is a kind of "virtual" swapping) or measure how
often 16MiB memory window moves (which flushes the file). But the latter
parameter is quite fuzzy.



> If you are
> mostly doing in-memory operations, having the fastest method available
> will be beneficial, but with the marginal improvement you get, I would
> not bother compressing the RGB data at all, only the alpha.
>

Well, yes. Though in this case we won't be able to compress the tiles which
are fully filled with one color.


> IZ compression is symmetrical, i.e. needs the same time for
> compression and decompression. From looking at your numbers,
> compression speed for IZ should be similar to LZF, but decompression
> will be much slower. I can try to extract the LZF code and make a
> comparison on my machine, if you have representative test data (Krita
> isn't really for photos, which I used for all my benchmarks).
>

I've written the link to a standalone test above. You need to inherit your
algorithm from KisAbstractCompression and add it to KisCompressionTests.
You can check it with both source images.

-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20120209/fe7e17dc/attachment.html>