261–270 of 374 posts
Earlier quoted context omitted.
Also no more .thumbnails folders I imagine images appearing as fast as I can scroll, with enough visual clue to them to find images way way more quickly than with thumbnails today. As a start, thumbnails could use flif.
I think some formats already support embedded thumbnails. (EXIF metadata can contain thumbnails, I believe)
They claim this is good for responsive images: The download or file read operations can be stopped as soon as sufficient detail is available, and if needed, it can be resumed when for whatever reason more detail is needed. -- http://flif.info/responsive.php Unfortunately that's not how HTTP works. Your browser opens several connections to a website, and makes requests for resources. Each connection is in use until th…
Earlier quoted context omitted.
True, but the only complete documentation of the file format I found was the source code of the reference implementation. So the only way to write a new implementation is to study the reference implementation, which will make your new implementation "tainted".
Studying GPL'ed source code does not "taint" anything. You're absolutely allowed to do that. If you're really concerned about subconsciously copying elements of the original into your implementation, you could let somebody else study the original and write a spec.
This is far from my area of expertise, but lawyers smarter than me about these things disagree.
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 more permissive. There is not much point in doing that when the format is not yet stable. It's not because FLIF is GPL v3+ now, that we can't add more permissive licenses later. A…
Game development projects, in particular, will avoid it, as will almost anything that wants to publish an application to the Apple App Store or Google Play.
You may wish to consider whether adoption of a standard implementation is more important than other goals you may have considered in choosing a license.
This is really interesting. One of the most interesting parts is the progressive decoding/responsive images. http://flif.info/example.php (go to the bottom of the page). Basically, the last example shows that, if you want a scaled version of the image, you can simply stop decompressing. No need for multiple image files. Just create one with very high quality and decompress until you get the quality you want and scale…
If you want to use a similar feature -today-, there's this service called Imgix: https://www.imgix.com/ Basically, it allows you to use responsive images using 1 single master image. Makes for a really snappy user experience, and it's very easy to integrate into any project, new or old.
They claim this is good for responsive images: The download or file read operations can be stopped as soon as sufficient detail is available, and if needed, it can be resumed when for whatever reason more detail is needed. -- http://flif.info/responsive.php Unfortunately that's not how HTTP works. Your browser opens several connections to a website, and makes requests for resources. Each connection is in use until th…
Earlier quoted context omitted.
But that is not the same. That is a small, but fixed size, second version of the image, embedded into the same file. With FLIF you simply read the first N bytes of the full image and have a resonable preview. You choose how big or small N has to be, depending on the size of the thumbnail you want to show. Maybe first read N bytes for each image to get a quick but rough preview, then repeatedly read a few bytes more t…
To be fair, that's not the same thing either. A thumbnail is resampled in a way to resemble the original at a smaller size. This will be resampled with (more or less) nearest neighbor, which means lots of aliasing and possibly looking nothing like the original, depending on the subject.
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 more permissive. There is not much point in doing that when the format is not yet stable. It's not because FLIF is GPL v3+ now, that we can't add more permissive licenses later. A…
> WARNING: FLIF is a work in progress. The format is not finalized yet. Any small or large change in the algorithm will most likely mean that FLIF files encoded with an older version will no longer be correctly decoded by a newer version. Keep this in mind. This seems so... avoidable. Maybe the FLIF format could include a version number declaration?
If they do it for pre-finalization versions, then they (and other implementations) will have to keep supporting them, which probably doesn't make sense considering how small the corpus of images in this format likely is.