jonsneyers

22 ms·

1. 211.▲
   by jonsneyers 11y ago

   Thanks for the compliment about FLIF's progressive decoding! (FLIF author speaking here) However, truncated FLIF files will (probably) never achieve the same quality/size ratio as dedicated lossy methods that can produce a complet
2. 212.▲
   by jonsneyers 11y ago

   1) How does a GPL'ed reference implementation prevent digital cameras from using the format? 2) The reference implementation will most likely change to a more permissive license, cf https://github.com/FLIF-hub/FLIF
3. 213.▲
   by jonsneyers 11y ago

   FLIF only has a lossless mode. For lossless animation, it usually beats GIF, APNG, MNG, WebP and BPG. It is the only responsive animation format afaik. For lossy movies, actual video codecs are best, since they're designed for that. BP
4. 214.▲
   by jonsneyers 11y ago

   The original PNG of that PBF comic is 671,012 bytes. ZopfliPNG crunches it down to 585,117 bytes. Not bad, but if you use newer image formats, you can do better. Lossless WebP brings it down to 429,696 bytes (using -lossless -m 6 -q 100) FL
5. 215.▲
   by jonsneyers 11y ago

   For each algorithm, the images are sorted from best (on the left) to worst (on the right). So if you look at the middle region of the graph, you see how they behave on "median" images. Another way to view the graph is: the area un
6. 216.▲
   by jonsneyers 11y ago

   I only tried bpgenc with the default speed presets. It's a bit premature to discuss compression/decompression speed, because this is just a prototype implementation and there are probably many ways to improve the speed. Premature
7. 217.▲
   by jonsneyers 11y ago

   Thanks for pointing this out! I only tried ImageMagick convert at minimum -quality. Sorry about that.
8. 218.▲
   by jonsneyers 11y ago

   You're right about the interpolation method (bilinear vs nearest-neighbor), it's indeed not a fair comparison in that respect. However, I do think that most PNG viewers use nearest-neighbor (at least that's what my viewer did
9. 219.▲
   by jonsneyers 11y ago

   Done.
10. 220.▲
    by jonsneyers 11y ago

    I think JPEG's color transform is lossy, so even those basic blocks are somewhat lossy. A better approximation of the entire 8x8 block than the exact pixel at the top-left position of the block, which is what FLIF and PNG with Adam7 in
11. 221.▲
    by jonsneyers 11y ago

    That's true. I tried a variant where the resampling would be better, but while it is possible, it hurts the compression rate significantly. At the level of a single step: if you have two pixels A and B that are both 8-bit numbers, then
12. 222.▲
    by jonsneyers 11y ago

    Can be done. Basically just change the type of ColorVal and implement a float variant of writer() and reader() in maniac/symbol.h.
13. 223.▲
    by jonsneyers 11y ago

    To clarify: at the moment FLIF is licensed under the GPL v3+. Once the format is finalized, the next logical step would be to make a library version of it, which will be most probably get licensed under the LGPL v3+, or maybe something even
14. 224.▲
    by jonsneyers 11y ago

    FLIF also emits Y first (actually alpha first), before the chroma channels.