to speed flif encoding up, you can do fewer MANIAC tree learning iterations, setting -R 1 or if you want something quick -R 0 (and then later do a transcode with -R 2)
in fuif / jpeg xl you have more fine-grained control over encode speed, in flif you need an integer number of learning iterations and the default is -R 2, in fuif you can do a fractional number of learning iterations and the default is basically -R 0.5
I just got the AccessViolationException again in flif_encoder_encode_file() when encoding the 10000x10000x32bpp PNG. The RAM usage is about 900MB in the moment of the exception, but it's 1400MB if no exception occurs. You may want to check whether the memory allocation is done correctly on large files; maybe not on the FLIF encoder since you stopped working on it, but on the FUIF encoder.
well, I should stop mentioning a file type. I load every file into a .Net Bitmap object, so the original file type is pretty irrelevant.
@jonsneyers Yes, on Windows it's BGRA (https://stackoverflow.com/a/8104553). Is it different on other systems? Is there a way to make FLIF "compatible" to the Windows byte order? This would speed up the copying of image data a lot prior to the actual encoding.
@TheJaredWilcurt : I compiled the flif library using the "dl_make_vs.bat"
@sipa "the overhead of calling an exe" should be some tens of milliseconds, which is nothing even on my medium-sized images that take 5 seconds. It would only be relevant at encoding of tiny PNG images that take about 100ms.
@TheJaredWilcurt : I compiled the flif library using the "dl_make_vs.bat"
@sipa "the overhead of calling an exe" should be some tens of milliseconds, which is nothing even on my medium-sized images that take 5 seconds. It would only be relevant at encoding of tiny PNG images that take about 100ms.
Tests with different values of interlace and learn-repeat finished. Results on various kinds of image data are too long to post it here, but I can send it to anybody who's interested.
Summary for the 1280x960x8bpp:
Summary for the 1280x960x8bpp:
image.bmp 1280x960xFormat8bppIndexed : image=1228800 bytes, sourcefile=1229878 bytes, sourcefile/image=100,087728%
Interlaced = 1, LearnRepeat = 3, encoding: 00:00:04.4502546, file=430089 bytes, file/image=35,000732% file/sourcefile=34,970%
Interlaced = 0, LearnRepeat = 3, encoding: 00:00:04.2122409, file=433344 bytes, file/image=35,265625% file/sourcefile=35,235%
Interlaced = 0, LearnRepeat = 1, encoding: 00:00:01.5380880, file=435377 bytes, file/image=35,431071% file/sourcefile=35,400%
I'm having some trouble getting good results out of FLIF. I have a set of BMP images at 128x128, so every image is 12kb. If I convert these images to WEBP they all compress and have filesizes lower than 12kb. But if I convert them to FLIF they are all larger than 12kb. On bigger files FLIF always seems to beat WEBP but on this imageset FLIF is doing worse than the uncompressed BMP files.
with my WEBP conversion I use -z 9 (highest lossy compression level) and with FLIF I use -E=100
but probably there will still be quite some difference
brotli, ANS, sANS, BAC, huffman, ABRAC
basically everything after page 135 should be removed in my opinion, but I'm having a hard time convincing the Google team :)
I want to keep Brotli, ANS and ABRAC.
This is good progress
@viluon FLIF is a filetype. There are tools to convert from other file types to it, and tools to view those files. It is open source so anyone can contribute to it to improve it, or create their own encoding/decoding tools based on the spec and existing source code.
Active development efforts seem to have moved from it to FUIF and JPEG XL, which will have FUIF essentially built in, and FUIF has many ideas that are taken from FLIF
It doesn't convert
