Roadmap and crowd-funding

[hrj]

In order to evolve this demo into a production quality library, I am planning to spend some dedicated time on it.

Roadmap

• Async loading (start decoding while the bytes are still being fetched from the network)
• Async render (render while the decoding is still in progress)
• The above is with browsers that support WebWorkers. For older browsers, a work-around, such as decoding in a separate iframe can be considered. In the worst case, fall-back will be to synchronous versions.
• Stopping the decoding when sufficient resolution has been achieved. And resuming if requirement changes (user pinch-zooms on the image).
• Better support for animations including
  • Respecting the frame delay and looping constraints specified in the stream
  • Allowing playback control (pause, play, rewind, etc)
• Size and speed optimisations of the JS layer.
• Design a flexible API around all this functionality. There would be two APIs: a low level API which deals with just decoding a byte stream, and a higher level one which makes it convenient to render to a canvas or img element and to fetch data / decode asynchronously.
• Testing with different browsers that I have access to, which includes Chromium, Firefox on Linux, Android and Windows, and IE 8. Some testing could be done on cloud-hosted testing services as well.

  License

This work is a derivative of the upstream C++ code, so the license of this library will follow the upstream license. The current license is GPLv3. The informal word I have heard is that the decoder will be available in a more permissive license as soon as the bytestream format is finalised.

Crowd-funding

To be able to spend dedicated time on this, I am considering the option of receiving crowd-funds. My estimated time for completing the above is 4 to 6 weeks, and I feel around 3000 USD should help cover the cost.

Any feedback on the above would be highly appreciated.

[jonsneyers]

This sounds very good, but maybe we should be more ambitious and make a bigger crowdfunded project, where this would be one component. The goal of the project would be to create all the software needed to make FLIF a practical, mainstream and universal image format. The subtasks could include:

1. Browser support via JS polyfill (poly-flif)
2. Browser support via plugin/extension
3. Native browser support
4. GIMP import/export plugins
5. ImageMagick support
6. SDL_image support
7. apt-get install libflif libflif-dev flif-tools
8. Better support for camera raw images
9. Integration in dcraw and related tools
10. Progressive rendering of camera raw (making those embedded preview jpegs redundant)
11. Better / faster encoder
12. Lossy FLIF, e.g. to losslessly transcode existing JPEG images
13. Optimized implementation (asm, gpu, hardware?)
14. Video codec derived from FLIF? (cf ffv1)
15. ISO and/or W3C standardization
16. etc. etc.

Of course the above represents quite a huge amount of work. It would be a crowdfunding project at a much larger scale. With many "stretch goals" etc.

[hrj]

maybe we should be more ambitious and make a bigger crowdfunded project, where this would be one component.

That sounds fine too. Though managing all the items in that list would be a huge task by itself.

The list could be split into stages to make it more manageable. The first stage could be those items which are immediately actionable, say over a period of 3-6 months. I realize that this might be a little arbitrary, but it would help focus and organise effort.

A later stage could include the rest. By that time, the clarity would be more for everyone involved (contributors and funders alike).

[waldyrious]

What crowdfunding platforms are you thinking of, if any? I'd suggest either Gratipay or BoutySource as they are both focused on open source. BoutySource in particular supports 3 funding models: collective bounties on specific issues (claimable by whoever fixes the issue), one-time fundraisers, and continuous, regular funding through their Salt platform.

[ayurmedia]

Sounds great to see motivation to push this technology forward, as it has a good usecase on mobile devices or responsive css in general, making the image data fit to the viewed size and render it while its loading. On the other hand there will not be much support from users as gif, jpg, png or html5 video like gifv will be mainstream for a long time.

Also there are 2 barriers:

First it would need wide support in browsers, ideally directly in webkit, blink which powers a good share of all modern browsers (safari, chrome, opera, mobile browsers), but for quick adoption of flif in browser, your way with canvas and javascript is the only logical way to do it, as one can see that plugins are a no-go as flash and java and silverlight are dying out and get replaced with html5,js,css3 alternatives. i hope browser vendors catch up and extend html5 standard to natively support flif (or similar streaming image formats) so we get best performance, there are already decoders for gif, jpg, png and other formats, so it should be possible to add one for the exotic format flif, which has some advantages in modern responsive webdesign.

The second barrier will be adoption to a new format, as developers are used to use tools for producing gif, png, jpg depending on the needs, and it will take quite a while and change-management to change old behaviors. but switching to html5 or slowly addapting responsive design with css3 and media-queries shows that web developers can change their workflow and use new tech, if it fills a need and has advantages, as responsive css is ideal for different device-types and removes the need to build several versions of the html-page, or is even fluid, as the display-sizes of mobile phones and tablets are very fragmented and fluid css can adopt to it.

I got news about flif by browsing reddit.com, so maybe reddit would be a good discussion forum to get people to notice your plans to make flif a practical alternative and ready to use in the future. as croudfunding needs many people for support, this might be a way to advertice the ideas of this github project or other projects like tooling etc. also the reddit forums could be used to get a poll and feedback if there is a generall interest and support, or if people think its a crazy idea and png, jpg will never be replaced. i don't want to demotivate you, and like to see improvements in this tech in the near future, eg. timeframe 6 month to a year to use it in a real project, and maybe contribute a bit of time coding javascript on this github project if i feel it might lead to a usable solution. as you always have a tradeoff between high cpu-usage decoding and slow network connection, and future will show if flif can perform better on mobile responsive websites and show real benefits for users on the go with slow 3g connections, eg. make mobile-app users more happy with a better user experience.

i found flif over this reddit link which was top in reddit.com/r/all for a short time. maybe not exactly this thread, i just googled the most popular reddit comment thread for flif: https://www.reddit.com/r/programming/comments/3n7yvx/flif_free_lossless_image_format/

[hrj]

On Mon, Oct 26, 2015 at 3:42 PM, Waldir Pimenta wrote:

What crowdfunding platforms are you thinking of, if any?

I was thinking​ of a simple PayPal donation button, if it was only about poly-flif. It would allow me to focus on technical aspects and get the job done quickly.

​As a larger campaign, that simplicity may not work and I am open to other ideas.​

I'd suggest either Gratipay or BoutySource as they are both focused on open source.

​I have been following these systems for a while now (including Gratipay, BountySource, SnowDrift, FreedomSponsor), since I wanted to choose something for my other OSS projects.

​Gratipay is undergoing ​a lot of changes recently (closure of Balance Payments and redesign of their team feature).

SnowDrift is still under development, and FreedomSponsor doesn't have much traction. Which brings us to Bountysource:

BoutySource in particular supports 3 funding models: collective bounties on specific issues (claimable by whoever fixes the issue), one-time fundraisers, and continuous, regular funding through their Salt https://salt.bountysource.com/ platform.

I am more in favour of the last two models. The first model (claimable bounties) seem more suited for mature projects that need incremental updates. And even then, it can be a little controversial (rejected or neglected PRs, etc). I would stay away from that model for FLIF, for now.

​BTW, BountySource is also having some hiccups (the search feature isn't working, and their promised open-sourcing hasn't happened yet).​ But these are relatively small.

​Bitcoin or some such *coin wouldn't work for me; as there are legal issues surrounding it in my country, and again, I would rather focus on the technical stuff.

[waldyrious]

Glad to hear you're following the space of FOSS crowdfunding platforms closely :) I'd love to get your input in the summary document I've started a while ago but never got around to complete with all the details. It's a publicly editable spreadsheet, so feel free to either add comments or directly edit it.

[hrj]

It's a publicly editable spreadsheet, so feel free to either add comments or directly edit it.

​That's an interesting comparison. I haven't been following this stuff very closely (or methodically) to contribute. The snowdrift folks have very elaborate wiki pages summarising their research. For example: this comparison.

[waldyrious]

Ah, that's a nice resource, thanks. I'll take a look.

[hrj]

Thanks all for the feedback. Crowdfunding doesn't seem suitable at this stage. It might be more suitable when the project becomes popular. (And I lack the PR skills myself to make it popular).

I will "close" this issue, but further discussions are welcome in this thread.