flif-hub / flif Goto Github PK

If you want to address medical or other scientific domains, progress retrieval is not enough as images become very large.

You need a tiled storage layout so that progressive retrieval of cropped regions is efficient. You need to be able to quickly fetch and decode a high resolution portion of the image, without requiring the client to decode and store the rest of the image outside the cropped region of interest.

If you generalize to 3D or ND as in #10, this is further complicated by the region of interest being 3D or ND...

This table is 8KB in size.

As discussed in chat: The table could be either created dynamically, or replaced by some other logic.

Lossless is lossless. Of course there should also be an option to strip metadata.

On master + Ubuntu:

./flif benchmark/input/webp_gallery/2_webp_ll.png x.flif
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
abort (core dumped)

It used to work fine earlier.

Notes from chat:

sipa: @jonsneyer @hrj In the pyani example animation, with 70% or more truncation, you see weird transparent circular lines in the decoded image. My guess is that these are the result from interpolating incomplete Alpha data, in between "deep alpha" negative values, and positive ones?
I think it's better to have this reference data in a separate plane, which perhaps allows better prediction (as it's not really correlated to the actual alpha data), perhaps even a plane which goes before Y?
jonsneyer: Yes. Good idea. FRA was just a quick hack, it can be improved...

I would like to point out that identifiers like "__COMMMON_H__" and "_FLIF_H_" do not fit to the expected naming convention of the C++ language standard.
Would you like to adjust your selection for unique names?

I try to use./flif -i test.png test.flif but every time i got
Could not read input file: test.png.
Whats my fault?

I suggest to reuse a higher level build system than your current small make file so that powerful checks for software features will become easier.

• CMake
• Autotools

I have the following idea on how to add support for metadata:
A FLIF file is either a "bare" image file, or it is actually a .tar (or some other archive format) which contains files with standardized names, e.g. _image.flif, _meta.gz, _colorprofile.gz, browser_hints.gz. This would make it easy to add arbitrary information (just add a custom file to the archive) and manipulate or remove the metadata.

So basically the .flif file would only contain the information needed to decode the pixels, and anything else (including information on how to interpret the pixel values, like gamma etc) would be in those optional extra files.

Would that be a good idea?

There is an assertion failure while converting this file:
https://gitlab.com/freedroid/freedroid-src/raw/72d74df09a18bfc2dee8c92a17b43beb55da17d2/graphics/droids/arthur/portrait.png

flif: /home/matthias/vcs/github/FLIF/image/image.h:139: void Image::init(uint32_t, uint32_t, ColorVal, ColorVal, int): Assertion `max<256' failed.
zsh: abort (core dumped) /home/matthias/vcs/github/FLIF/flif ./graphics/droids/arthur/portrait.png

edit: I didn't pass any extra options to flif, just "flif oldfile newfile"

• libpng: 1.6.18
• zlib 1.2.8

I am guessing the dependencies based on the linker arguments, if I am missing
any please do mention them:

g++ -std=gnu++11 -DNDEBUG -O3 -g0 -Wall maniac/util.c maniac/chance.cpp image/crc32k.c image/image.cpp image/image-png.cpp image/image-pnm.cpp image/color_range.cpp transform/factory.cpp flif.cpp -lpng -o flif
image/image-png.cpp: In function ‘int image_save_png(const char*, const Image&)’:
image/image-png.cpp:133:37: error: ‘Z_BEST_COMPRESSION’ was not declared in this scope
   png_set_compression_level(png_ptr,Z_BEST_COMPRESSION);
                                     ^
Makefile:2: recipe for target 'flif' failed
make: *** [flif] Error 1

I've successfully compiled your code on Windows with the following changes: Bulat-Ziganshin@17e146d?diff=unified

Note that code for external formats (png, pam) is already using "rb"/"wb" fopen modes.

flif does not accept .flif files as input.
Possible use cases

• Forge several .flifs files into an animation.
• Remove/add interlacing
• Alter repeats for MANIAC learning.

Basically a continuation of #37 (comment).

It'd be nice if FLIF supported weird things like RGGB as well as RGB and RGBA.

Please forgive me if this is obvious, but why are modern video and image codecs/formats opting to have both lossy and lossless compression under the same file extension?

I see it as a disadvantage to do this, as it would make it harder to find a lossless version. Imagine if all FLACs could be either lossy or lossless, but you never knew until you downloaded it - wouldn't that be a waste of time?

Do you have plans on having a different file extension for lossy FLIFs than lossless FLIFs?

Can the encoding scheme generalize to an ND scalar field? I.e. actually make use of locality in more dimensions than just X, Y?

In addition to #8 scalar precisions, if you want to support medical imaging, it would really need to handle 3D volumes. Ideally, it should generalize to ND arrays, i.e. anything you can represent in a normal numerical library. It should also support multiple channels at each grid location.

https://i.imgur.com/VcyuTdJ.png

flif 13109 bytes
png   1941 bytes
webp   892 bytes

There are some arbitrary constants that could become variables...

Attempting to convert a large (24MP) 16-bit PNG results in FLIF eating a ton (>40GB) of memory.

This memory appears to be primarily produced in create_transform (heap profile produced by compiling FLIF with debug enabled and gperftools linked):

I improved the WebP lossless encoding significantly in June 2015. Using a newer version improves on the faces corpus by 31 % and less on other 4 corpora (0.8, 1.0, 13 and 21 %) I tested from your 26 test corpora. Please consider rerunning WebP lossless compression density tests with the development version from github.

https://github.com/webmproject/libwebp/

It seems there is a small memory leak.

Out of curiosity, I compiled FLIF with "-fsanitize=address,undefined -g3" CXXFLAGS.
Now running "flif FreedroidRPG.png bla.flif"
( sourcefile: https://gitlab.com/freedroid/freedroid-src/raw/72d74df09a18bfc2dee8c92a17b43beb55da17d2/graphics/FreedroidRPG.png )
seems to detect a memory leak:

=================================================================
==4571==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 192 byte(s) in 1 object(s) allocated from:
    #0 0x7fe4da2a0912 in operator new(unsigned long) (/lib64/libasan.so.2+0x99912)
    #1 0x4c7a6b in TransformCB<FileIO>::init(ColorRanges const*) (/home/matthias/vcs/github/FLIF/flif+0x4c7a6b)
    #2 0x52caf4 in bool flif_encode<FileIO>(FileIO&, std::vector<Image, std::allocator<Image> >&, std::vector<std::string, std::allocator<std::string> >, flifEncoding, int, int, int, int, int) /home/matthias/vcs/github/FLIF/flif-enc.cpp:318
    #3 0x572810 in handle_encode_arguments(int, char**, std::vector<Image, std::allocator<Image> >&, int, int, flifEncodingOptional, int, int, int) /home/matthias/vcs/github/FLIF/flif.cpp:204
    #4 0x574134 in main /home/matthias/vcs/github/FLIF/flif.cpp:345
    #5 0x7fe4d86826ff in __libc_start_main (/lib64/libc.so.6+0x206ff)

, compiled with gcc 5.1.1.

Any instructions of how to install it on Mac OS X. I already have libpng package in it how can install flip format ? Any example of conversion will also be helpful. :)

PNG use Adam7, which algorithm FILF use? and how it works?

How it compares to (closed-source) 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.

here we've found that Gralic compresses 10% better:
http://encode.ru/threads/2321-FLIF-Free-Lossless-Image-Format?p=45075&viewfull=1#post45075

Would it be possible to include filename, and text description (http://www.w3.org/WAI/WCAG20/quickref/#text-equiv) in metainfo (http://owl.phy.queensu.ca/~phil/exiftool/) such that the file format could be used to ensure accessibility for people with disabilities (as well as web crawlers or search engines) and is tied to the file itself? By doing so, we could specify web tools pull that information to generate alt text in HTML, as well as assistive technologies (screen readers) could pull it from the image itself.

Your website with the encoding bake-off might benefit from a comparison to JPEG-XR as it is a lot better than JPEG-2000...

./flif ./tools/2_webp_ll.png ./test1.flif
./flif -t ./test1.flif ./test2.flif
./flif -t ./test2.flif ./test3.flif
sha1sum test1.flif test2.flif test3.flif

0e0caa159252c7ccb30998b7ab7297a0b9cb057b  test1.flif
86ef4e2ade55db39bfe8eb7986bd1aedfb03503a  test2.flif
86ef4e2ade55db39bfe8eb7986bd1aedfb03503a  test3.flif

shouldn't test1, test2 and test3 technically all be the same file?

@jonsneyers In this Hacker News comment, you stated that you intend to relicense the project under a more permissive license (as desired by issues #3 and #9) after the project has matured slightly.

However, if you wish to change the project's licensing terms at a later point, you need to have contributors release their contributions under the terms of a Contributor License Agreement starting now. Otherwise, at said point of future maturation, you'll have to get everybody who's ever contributed a patch to the project to explicitly sign off on your desired relicensing, which is a pain (as the maintainers of projects which have had to do this in the past, such as Bootstrap, can attest).

http://www.harmonyagreements.org/ has a relatively simple generator for CLAs - once you've generated one, you can add it to the repo, and then request in any pull request that contributors explicitly state that they agree to the terms of the CLA and release their contribution under it (you can also automate this with cla-assistant, clahub, and/or clabot). You can (and should) also add a mention and further explanation of these terms to a CONTRIBUTING.md file in the repo's root.

With these agreements in place, you will be able to relicense the project in the future under whatever terms you decide, without having to get unanimous agreement from every user you choose to accept contributions from (no matter how minor).

The embedded getopt is licensed under BSD 4-clause, which in my understanding is incompatible with GPL.

Perhaps gnu-getopt would be a better option?

Regards

While playing with the web demo, I saw a glitch. See the shadow below the penguin:

I hope it is self-explanatory; let me know if you need more details.

Can we make it faster without sacrificing (too much) compression density?

file: https://raw.githubusercontent.com/widelands/widelands/master/tribes/barbarians/cattlebreeder/walk_e_07.png

If flif is compiled via

cmake .
make

there will be a crash:

./flif walk_e_07.png walk_e_07.flif 
flif: /tmp/FLIF/maniac/compound.h:510: void PropertySymbolCoder<BitChance, RAC, bits>::set_selection_and_update_property_sums(const Properties&, CompoundSymbolChances<BitChance, bits>&) [with BitChance = SimpleBitChance; RAC = RacDummy; int bits = 10; Properties = std::vector<int>]: Assertion `properties[i] <= range[i].second' failed.
zsh: abort (core dumped)  ./flif walk_e_07.png walk_e_07.flif

Namely, it renders it unusable for a wide array of uses, and, being the only implementation, with quite likely relatively few people interested in re-implementing it(it's not well known, or used), this means that no one will be creating FLIF images, and no one will be capable of using FLIF images.

I suggest keeping the specification as GPL, and re-implementing the library as LGPL, or MIT, instead of a viral license like GPL.

(Leaving room for future enhancements)

Hello there,

I made the following changes in the source code. Would you be interested in pull requests for any of them?

• win32 port
• msvc friendly
• removed libpng, zlib and getopt dependencies
• added stb image and miniz so it loads more lossless image formats now
• fixed a crash when no args were provided
• fixed mixed up c/c++ linkage problems

I've run a few tests on the lossless DNG files that Adobe compressors (Lightroom, Adobe DNG Converter) output and I've found that FLIF underperforms on some types of RAW (this example is produced by an A7II). Not sure what's going on.

Steps to reproduce (using sample data):

• convert sample.arw -depth 12 sample.ppm
• flif -vvvvvvvv -b -n -r 3 sample.ppm sample.flif
• (Use Adobe DNG Converter with lossless settings)
• du -sh sample.*

Expected results: FLIF file is smaller than DNG and the original
Actual results: FLIF is 2.4x the size of the original and the DNG:

 24M    sample.arw
 23M    sample.dng
 57M    sample.flif
139M    sample.ppm

This may be due to Sony's built in lossy compression, however. I think that's doubtful in the DNG's case since Adobe applies its own lossless compression (lossless JPEG 92) and this shouldn't benefit from Sony's.

It may also be due to bit depth. Sony's cRAW only appears to use 8 bits per pixel. Indeed, when I use an 8-bit PPM instead of 12, the size is 23M, the same as the DNG.

I tried this on another DNG derived from a camera that doesn't use lossy RAW compression (Olympus OM-D E-M5) and found that FLIF still underperformed:

> exiftool testImages/PA120012.dng | grep -i bit
Bits Per Sample                 : 16
Valid Bits                      : 12 0
> convert testImages/PA120012.dng -depth 12 testPNGs/PA120012.ppm
> ./flif -vvvvvvvv -b -n -r 3 testPNGs/PA120012.ppm testFlifs/PA120012.flif
  _____  __  (__) _____
 (___  ||  | |  ||  ___)   FLIF 0.1 [2 October 2015]
  (__  ||  |_|__||  __)    Free Lossless Image Format
    (__||______) |__)      (c) 2010-2015 J.Sneyers & P.Wuille, GNU GPL v3+

Loading input file: testPNGs/PA120012.ppm  
Input: 3472x4640, channels: [0] 12 bpp [1] 12 bpp [2] 12 bpp
Transforms: YIQ, BND[0:24..4095][1:516..7630][2:2505..6801]
Plane 0: 24..4095
Plane 1: 516..7630
Plane 2: 2505..6801
Learning a MANIAC tree. Iterating 3 times.
Header: 27 bytes. MANIAC tree: 129315 bytes.
75% done [1/3] ENC[3472x4640]    filesize : 11875219 (+11745877 for 16110080 pixels, 5.832809 bpp)
83% done [2/3] ENC[3472x4640]    filesize : 24216210 (+12340991 for 16110080 pixels, 6.128333 bpp)
91% done [3/3] ENC[3472x4640]    filesize : 35246901 (+11030691 for 16110080 pixels, 5.477659 bpp)
Encoding done, 35246901 bytes for 3472x4640 pixels (2.1879bpp) 
> du -sh testFlifs/PA120012.flif
 34M    testFlifs/PA120012.flif
> du -sh testImages/PA120012.dng
 16M    testImages/PA120012.dng

I just tried to make the project on Ubuntu, and some files referenced in the Makefile weren't there.

Please could you tag versions that can be compiled? Would be useful for people wanting to play with this interesting new project.

I ran a quick round of fuzzing using American Fuzzy Lop and immediately found the following examples:

root@e0a3ba7ea8a2:~/FLIF-master# ./flif -d  o/crashes/id\:000001*  /tmp/a.png
Warning: expected file name extension ".flif" for input file, trying anyway...
Floating point exception (core dumped)
root@e0a3ba7ea8a2:~/FLIF-master# base64 o/crashes/id\:000001\,sig\:08\,src\:000000\,op\:flip1\,pos\:7 
RkxJRjMxAAAAHoHz280HVfdJ5npjXrviUtU3tQFYKJtBFQorvILr
root@e0a3ba7ea8a2:~/FLIF-master# ./flif -d  o/crashes/id\:000002*  /tmp/a.png
Warning: expected file name extension ".flif" for input file, trying anyway...
Invalid tree. Aborting tree decoding.
Invalid tree. Aborting tree decoding.
Invalid tree. Aborting tree decoding.
Segmentation fault (core dumped)
root@e0a3ba7ea8a2:~/FLIF-master# ./flif -d  o/crashes/id\:000003*  /tmp/a.png
Warning: expected file name extension ".flif" for input file, trying anyway...
Invalid tree. Aborting tree decoding.
Invalid tree. Aborting tree decoding.
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)
root@e0a3ba7ea8a2:~/FLIF-master# ./flif -d  o/crashes/id\:000004*  /tmp/a.png
Warning: expected file name extension ".flif" for input file, trying anyway...
Segmentation fault (core dumped)
root@e0a3ba7ea8a2:~/FLIF-master# ./flif -d  o/crashes/id\:000005*  /tmp/a.png
Warning: expected file name extension ".flif" for input file, trying anyway...
Invalid tree. Aborting tree decoding.
Segmentation fault (core dumped)
root@e0a3ba7ea8a2:~/FLIF-master# ./flif -d  o/crashes/id\:000006*  /tmp/a.png
Warning: expected file name extension ".flif" for input file, trying anyway...
Invalid tree. Aborting tree decoding.
Invalid tree. Aborting tree decoding.
Invalid tree. Aborting tree decoding.
*** Error in `./flif': free(): invalid next size (fast): 0x0000000000d88760 ***
Aborted (core dumped)
root@e0a3ba7ea8a2:~/FLIF-master# ./flif -d  o/crashes/id\:000007*  /tmp/a.png
Warning: expected file name extension ".flif" for input file, trying anyway...
*** Error in `./flif': free(): invalid next size (fast): 0x00000000027111b0 ***
Aborted (core dumped)
root@e0a3ba7ea8a2:~/FLIF-master# ./flif -d  o/crashes/id\:000008*  /tmp/a.png
Warning: expected file name extension ".flif" for input file, trying anyway...
Floating point exception (core dumped)
root@e0a3ba7ea8a2:~/FLIF-master# ./flif -d  o/crashes/id\:000009*  /tmp/a.png
Warning: expected file name extension ".flif" for input file, trying anyway...
Invalid tree. Aborting tree decoding.
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)

You can quickly reproduce the fuzzing by creating a file named Dockerfile in a separate directory. File should have the following contents:

FROM d33tah/afl-sid
RUN cd /; wget --no-check-certificate "https://github.com/jonsneyers/FLIF/archive/master.zip"
RUN apt-get update; apt-get install pkg-config libpng-dev unzip -y
RUN . ~/.bashrc; cd / ; unzip master.zip ; cd FLIF-master ; make -j`nproc` 
RUN mkdir /i ; echo 'RkxJRjMxAAEAHoHz280HVfdJ5npjXrviUtU3tQFYKJtBFQorvILr' | base64 -d > /i/1
CMD . ~/.bashrc; afl-fuzz -i /i -o /FLIF-master/o /FLIF-master/flif -d @@ /tmp/out.png

Then cd into this file and run: sudo docker build -t flif-afl-sid . && sudo docker run -ti flif-afl-sid. Let me know if you need help extracting the crashing files later.

Currently FLIF does not compile without HAS_ENCODER set. Conditionally compile all encoder stuff, including in the help text etc.

Would be helpful for scientific and terrain uses.

Please make sure to allow for spatial metadata including projection (epsg or wkt), bounding region, ground control points etc. Needing to have side cars for the geotransform and or projection info is really painful

Background info:

• http://www.gdal.org/formats_list.html
• https://en.wikipedia.org/wiki/GeoTIFF

Very interesting work. I would like this kind of technology to succeed, but GPL is way too restrictive (even v3) to be used by for-profit entities. If they don't use it, FLIF will be always considered as niche for GPL only software.

For FLIF to be considered and accepted on say browsers, standard photographic manipulation software, transcoders, etc it needs to be available in a friendlier license.

Keep up the great work.

flif.h needs some love:

• function prefixes (encode and decode pollute the global namespace with generic names)
• C interface (C++ has no fixed ABI, and every language under the sun uses a C FFI for bindings.)
• Don't define v_printf in a public header.

Would you like to add more error handling for return values from functions like the following?

• fclose ⇒ file_is_flif
• fgetc ⇒ decode

Support raw input for encoding and output for decoding where we can specify number of rows, columns and bands, data type, endianness and signedness. This will make it much easier to test with medical imaging.

Which brings another question: do you support signed pixel data?

I'd like to ask that the use of GPL licensing be reconsidered. The GPL is primarily intended for applications, IE software that gets into the hands of end users (who may or may not wish to tinker with it). In doing so, however, it sacrifices some of the freedoms of application developers.

Developers who wish to use FLIF in their project would be forced to license it as GPL, and doing so would mean (A) sacrificing their freedom to license their project according to their needs and/or personal wishes, and (B) it would mean that other libraries they may wish to use would automatically not be an option because they are not under GPL-compatible licenses.

Because of those, it can mean that FLIF cannot be used in some projects. And I will note that none of the major browsers in use are GPL-licensed: they are either proprietary or licensed under permissive open source licenses. (The exception to this is firefox, which allows developers to choose between GPL, LGPL, and MPL according to their needs). The libraries that browsers use to support established image standards, libpng, libjpeg, giflib, openJPEG, and Jasper, are all under permissive licenses.

FLIF is advertised as being royalty-free and unencumbered by software patents. But the unfortunate reality is that the GPL is as much of a barrier to adoption as royalty fees and software patents, because just like those it places additional restrictions upon developers. Sadly, the GPL is simply not flexible enough to accommodate the needs of larger open source projects. And although you may not like proprietary software much, their support is needed as well in order for FLIF to become an established standard, and they won't support it if it is GPL.

So, I would like to propose that the following alternatives be considered:
A) Allowing exemptions to some of the non-permissive terms of the GPL, or allow developers to request an alternative license that better suits their needs. Some open source projects make money with paid exemptions, which can be used to finance further development on the project by paying for developer time.
B) Adopt a permissive license. No major developer freedoms are sacrificed with this route. However, you lose one advantage of the GPL, which is the requirement that fixes and improvements to the library itself be contributed back if publicly distributed.
C) Adopt the LGPL. It is a much better fit for libraries than the GPL. It preserves the GPL's requirement for improvements/fixes to be contributed back, but without forcing developers to change their licensing, and it doesn't produce a licensing conflict that prevents the usage of other libraries.

I have created a poly-fill / playground for FLIF, using emscripten.

Code

Demo

It's not perfect; there is a memory leak.. Solved.

Feedback welcome!

Hi there

Apart from a couple of warnings (missing return values):

transform/../image/image.h:118:2: warning: control reaches end of non-void function [-Wreturn-type]

I also get an error when trying to compile:

common.cpp:5:32: error: non-aggregate type 'const std::vector<std::string>' cannot be initialized with an initializer list
const std::vector<std::string> transforms = {"YIQ","BND","ACB","PLT","PLA","FRS","DUP","FRA","???"};

The error message sounds really strange to me. Any idea? My compiler (on Ubuntu 12.04.5 LTS):

$ clang -v
Ubuntu clang version 3.0-6ubuntu3 (tags/RELEASE_30/final) (based on LLVM 3.0)
Target: x86_64-pc-linux-gnu
Thread model: posix

cheers,
floyd