@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
We took MANIAC from FLIF, turned it into MA-ANS, and made it significantly more powerful: it also does lz77-style references, it has a predictor and multiplier per MA context, and more predictors and MA properties.
The FLIF/FUIF-based mode in JPEG XL is called "Modular mode", and it is used for various things: lossless mode, the DC (1:8 image) in lossy mode, alpha and other extra channels, and all kinds of internal auxiliary images in lossy mode (the adaptive quantization map, block type selection map, chroma from luma coefficients, custom quantization tables, filter strength maps).
Version 0.1 was released last week. Plan is to reach 0.2 soon (bw-compatible bitstream), then 0.3 (stable libjxl api) by January, and hopefully we can get in the next Android and in Chrome somewhere in 2021.
this is extremely exciting
Also: 0.2 was released last week, bitstream is frozen!