FLIC - a new fast lossless image compressor

[Alexander Ratushnyak]

Demo version is here:
http://www.imagecompression.info/gralic/flic1d.zip - command-line executable for 32-bit Windows. It can handle only 24-bit color images in PPM format, with both width and height less than 8160. It always applies the algorithm designed for photographic images.

Here's some comparison with JPEG2000 (Kakadu), BMF2 and BCIF.

Compressed sizes:
FLIC: 100.0% - 358268079 bytes
BMF2: 106.9% - 383042492
BCIF: 110.2% - 394725429
Jpg2K: 116.0% - 415503871
Uncompressed: 265.17% - 950008194 bytes

Compression time:
FLIC: 100 seconds
BMF2: 114
BCIF: 229
Jpg2K: 107

Decompression time:
FLIC: 102 seconds
BMF2: 80
BCIF: 44
Jpg2K: 90

Tests were run on an Intel Core i7 CPU 930 (2.8 GHz) with 3 GB RAM running Windows XP.
Data used:
all 14 images from http://www.imagecompression.info/tes...es/rgb8bit.zip ,
plus all 11 images from http://cdb.paradice-insight.us/corpo...verse/?C=S;O=D ,
plus all 7 images from http://cdb.paradice-insight.us/corpo...08bit/?C=S;O=D .


MORE UPDATES AND DISCUSSION:
http://www.linkedin.com/groups/Image...ession-3363256

[thometal]

Flic sound like Flac do you have the same intention, but for Images?
A PNG comparision would maybe usefull too.

But anyway the results look impressive.

[Alexander Ratushnyak]

No such intention yet.
Some comparison with PNG and JPEG-LS is here:
http://www.researchandtechnology.net...benchmarks.php -> Imagecompression.info image set.
PNG is almost 25% worse than BCIF.
14 of 32 images used in FLIC comparison are from www.imagecompression.info, and that's 470.6 of 950 Mb.
PNG is good for artificial images but not for big photographic images.

[jethro]

I like GRALIC compression balance more because as I see it for not-widespread compressors the main benefit is the compressed size not speed. In my small test set FLIC lost to BCIF (9.43MB to 9.12MB), being slightly smaller on photographic images and much worse (precentage-wise) on artificial images and screenshots. To make matters worse BMF2 comes at 8,64MB while being really quick. I guess the caveat would be to use FLIC only on natural photographs but that means it cannot be used universally to bmp-like images.
On topic of lossless image compression have you considered digital RAW format(s) re-compression?

[Alexander Ratushnyak]

An improved version is here:
http://www.imagecompression.info/gralic/flic1d.zip
Speed is higher, compression quality is slightly better on average.

Compression time:
FLIC: 93 seconds
BMF2: 114
BCIF: 229
Jpg2K: 107

Decompression time:
FLIC: 96 seconds
BMF2: 80
BCIF: 44
Jpg2K: 90

Compressed sizes:
FLIC: 100.0% - 357749193 bytes
BMF2: 107.1% - 383042492
BCIF: 110.3% - 394725429
Jpg2K: 116.1% - 415503871
Uncompressed: 265.55% - 950008194 bytes

Obsolete package: http://www.imagecompression.info/gralic/flic11d.zip

[Piotr Tarsa]

Still BCIF wins by far when it comes to decompression speed

[Alexander Ratushnyak]

Still BCIF wins by far when it comes to decompression speed

No, COPY wins if speed is so important. Also, RAR has better decompression speed, but it stops compressing at 133.1% (476213620 bytes). PNG is pretty similar, I guess.

A PNG comparision would maybe usefull too.

Which PNG implementation would you recommend? Preferably command-line, and accepting PPM as input.

On topic of lossless image compression have you considered digital RAW format(s) re-compression?

Not now, maybe later




MORE UPDATES AND DISCUSSION:
http://www.linkedin.com/groups/Image...ession-3363256

[Alexander Ratushnyak]

No, COPY wins if speed is so important.

Actually, CharLS wins, if you care not only about speed. See http://www.imagecompression.info/gralic/LPCB.html

[m^2]

Alex, could you try the following:

FreeArc -mmm:3*8+grzip:m4:l
FreeArc -mmm:3*8+1xb

[Alexander Ratushnyak]

Yes and yes. Decompressed files were bit-exact, speed will be tested later.

[m^2]

Thanks.

[thometal]

could you also test packpnm and webp ?

[Alexander Ratushnyak]

PackPNM 1.0e is on the to-do list,
WebP-lossless: compression is very slow even with "-c 0", and it crashes when there's not enough memory (i.e. on 100+ Mb files with -c 0, on 30+ Mb files with -c 10), at least the 32-bit Windows executable.

[Alexander Ratushnyak]

PackPNM 1.0e was added today,
WebP-lossless -c 0 on 103 LPCB images, i.e. all but the four that are bigger than 100 Mb:

1'220'278'081 bytes in PNG format => 1'100'509'276 in Webpll format, that's 90.18%
Compression time: 17561 seconds (almost 5 hours)
Decompression time: 1286 seconds (21.5 minutes)

[m^2]

Thanks for testing. Could you clarify how did you measure decompression time?
I mean, did you use the switch that allows to increase number of iterations or was it just 1 iteration?

ADDED: Do you intend to test it in stronger modes?
ADDED: Also, what is PNG size? Is it the best out of the box implementation or something heavily optimized?

[Alexander Ratushnyak]

Thanks for testing. Could you clarify how did you measure decompression time?
I mean, did you use the switch that allows to increase number of iterations or was it just 1 iteration?

Normally it's three iterations for the complete set, and then I pick the smallest of three numbers, but for webp-lossless, because it's experimental and very slow, only two iterations.

Do you intend to test it in stronger modes?

Thirty LPCB files on which webp-lossless with -c 30 does not crash:
38,357,519 bytes - GraLIC 1.11.demo
38,957,996 - BMF -s -q9
51,763,457 - webp -c 30
51,859,030 - webp -c 10
53,720,988 - webp -c 0
64,611,485 - PNG
More details here: http://www.imagecompression.info/gralic/lpcb30.rar

ADDED: Also, what is PNG size? Is it the best out of the box implementation or something heavily optimized?

PNG files were created with NConvert -out png *.ppm

[m^2]

Thanks for the answers.