[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: Lossless image compression
From: Dmitry Kazakov <dimula73 () gmail ! com>
Date: 2012-02-07 14:43:19
Message-ID: CAEkBSfUz2xPDtAM=MDLf1XwBpV7mDG-traE8Shh1-XMBNPO1Gg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tue, Feb 7, 2012 at 5:01 PM, Boudewijn Rempt <boud@valdyas.org> wrote:
> On Tue, 7 Feb 2012, Dmitry Kazakov wrote:
>
> Compression
>> For the actual compression of the tile data we use LZF algorithm. I did
>> some research on the compression times of LZO and LZF [0], [1]. It
>> turned out that LZF has better times. It takes twice faster to compress
>> the image with LZF while keeping almost the same compression rate.
>> One more thing I found then is that it is faster to "linearize" colors
>> before compression and then compress the image than compress the
>> image directly (RGBARGBA -> RRGGBBAA). It boosts both the speed and the
>> compression rate. The time of the "linearization" itself is
>> negligible in comparison with the boost it give, so now we do it this way.
>>
>>
> Well, actually when Sven wanted to know why loading and saving files is so
> slow, it turns out that the linearization is the biggest bottleneck we
> currently have! But that might depend a lot on cache sizes and so on. In
> general, we want to avoid missing the cache when compressing a tile.
>
Probably, I'm a bit outdated.
I've just run the test on my new machine.
The results are the following:
Compression LZF w/o linearization: 247 memcpy's. Ratio: 0.938
Compression LZF with linearization: 213 memcpy's. Ratio: 0.769
Decompression LZF w/o linearization: 78 memcpy's.
Decompression LZF with linearization: 112 memcpy's.
It means that for compression the linearization still makes it faster, but
for decompression it makes the things worse on newer cpu. Here are the
callgrind graphs for compression and decompression: [0], [1]
[0] - http://dimula73.narod.ru/callgrind.out.9540_compression_two_pass
[1] - http://dimula73.narod.ru/callgrind.out.9513_decompression_two_pass
--
Dmitry Kazakov
[Attachment #5 (text/html)]
<br><br><div class="gmail_quote">On Tue, Feb 7, 2012 at 5:01 PM, Boudewijn Rempt \
<span dir="ltr"><<a href="mailto:boud@valdyas.org">boud@valdyas.org</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"> <div class="im">On Tue, 7 Feb 2012, Dmitry Kazakov \
wrote:<br> <br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> Compression<br>
For the actual compression of the tile data we use LZF algorithm. I did some research \
on the compression times of LZO and LZF [0], [1]. It<br> turned out that LZF has \
better times. It takes twice faster to compress the image with LZF while keeping \
almost the same compression rate.<br> One more thing I found then is that it is \
faster to "linearize" colors before compression and then compress the image \
than compress the<br> image directly (RGBARGBA -> RRGGBBAA). It boosts both the \
speed and the compression rate. The time of the "linearization" itself \
is<br> negligible in comparison with the boost it give, so now we do it this way.<br>
<br>
</blockquote>
<br></div>
Well, actually when Sven wanted to know why loading and saving files is so slow, it \
turns out that the linearization is the biggest bottleneck we currently have! But \
that might depend a lot on cache sizes and so on. In<br>
general, we want to avoid missing the cache when compressing a tile.<span \
class="HOEnZb"><font \
color="#888888"><br></font></span></blockquote><div><br>Probably, I'm a bit \
outdated.<br><br>I've just run the test on my new machine.<br> The results are \
the following:<br><br><span style="font-family:courier new,monospace">Compression LZF \
w/o linearization: 247 memcpy's. Ratio: 0.938</span><br \
style="font-family:courier new,monospace"><span style="font-family:courier \
new,monospace">Compression LZF with linearization: 213 memcpy's. Ratio: \
0.769</span><br style="font-family:courier new,monospace"> <br></div></div><span \
style="font-family:courier new,monospace">Decompression LZF w/o linearization: 78 \
memcpy's.</span><br style="font-family:courier new,monospace"> <span \
style="font-family:courier new,monospace">Decompression LZF with linearization: 112 \
memcpy's.</span><br style="font-family:courier new,monospace"> <br>It means that \
for compression the linearization still makes it faster, but for decompression it \
makes the things worse on newer cpu. Here are the callgrind graphs for compression \
and decompression: [0], [1]<br><br>[0] - <a \
href="http://dimula73.narod.ru/callgrind.out.9540_compression_two_pass">http://dimula73.narod.ru/callgrind.out.9540_compression_two_pass</a><br>
[1] - <a href="http://dimula73.narod.ru/callgrind.out.9513_decompression_two_pass">http://dimula73.narod.ru/callgrind.out.9513_decompression_two_pass</a><br><br><br \
clear="all"><br>-- <br>Dmitry Kazakov<br>
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic