Page 1 of 6 123 ... LastLast
Results 1 to 30 of 174

Thread: FLIF - Free Lossless Image Format

  1. #1
    Member
    Join Date
    Feb 2010
    Location
    Nordic
    Posts
    200
    Thanks
    41
    Thanked 36 Times in 12 Posts

    FLIF - Free Lossless Image Format

    FLIF is a novel lossless image format which outperforms PNG, lossless WebP, lossless BPG and lossless JPEG2000 in terms of compression ratio.According to the compression experiments we have performed, FLIF files are, on average:
    • 26% smaller than brute-force crushed PNG files,
    • 35% smaller than typical PNG files,
    • 37% smaller than lossless JPEG 2000 compression,
    • 15% smaller than lossless WebP,
    • 22% smaller than lossless BPG.


    Even if the best image format was picked out of PNG, JPEG 2000, WebP or BPG for a given image, depending on the type of image (photograph, line art, etc),
    then FLIF still beats that by an average of 10% in our comparisons.

    Couldn't find a thread on this so thought it deserved one:

    http://flif.info/

    This is getting some hype in the tech sites:

    https://www.reddit.com/r/programming..._image_format/
    https://news.ycombinator.com/item?id=10317790

  2. The Following 3 Users Say Thank You to willvarfar For This Useful Post:

    Bulat Ziganshin (2nd October 2015),Cyan (3rd October 2015),lorents17 (3rd October 2015)

  3. #2
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,497
    Thanks
    733
    Thanked 659 Times in 354 Posts
    There seems to be some additional technical information here:https://boards.openpandora.org/topic...e-format-flif/

    - for interlacing it uses a generalization of PNG's Adam7; unlike PNG, the geometry of the 2D interlacing
    is exploited heavily to get better pixel estimation, which means the overhead of interlacing is small (vs simple scanline encoding, which has the benefit of locality so usually compresses better)

    - the colorspace is a lossless simplified variant of YIQ, alpha and Y channel are encoded first, chroma channels later

    - the real innovation is in the way the contexts are defined for the arithmetic coding: during encoding, a decision tree is constructed (a description of which is encoded in the compressed stream) which is a way to dynamically adapt the CABAC contexts to the specific encoded image. We have called this method "MANIAC", which is a backronym for "Meta-Adaptive Near-zero Integer Arithmetic Coding".

    Also, comments in that thread on speed [1]:
    In terms of encode/decode speed: both are slow and not very optimized
    at the moment (no assembler code etc, just C++ code). A median file
    took 3 seconds to encode (1 second for a p25 file, 6 seconds for a p75
    file), which is slower than most other algorithms: WebP took slightly
    less than a second for a median file (0.5s for p25, 2s for p75), PNG
    and JPEG2000 took about half a second. It's not that bad though: BPG
    took 9 seconds on a median file (2.5s for p25, 25s for p75), and
    brute-force pngcrushing took something like 15 seconds on a median
    file (6s for p25, over 30s for p75), so at least it's already better
    than that.

    Decode speed to restore the full lossless image and write it as a png
    is not so good: about 0.75s for a median file, 0.25s for a p25 file,
    1.5s for a p75 file. That's roughly 3 to 5 times slower than the other
    algorithms. However, decoding a partial (lossy) file is much faster
    than decoding everything, so in a progressive decoding scenario, the
    difference would not be huge.


  4. #3
    Member
    Join Date
    Sep 2010
    Location
    US
    Posts
    126
    Thanks
    4
    Thanked 69 Times in 29 Posts
    Somebody please do a comparison vs the better lossless image compressors (PAQ,BMF,etc. ?).
    Last edited by cbloom; 3rd August 2016 at 20:32.

  5. #4
    Member
    Join Date
    Jul 2014
    Location
    Mars
    Posts
    164
    Thanks
    115
    Thanked 10 Times in 9 Posts
    any win binaries pls?

  6. #5
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,497
    Thanks
    733
    Thanked 659 Times in 354 Posts
    attached executable + sources to rebuild. GCC 4.9.2, 32-bit. Github repo

    i've succesfully encoded compression-all.png (150KB) into flif (70KB) in 10 seconds and back in 1 second with i7-4770

    ADD: just compiled more up-to-date code, seems that it only added .PAM support: https://github.com/Bulat-Ziganshin/F...tag/2015-10-03
    Attached Files Attached Files
    Last edited by Bulat Ziganshin; 3rd October 2015 at 14:00.

  7. The Following 2 Users Say Thank You to Bulat Ziganshin For This Useful Post:

    lorents17 (3rd October 2015),sathyaalias (15th December 2015)

  8. #6
    Member
    Join Date
    Jun 2009
    Location
    Kraków, Poland
    Posts
    1,471
    Thanks
    26
    Thanked 120 Times in 94 Posts
    How it compares to gralic, flic and qlic? http://imagecompression.info/gralic/
    Those codecs are for photograps generally, but nonetheless it would be interesting to compare on different types of images.

  9. #7
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,497
    Thanks
    733
    Thanked 659 Times in 354 Posts
    alternative Windows build: https://github.com/r-lyeh/FLIF , including flif.exe
    Last edited by Bulat Ziganshin; 3rd October 2015 at 21:33.

  10. #8
    Member Skymmer's Avatar
    Join Date
    Mar 2009
    Location
    Russia
    Posts
    681
    Thanks
    37
    Thanked 168 Times in 84 Posts
    Quick and dirty observation using hdr.ppm from http://imagecompression.info/test_images/rgb8bit.zip
    Code:
    hdr.ppm, 3072x2048x24bit, 18 874 385 bytes
    
                     enc.time          enc.mem           dec.time          dec.mem            enc.size
    -i -b (default)   52.175s           79628K             6.275s           75396K            5 611 705
    -i -a             79.087s           85484K            11.376s           83372K            5 633 918
    -n -b             49.370s           86380K             5.622s           84412K            5 562 291
    -n -a             77.605s           90624K            10.840s           86956K            5 580 336
    
    webp 0.4.3 -lossless -q 100 -m 6                                                          5 858 356
    gralic 1.11d                                                                              4 978 747
    Well, not so bad compression at the first glance, but noticeable option-dependant-symmetric behaviour is unpleasant.
    By default FLIF uses 3 itterations so I tried to raise it to 1000 which is the maximum value. Unfortunately the memory overflow happened after 1977.018s of processing:
    Code:
    Loading input file: hdr.ppm
    Input: 3072x2048, channels: 3, depth: 8 bit
    Learning a MANIAC tree. Iterating 1000 times.
    110% done [2/3] ENC[3072x2048]    terminate called after throwing an instance of 'std::bad_alloc'
      what():  std::bad_alloc
    
    This application has requested the Runtime to terminate it in an unusual way.
    Please contact the application's support team for more information.
    With -r 100, overflow happened again but interesting thing - output file has been created this time.
    Its appeared to be broken but surprisingly FLIF made a trick:
    Code:
      _____  __  (__) _____
     (___  ||  | |  ||  ___)   FLIF 0.1 [30 September 2015]
      (__  ||  |_|__||  __)    Free Lossless Image Format
        (__||______) |__)      (c) 2010-2015 J.Sneyers & P.Wuille, GNU GPL v3+
    
    Decoding 3072x2048 image, channels: 3, depth: 8 bit
    Transforms: YIQ, BND
    Decoded header + rough data. Decoding MANIAC tree.
    Decoding data (scanlines)
    0% done [1/3] DEC[3072x2048]
    33% done [2/3] DEC[3072x2048]
    66% done [3/3] DEC[3072x2048]
    Decoding done, 5379332 bytes for 3072x2048 pixels (0.8550bpp)
    
    CORRUPTION DETECTED! (partial file?)
    
    Saving output file: out.pnm
    Yep, thats right, FLIF is able to decode throught errors. In such case you'll see visual corruption like this:

    Click image for larger version. 

Name:	flif_decode_through_error.png 
Views:	850 
Size:	692.2 KB 
ID:	3862

    And here is an additional test on 4bpp and 8 bpp files. Simple linear table this time.

    Code:
    4bpp_1.png                 148 274
    4bpp_1.png.webp            156 922
    4bpp_1.png.flif.na         91 578
    4bpp_1.png.flif.nb         91 578
    4bpp_1.pnm.gr              118 062
    
    4bpp_2.png                 550 113
    4bpp_2.png.webp            381 650
    4bpp_2.png.flif.na         302 965
    4bpp_2.png.flif.nb         302 965
    4bpp_2.pnm.gr              (refused)
    
    8bpp_1.png                 197 807
    8bpp_1.png.webp            141 536
    8bpp_1.png.flif.na         133 132
    8bpp_1.png.flif.nb         133 132
    8bpp_1.pnm.gr              338 147
    
    8bpp_2.png                 2 571 542
    8bpp_2.png.webp            1 990 120
    8bpp_2.png.flif.na         1 016 141
    8bpp_2.png.flif.nb         1 016 141
    8bpp_2.pnm.gr              1 665 311

  11. #9
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,497
    Thanks
    733
    Thanked 659 Times in 354 Posts
    FLIF just released the first official Windows executable: https://github.com/jonsneyers/FLIF/releases

    ADD: Skymmer, FLIF can decode any incomplete flif file, so it dups as lossy compressor (probably not the best though)

    Piotr: https://github.com/jonsneyers/FLIF/issues/28
    Last edited by Bulat Ziganshin; 3rd October 2015 at 22:18.

  12. The Following User Says Thank You to Bulat Ziganshin For This Useful Post:

    Stephan Busch (5th October 2015)

  13. #10
    Member
    Join Date
    Oct 2015
    Location
    Belgium
    Posts
    29
    Thanks
    9
    Thanked 10 Times in 8 Posts
    Quote Originally Posted by Skymmer View Post
    By default FLIF uses 3 itterations so I tried to raise it to 1000 which is the maximum value. Unfortunately the memory overflow happened after 1977.018s of processing
    Oh, 1000 iterations, that does not make sense. Try -r4 first. If 4 is better than 3 you can try 5 or 6. Usually more than that will only result in worse compression. The default of 3 is usually more or less OK.

  14. #11
    Member
    Join Date
    Sep 2010
    Location
    US
    Posts
    126
    Thanks
    4
    Thanked 69 Times in 29 Posts
    My initial testing shows FLIF is beaten pretty badly by BMF/gralic/MRP/etc. on continuous tone (photographic images).

    FLIF does win on strange/artificial images.

    This is a video game screen shot :

    pnm 2,764,816
    png 1,459,310
    bim 1,035,443
    flic 891,913
    gralic 784,093
    bmf 772,344
    flif 710,768
    Last edited by cbloom; 3rd August 2016 at 20:32.

  15. #12
    Member
    Join Date
    May 2015
    Location
    ~
    Posts
    7
    Thanks
    1
    Thanked 1 Time in 1 Post
    Win 10 x64
    options used: flif -r3 / cwebp -z 9 -m 6 -mt -lossless

    1974444 wow05.06 - 02.41.11.png.flif
    1928218 wow05.06 - 02.41.11.png.webp


    2334033 minecraft2014-04-22_20.43.38.png.flif
    2305078 minecraft2014-04-22_20.43.38.png.webp


    2406359 ck2_7.png.flif
    2580744 ck2_7.png.webp


    3111091 l4d2oot_temple0000.png.flif
    2970176 l4d2oot_temple0000.png.webp


    2029821 SaintsRowTheThird_DX11_2015_07_12_01_28_54_662.png .flif
    2037966 SaintsRowTheThird_DX11_2015_07_12_01_28_54_662.png .webp

  16. The Following User Says Thank You to choochootrain For This Useful Post:

    Jyrki Alakuijala (4th October 2015)

  17. #13
    Member
    Join Date
    Oct 2015
    Location
    Belgium
    Posts
    29
    Thanks
    9
    Thanked 10 Times in 8 Posts
    Quote Originally Posted by choochootrain View Post
    Win 10 x64
    options used: flif -r3 / cwebp -z 9 -m 6 -mt -lossless

    1974444 wow05.06 - 02.41.11.png.flif
    1928218 wow05.06 - 02.41.11.png.webp


    2334033 minecraft2014-04-22_20.43.38.png.flif
    2305078 minecraft2014-04-22_20.43.38.png.webp


    2406359 ck2_7.png.flif
    2580744 ck2_7.png.webp


    3111091 l4d2oot_temple0000.png.flif
    2970176 l4d2oot_temple0000.png.webp


    2029821 SaintsRowTheThird_DX11_2015_07_12_01_28_54_662.png .flif
    2037966 SaintsRowTheThird_DX11_2015_07_12_01_28_54_662.png .webp
    That's not really a fair comparison though. WebP does not support progressive decoding, while FLIF does by default. So a fairer comparison would use flif -n

  18. The Following User Says Thank You to Jon Sneyers For This Useful Post:

    Jyrki Alakuijala (4th October 2015)

  19. #14
    Member
    Join Date
    Jun 2015
    Location
    Switzerland
    Posts
    667
    Thanks
    204
    Thanked 241 Times in 146 Posts
    Quote Originally Posted by Jon Sneyers View Post
    That's not really a fair comparison though. WebP does not support progressive decoding, while FLIF does by default. So a fairer comparison would use flif -n
    Agreed. Also, please compare the development version of cwebp, from github. I improved the performance with some classes of pics (including grayscale) by 30 %, and the typical pic by 1.5 % in June 2015. These improvents are not in 0.4.3.

  20. #15
    Member
    Join Date
    Sep 2007
    Location
    Denmark
    Posts
    856
    Thanks
    45
    Thanked 104 Times in 82 Posts
    just a quick test

    Code:
                    Color   PNGbest.bat	           Fliff
    ootschar.png    8bit    75.6 KB (77,478 bytes)     85.4 KB (87,465 bytes)	
    oots9904.png    8bit    254 KB (260,822 bytes)     259 KB (265,927 bytes)
    Content.jpg     24bit¹  623 KB (638,686 bytes)     529 KB (542,548 bytes)
    Witchblade.jpg  24bit²  2.14 MB (2,253,500 bytes)  1.40 MB (1,473,779 bytes)
    
    
    ¹ Looks visually like a palletede image but have more colors.
      probably due to jpg artifacts
    ² Scanned image of a low color comic front page. again probably jpeg artifacts
      are the reason for most of the colors.
    Flif seems to be lacking punch in 8bit palette images but does great once more colors are introduced from jpeg artifacts.
    none of these pictures where photo realistic though.

  21. #16
    Member
    Join Date
    May 2015
    Location
    ~
    Posts
    7
    Thanks
    1
    Thanked 1 Time in 1 Post
    Quote Originally Posted by Jon Sneyers View Post
    WebP does not support progressive decoding, while FLIF does by default. So a fairer comparison would use flif -n
    Quote Originally Posted by Jyrki Alakuijala View Post
    Also, please compare the development version of cwebp, from github.
    Thanks for the heads up, same set with flif -n and cwebp 0.4.4 git, 0.4.3 and 0.4.0:

    2519382 ck2_7.png.040.webp
    2580744 ck2_7.png.043.webp
    2568798 ck2_7.png.044git.webp
    2406359 ck2_7.png.flif
    2312699 ck2_7.png.n.flif

    2942116 l4d2oot_temple0000.png.040.webp
    2970176 l4d2oot_temple0000.png.043.webp
    2967308 l4d2oot_temple0000.png.044git.webp
    3111091 l4d2oot_temple0000.png.flif
    3008395 l4d2oot_temple0000.png.n.flif

    2249354 minecraft2014-04-22_20.43.38.png.040.webp
    2305078 minecraft2014-04-22_20.43.38.png.043.webp
    2264912 minecraft2014-04-22_20.43.38.png.044git.webp
    2334033 minecraft2014-04-22_20.43.38.png.flif
    2182334 minecraft2014-04-22_20.43.38.png.n.flif

    2010436 SaintsRowTheThird_DX11_2015_07_12_01_28_54_662.png .040.webp
    2037966 SaintsRowTheThird_DX11_2015_07_12_01_28_54_662.png .043.webp
    2035240 SaintsRowTheThird_DX11_2015_07_12_01_28_54_662.png .044git.webp
    2029821 SaintsRowTheThird_DX11_2015_07_12_01_28_54_662.png .flif
    1946201 SaintsRowTheThird_DX11_2015_07_12_01_28_54_662.png .n.flif

    1878226 wow05.06 - 02.41.11.png.040.webp
    1928218 wow05.06 - 02.41.11.png.043.webp
    1918848 wow05.06 - 02.41.11.png.044git.webp
    1974444 wow05.06 - 02.41.11.png.flif
    1856102 wow05.06 - 02.41.11.png.n.flif

  22. #17
    Member Alexander Rhatushnyak's Avatar
    Join Date
    Oct 2007
    Location
    Canada
    Posts
    232
    Thanks
    38
    Thanked 80 Times in 43 Posts
    LPCB images:
    the total compressed size is
    =1128615725 FLIF.exe -n
    ~1133000000 FLIF.exe -n --repeats=10
    The latter is approximate because it crashes on STA13843.ppm

    This newsgroup is dedicated to image compression:
    http://linkedin.com/groups/Image-Compression-3363256

  23. #18
    Member
    Join Date
    Sep 2010
    Location
    US
    Posts
    126
    Thanks
    4
    Thanked 69 Times in 29 Posts
    BTW lossless image seems like an obvious area for context mixing. You have various predictors (gradient from neighbors; edge-directed, prediction from other color planes, prediction from LZ-like match) and you want to weight & combine them. I'm not aware of anyone really doing this, thought I guess I don't know what's in BMF and perhaps the PAQ image model is like this?
    Last edited by cbloom; 3rd August 2016 at 20:32.

  24. #19
    Member
    Join Date
    Oct 2010
    Location
    Germany
    Posts
    275
    Thanks
    6
    Thanked 23 Times in 16 Posts
    Just google "predictor blending image compression", you'll be surprised. The blending is often done based on the prediction error. PAQ does it by minimizing Kullback-Leibler divergence.

  25. #20
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    437
    Thanks
    1
    Thanked 96 Times in 57 Posts
    Quote Originally Posted by willvarfar View Post
    FLIF is a novel lossless image format which outperforms PNG, lossless WebP, lossless BPG and lossless JPEG2000 in terms of compression ratio.According to the compression experiments we have performed, FLIF files are, on average:
    • 26% smaller than brute-force crushed PNG files,
    • 35% smaller than typical PNG files,
    • 37% smaller than lossless JPEG 2000 compression,
    • 15% smaller than lossless WebP,
    • 22% smaller than lossless BPG.


    Actually, I cannot quite confirm this. Or rather, the above is heavily exaggerating the performance benefits. I'm testing here on the JPEG AIC Core1 test image set, and these are the average bitrates I get over the complete set:

    JPEG2000 10.84194
    JPEG-LS 12.43031
    JPEG-LS2 10.66394
    FLIF 10.03118

    So that makes FLIF 6% better than JPEG LS part 2, or 8% than JPEG 2000 lossless. That's *a lot* less than the claimed "37% smaller than JPEG 2000". So it looks to me that you should probably have a very critical look at your test image set, or you might have overfitted your algorithm to your test images.

  26. #21
    Tester
    Stephan Busch's Avatar
    Join Date
    May 2008
    Location
    Bremen, Germany
    Posts
    872
    Thanks
    457
    Thanked 175 Times in 85 Posts

    Question

    Quote Originally Posted by choochootrain View Post
    Thanks for the heads up, same set with flif -n and cwebp 0.4.4 git, 0.4.3 and 0.4.0:

    Where did you get WEBP 0.4.4git?
    Can you please provide a download link?

    Thank you very much

    Best regards,

    Stephan

  27. #22
    Member
    Join Date
    May 2009
    Location
    France
    Posts
    95
    Thanks
    13
    Thanked 72 Times in 42 Posts
    Hello,

    Today git cwebp binary (MSYS2/gcc 5.2.0 win32, PNG input), barely tested as usual, be warned.
    cwebp_git_20151016_win32.7z

    On some pictures, '-lossless -m 6' produces heavier files than '-lossless'.

    AiZ
    Last edited by AiZ; 16th October 2015 at 12:37. Reason: typo

  28. The Following 2 Users Say Thank You to AiZ For This Useful Post:

    lorents17 (16th October 2015),Stephan Busch (20th October 2015)

  29. #23
    Member
    Join Date
    May 2008
    Location
    England
    Posts
    325
    Thanks
    18
    Thanked 6 Times in 5 Posts
    It's not actually 0.4.4 in git i think he just pulled that number out the air ;p it's leading to 0.5 atm.

    -m 6 is pretty odd yes, when doing non-lossess it can murder the image quality so i always stick with -m 4 (default)

    It also has some nasty image artefacts which were introduced after 0.3.1 on certain types of images, have submitted a bug report for it and maybe it'll be fixed one day. For me 0.2.1 webp gives the best image quality so i stick with that.

  30. #24
    Tester
    Stephan Busch's Avatar
    Join Date
    May 2008
    Location
    Bremen, Germany
    Posts
    872
    Thanks
    457
    Thanked 175 Times in 85 Posts
    Can anybody please provide a fresh win32 compile of current FLIF0.1 sources?

  31. #25
    Member
    Join Date
    May 2009
    Location
    France
    Posts
    95
    Thanks
    13
    Thanked 72 Times in 42 Posts
    Hello,

    Today git win32 binary:
    flif_win32_20151020.7z

    Watch out, tested on two files from Alexander's test data, resulting files are bigger.

    AiZ

  32. The Following User Says Thank You to AiZ For This Useful Post:

    Stephan Busch (20th October 2015)

  33. #26
    Member
    Join Date
    Oct 2015
    Location
    Curitiba
    Posts
    4
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Hi, with is the best format for one image that will ALWAYS have only 5 colors with a balanced distribution beetwen then and none kind of pattern?


    Here is one example.

    In PNG: 638.325 bytes
    In WEBP: 452.932 bytes

    Click image for larger version. 

Name:	test.png 
Views:	502 
Size:	623.4 KB 
ID:	3894

  34. #27
    Member
    Join Date
    Apr 2012
    Location
    Stuttgart
    Posts
    437
    Thanks
    1
    Thanked 96 Times in 57 Posts
    Quote Originally Posted by kredens View Post
    Hi, with is the best format for one image that will ALWAYS have only 5 colors with a balanced distribution beetwen then and none kind of pattern?
    Of what use are such images, or rather, is that really a "typical image" (as in "typical data source") you want to compress? Realistically, I'd try HEVC I-Frame compression with the screen-content coding mode, supporting the palette mode. Other than that, if *that* is *really* your typical image and you can invest into your own coding format, do this: Convert the colors into their palette indices, i.e. label each pixel by a number between 0 and 4. Then use an arithmetic encoder to encode the resulting bitstream. From an information theoretic point of view, this is your ideal compressor for this source. It takes on average log_2(5) bits per pixel, and you cannot get better than that. If you don't like this answer - what is *really* your problem?

  35. #28
    Member Skymmer's Avatar
    Join Date
    Mar 2009
    Location
    Russia
    Posts
    681
    Thanks
    37
    Thanked 168 Times in 84 Posts
    Here is the test I started a couple of days ago as simple comparison between PNG and FLIF on a small data set. Suddenly it growed up to a little bit more...
    Despite not too big overall size of the set the results are quite surprising if not too say more.

    Testset: 12 png files (3 x 8bpp, 5 x 24bpp, 3 x 8bpp (Grayscale), 1 x 1bpp), 4 232 995 bytes in total. Some of them picked up from my graphic data garbage and some of them created by myself.
    All PNGs passed through pngwolf --max-stagnate-time=0 --max-evaluations=200. To have an overall idea about the visual content you can view the image-strip below.

    Click image for larger version. 

Name:	test_strip.jpg 
Views:	391 
Size:	257.8 KB 
ID:	3904

    Competitors:
    Code:
         png: pngwolf --max-stagnate-time=0 --max-evaluations=200
         bpg: 0.9.6 -lossless -m 9
        webp: 0.4.3 -lossless -m 6 -q 100
    webp-git: cwebp_git_20151016 -lossless -m 6 -q 100
        flif: 0.1.1_3acea2e -n, picking up best among -a and -b
         bmf: 2.01 -S -Q9, tga input
     stuffit: 14.0.0.16 --recompression-level=2
         zcm: 0.93 -m7 -t1, ppm input
      packet: 1.2 -h4 -b512 -mx, tif input
       uharc: 0.6b -mx -md32768, tga input
    Results:
    Code:
                        PNG          BPG          WEBP       WEBP-GIT       FLIF         BMF         STUFFIT       ZCM          PACKET       UHARC
                      ---------    ---------    ---------    ---------    ---------    ---------    ---------    ---------    ---------    ---------
    8_map             136231       754809       137682       132568       131007       100628       99252        124061       124766       124473
    8_slam            404536       1171355      379758       376582       337831       278304       305214       312055       342868       314320
    8_var             25592        211328       23138        24222        22997        14220        12424        22973        22253        20065
    24_au             119831       532942       77278        81958        121406       55756        54434        96004        86584        93755
    24_desk           348194       913884       339238       349386       377526       289108       200177       226833       280322       238309
    24_encode         91441        357020       42494        44634        100768       35316        37725        42729        48136        43038
    24_intel          891677       950134       790446       773322       763151       571272       675452       728803       835762       747226
    24_lines          4466         258348       1684         3294         1548         884          2242         5314         3795         1973
    grey_beach        28074        46274        28164        31356        24751        16608        16320        24066        27966        23591
    grey_ship         1008019      1036776      1215900      941562       956882       850172       852901       1006787      1049621      1021882
    grey_xray         961961       964850       1341972      850622       834315       691276       724874       926655       1013914      945710
    mono_scroll       212973       1461014      -            -            144697       104444       61092        160049       159312       158098
                                                                                                                                        
    TOTAL:            4232995      8658734      4377754*     3609506*     3816879      3007988      3042107      3676329      3995299      3732440
    
    * - disquilified. unable to compress mono_scroll. total value without mono_scroll result.
    BPG is complete outsider in this test. It gives output data which is more than 2x larger comparing to original. Not sure how it should be called but I better keep silence here.
    BMF and Stuffit are expectable winners. Sad but true - BMF has its own limitations but at least it's freeware and not limited on input's dimensions\color as Gralic demo is, though such limitations of the latter are explainable.
    I don't know what to say about WEBP. Seems that the poor behaviour on greyscale data have been seriously improved (especially on grey_xray) in git version but still WEBP is disquilified due the simple fact that there is no support for width and height larger than 16383 pixels. Since mono_scroll file has height of 17314 pixels I simply got:
    Code:
    Error code: 5 (BAD_DIMENSION: Bad picture dimension. Maximum width and height allowed is 16383 pixels.)
    I don't know if it is a limitation of build or format but such limitation is quite bad.
    And now the FLIF. Well, for me it looks like a bad start. FLIF performed worser than general purpose archivers like ZCM and Uharc. Uharc 0.6b by the way celebrated 10th anniversary a month ago and its still shines.
    Also FLIF performed worse than WEBP (3816879 - 144697 = 3672182 which is > 3609506 of WEBP). Look closer to the results. On 24_au, 24_desk and 24_encode files FLIF compresses even worse than PNG.
    I can only hope that its just a beggining and a lot of improvements are possible.

    Here is some stuff which probably can be usefull.

    Testset itself: Download

    Alternative logo:
    Code:
    ______ __  (())______
    \___  |  | |  |  ___/
     \__  |  |_|__|  __/
       \__|_______|__/
    FLIF v0.1.1-3acea2e-skbuild (both x86 and x64)
    Code:
    	AiZ x86		sk x86		sk x64
    -----------------------------------------------------
    -n -a	146.056		137.317		106.654
    -n -b	125.730		117.912		 90.080
    -----------------------------------------------------
    TOTAL:	271.786		255.229		196.734
    Attached Files Attached Files

  36. The Following 3 Users Say Thank You to Skymmer For This Useful Post:

    AiZ (27th October 2015),Jon Sneyers (28th October 2015),Stephan Busch (28th October 2015)

  37. #29
    Member
    Join Date
    Oct 2015
    Location
    Belgium
    Posts
    29
    Thanks
    9
    Thanked 10 Times in 8 Posts
    What kind of images are in this JPEG QIC Core1 corpus? Are they all photographic in nature? (do you have a link to the test set?)

    Obviously the various JPEG algorithms perform much better on photographic images than on, say, line drawings. The 37% I claimed was only an average, and of course my test set may not be representative at all. On photographs, the difference is indeed typically less than 10%, while on some other kinds of images (e.g. diagrams or palette images), JPEG2000 produces files that are 10 times as large as PNG.

  38. #30
    Member
    Join Date
    May 2009
    Location
    France
    Posts
    95
    Thanks
    13
    Thanked 72 Times in 42 Posts
    Hello,

    I don't know why people are afraid to use the better BPG encoder (jctvc). Results are still catastrophic... but a bit less.

    Code:
    bpg: 0.9.6 -e jctvc -lossless
    
                        BPG    
                      ---------
    8_map             434683   
    8_slam            891175   
    8_var             84098    
    24_au             295352   
    24_desk           553436   
    24_encode         207731   
    24_intel          756880   
    24_lines          1559     
    grey_beach        32151    
    grey_ship         927286   
    grey_xray         921802   
    mono_scroll       752726   
                               
    TOTAL:            5858879
    And kudos for your x64 flif compile, what a difference with x86!

    AiZ

Page 1 of 6 123 ... LastLast

Similar Threads

  1. BIM (a new lossless image compressor) is here!
    By encode in forum Data Compression
    Replies: 43
    Last Post: 17th September 2013, 15:00
  2. FLIC - a new fast lossless image compressor
    By Alexander Rhatushnyak in forum Data Compression
    Replies: 25
    Last Post: 10th January 2013, 19:46
  3. New lossless image compressor
    By encode in forum Data Compression
    Replies: 105
    Last Post: 10th January 2013, 10:36
  4. Lossless image coders
    By Madgeniy in forum Data Compression
    Replies: 26
    Last Post: 11th July 2011, 09:06
  5. GraLIC - new lossless image compressor
    By Alexander Rhatushnyak in forum Data Compression
    Replies: 17
    Last Post: 29th November 2010, 21:27

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •