[Kde-imaging] Lossless image compression
dimula73 at gmail.com
Thu Feb 9 19:50:11 UTC 2012
> > tile and the size of a pixel. The algorithm is split into two
> > classes: KisTileCompressor2  and KisLzfCompression . The
> > benchmarks are placed in .
> Link  and  are identical.
Sorry, new ones:
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:
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the kimageshop