Search results

The first pass is just 1 pixel. The second pass is 2 pixels. The third pass is 4 pixels. The fourth pass is 8 pixels. And so on. The first 12 passes give you a 64x64 image (less if the aspect ratio isn't square). This usually only takes a couple of KB. 

I just got an email from the CTO of EA Mobile. Looks like they might want to buy a more permissive license to use FLIF. I kind of feel like FLIF is becoming Pied Piper :o  

Yes, that's exactly the point. Currently FLIF always transforms the RGB input to YIQ, while perhaps in the case of JPEG, it would be better to use a color space closer to JPEG's YCbCr. That should help to make re-encoding JPEG files a bit more efficient (in particular, if the JPEG does chroma...

Yes, in particular if your source material is a JPEG file anyway, then you better apply some JPEG to JPEG lossless re-encoding and just keep it at that.  

Also I am still free to release it under other licenses as well, if and when I feel like it :) For now, GPLv3+ is all you get though.

I just mailed to one of the PNG mailing lists: http://sourceforge.net/p/png-mng/mailman/message/34506065/

The cost of RAM is not just in dollars but also in battery life. Remember, we won't have low-power RAM. If we have exact numbers (dollars and power consumption), we can make the trade-off, but for now, I think 2GB is a good guess. Sure, more RAM will be useful in some cases, like editing huge...

I just registered http://flif.info/ Now, how do I make sure that FLIF conquers the world and becomes a new standard image format, used all over the interwebs? This is quite an ambitious goal, right? So your suggestions are extremely welcome! This is what I'm currently doing in terms of coding:

I just bought a nice ARM-based Chromebook (to run Debian on it, of course, though this ChromeOS thing is kind of nice for web browsing). It has an NVIDIA Tegra K1, which is a Cortex-A15 just like the Pyra will be. It has 4GB of RAM. You can buy this laptop with either 2GB or 4GB of RAM, and I...

I think the candidate screen has 25ms response time, and the Pandora has 35ms response time I think.

Of course PIV will be one of the very first image viewers to support FLIF once the format is finalized :)  

OK, so I implemented something to improve frame diff encoding. It's not based on a single bounding box per frame, but on a row-by-row index of the column number of the first and the last modified pixels. So this is quite a bit more fine-grained, which has upsides and downsides. The main...

I'm not planning to use bounding boxes for the frame diffs, but something more fine-grained. I have an idea in my head, but no time to implement it right now -- first need to do some teaching...

I agree it can work both ways. I could make the frame interlacing optional -- essentially it's just about how to nest the loops. My reasoning is that for "long" animations, you shouldn't use an image format but you should use a real video codec. I'm not trying to reinvent the wheel here, there...

Here is a demonstration of the progressive loading thing for an animated FLIF file: http://people.cs.kuleuven.be/~jon.sneyers/FLIF/animation.php The one thing I didn't implement yet is this: http://littlesvr.ca/apng/inter-frame.html (it's on my todo list though ;) )  

Here are some more preliminary results: http://davidmz.github.io/apng-canvas/images/APNG-Icos4D.png 991,744      original APNG file 1,010,113   re-encoded APNG file (using zlib) 961,921      re-encoded APNG file (using 7lib) 960,443      re-encoded APNG file (using Zopfli) 866,483      lossless...

Probably not that much work in terms of actual programming effort, but it would take some time to get there: first I need to understand the code and conventions of the target program/community (e.g. ImageMagick, GIMP, SDL, browsers), then I have to do the actual integration (which should be...

I'm adding rudimentary support for animation to FLIF. Every frame has to be the same size as the first frame, and each frame completely replaces the previous frame. (maybe later I'll add support for frames which are smaller and have an offset, and frames that combine with the previous frame)...

Next on my todo list: animated FLIFs. After all, it's supposed to be better than existing formats, including GIF :)

There was a bug in my PNG loading code for 16-bit PNGs, so they just got misread. That probably explains the problems you got. I only tested PNM input and PNM and PNG output, not PNG input. It should work now.