• Content count

  • Joined

  • Last visited

1 Follower

About _wb_

  • Rank
  • Birthday 06/21/81

Profile Information

  • Gender Male
  • Location Brussels, Belgium

Recent Profile Visitors

11475 profile views
  1. Pyra Developers.

    I'm currently a bit occupied with FLIF, but I plan to make stuff for the Pyra. Probably not exclusively for Pyra, but at least tweaked for Pyra. E.g. I might want to re-implement Pandora System Info to become a more general System Info thing, the same with Pandora Image Viewer and maybe some of the games I made for the Pandora (Microbes, NubNub, NanoLemmings).   Who knows, maybe at some point I'll make a web browser with native FLIF support, tweaked for devices with a small screen and two nubs  
  2. Keymat Sample Pictures!

    Looks very nice!
  3. Yes, FLIF would not be suitable at all as an in-memory texture format. It might be suitable as an on-disk texture format though.
  4. FLIF metadata (in the beginning of the stream) could contain a list of prefix sizes for different resolution/quality settings. Maybe the img tag needs an optional "priority" attribute to help browsers choose the order in which images are downloaded/refined.
  5. The client knows the total file size I suppose. Just downloading a fixed percentage of that could be good enough.
  6. 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. 
  7. 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  
  8. The challenge will be to add this "partial download" functionality to browsers. It's a feature they don't have yet at the moment (even though theoretically, it would make sense also for Progressive JPEGs and Adam7 interlaced PNGs -- I didn't invent progressive decoding, I only improved it slightly), and it would be of crucial importance to make the "Responsive By Design" idea of FLIF work at all. Animated files: FLIF does not accept APNG as input, though it will work because APNG is "backwards-compatible" in the sense that it is a valid PNG file which only contains the first frame. So you first have to use apngdis to get the individual frames, then "flif -vvv frame*.png animation.flif" to encode the animation and "flif animation.flif foobar.png" to decode it (you will get no output file foobar.png but individual frames foobar-00.png, foobar-01.png etc).  
  9. 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.  
  10. 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.
  11. I just mailed to one of the PNG mailing lists: http://sourceforge.net/p/png-mng/mailman/message/34506065/
  12. Ram Poll.

    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 audio/video files or browsing with hundreds of tabs. Money and battery life are also useful in some cases.
  13. 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:
  14. Ram Poll.

    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 picked the 4GB model. Now when I look at how it is configured by default, I was a bit surprised to find out that it seemed to have only 2GB of RAM. I wondered where the other 2GB went. Turns out only 2GB of RAM is used as RAM on this machine, and the other 2GB is used only as a zram swap partition. Nice idea -- maybe on the Pyra we could also use part of the RAM as a zram swap partition by default (e.g. 1.5GB RAM, 0.5GB swap). My point is: even on this full-sized laptop (OK, it's "only" a chromebook, but still, it's a pretty nice machine), 2GB of RAM is enough. I'm using ChromeOS and a Debian chroot at the same time, and while ChromeOS can eat quite a lot of RAM (it's processes fill the top-5 of memory users, then number 6 is Xorg and then the rest of the top-10 is more chrome processes), Debian doesn't have a big memory footprint at all.
  15. Parallel Production and new boards

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