6 ms·
Clever, but I'd love to see browser support for FLIF make this kind of thing irrelevant. > FLIF is lossless, but can still be used in low-bandwidth situations,
by nathan_long 9y ago
Clever, but I'd love to see browser support for FLIF make this kind of thing irrelevant.
> FLIF is lossless, but can still be used in low-bandwidth situations, since only the first part of a file is needed for a reasonable preview of the image.
> A FLIF image can be loaded in different ‘variations’ from the same source file, by loading the file only partially. This makes it a very appropriate file format for responsive web design.
The loading video on http://flif.info/index.html http://flif.info/index.html makes this clear.
- baybal2 9y ago>Clever, but I'd love to see browser support for FLIF make this kind of thing irrelevant. No, it will not make much difference. You rarely need lossless for anything but stuff like UI elements, which to begin with should not be drawn as PNGs if they are simple graphics that can be drawn as SVG
- nathan_long 9y agoHow will FLIF "not make much difference" here? Suppose we're talking about a profile image. The full, lossless file is 40KB. The video on the FLIF site (http://flif.info/index.html http://flif.info/index.html) shows a blurry-but-useful preview being displayed with the first 0.25% loaded (and possibly before). In this case, that's 100 bytes, which is a fraction of a single TCP packet. Don't need the full resolution of the 40KB lossless file? OK, sure, stop loading after 20KB, or 10KB, or 1KB, or whatever seems like enough. Yes, SVG is still better for things like icons, because you get clear, resizable images with a tiny data transfer. But for previewing a photograph, FLIF seems ideal, and doesn't require any additional tools.
- baybal2 9y agoMaybe, people usually just recode avatars to low-res JPGs
- nathan_long 9y agoFLIF makes re-encoding unnecessary. http://flif.info/responsive.html http://flif.info/responsive.html > for every image, only one file is required, ever. The optimization can happen entirely on the client side. > A FLIF image can be loaded in different ‘variations’ from the same source file, by loading the file only partially. This makes it a very appropriate file format for responsive web design. Since there is only one file, the browser can start downloading the beginning of that file immediately, even before it knows exactly how much detail will be needed. 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 — e.g. the user zooms in or decides to print the page.
- TheAceOfHearts 9y agoRendering SVG is considerably slower than PNG. If you know the target's display DPI, generating PNGs from the source SVG ahead of time is usually the better choice.
- mcphage 9y ago> browser support for FLIF make this kind of thing irrelevant I'm not sure it would. The nice thing about a lot of these SVG options (or even the smaller images as well), is that they can be embedded into pages. So not only do you see the image faster, you also reduce the number of remote file fetches. FLIF sounds like you'd still have to hit another server to see anything, even if the thing you see would display before it finishes loading.
- nathan_long 9y ago> The nice thing about a lot of these SVG options (or even the smaller images as well), is that they can be embedded into pages That's a good point. Though presumably you could embed FLIF data into HTML using a data URI - https://css-tricks.com/data-uris/ https://css-tricks.com/data-uris/
- ant6n 9y agoCan a data uri be used to store 10% of a file in HTML, but then get the rest of a file? I mean you don't want to include the whole file.
- nathan_long 9y agoYou should be able to encode the first 10% of a file as a data URI, yes. Maybe you could use something like `srcset` to say "and also load the higher-quality verion from the server"? https://responsiveimages.org/ https://responsiveimages.org/
- BHSPitMonkey 9y agoI think they mean, could you inline the first 10%, and then lazy-load the other 90% (taking advantage of the FLIF decoder's progressive rendering). Which I would have to imagine is a "no" (you would have to swap your 10% placeholder with a whole 100% remote version).
- 9y ago
- klodolph 9y agoThe problem with FLIF here is that it's not remotely competitive when you're using a lossy format for both the low-quality and high-quality versions, which is the most common case for photos. UI elements tend to be small, so it doesn't matter. In most cases if you get more bandwidth which you could spend on using a lossless FLIF, you would get better subjective quality by using a higher resolution JPEG at the same file size.
- nathan_long 9y agoIf you need to use an image twice, once low-quality and once high-quality but not perfect, FLIF would let you load (say) 10% of the image in one place and 50% in another. Are you saying that for the same bandwidth usage, you could load two separate lossy JPGs and they'd look better? What if the fact that you've loaded the first 10% of the FLIF for the low-res version means you can resuse that data and start with the 11th percent when loading the high-res version?
- klodolph 9y ago> Are you saying that for the same bandwidth usage, you could load two separate lossy JPGs and they'd look better? The tests I've done are along the lines of this (I forget the exact numbers I used): * JPEG: 10kB + 90kB * FLIF: 100kB JPEG usually wins for photographic source material. I was unable to come up with “reasonable” parameters where FLIF would win, but perhaps someone creative can figure that part out.
- LeifCarrotson 9y agoYou didn't mention the result of your tests, but I infer that you found the 90 kB JPEG to be superior to the 100 kB FLIF/PNG? That seems reasonable, if unfortunate.
- klodolph 9y agoYes, for photographs. This shouldn't be surprising. Note that the FLIF home page doesn't even claim that FLIF is superior to normal JPEG images... it only claims that it's superior to other lossless formats. For lossless formats, you can compare your desired metric (e.g. file size) for your corpus. For lossy formats, you can either fix subjective quality and compare size, or fix size and compare subjective quality. (Or compare some other metric, but these two are more common.) These are completely different ways of evaluating compression algorithms, and it intuitively makes sense that different algorithms will be better if you evaluate them differently. Consider that FLAC gives the best bitrate for lossless audio, but Opus gives a far better bitrate when you fix the subjective quality or a better quality when you fix the bitrate at reasonable rates. Or consider that there is a wide spectrum of data compression algorithms, each of which performs the best depending on how you assign weight to compression speed, decompression speed, and compression ratio, and what is in your corpus. There is a surprising variety of new compression algorithms out there, some of which may be the best for your use case even though their compression ratios are significantly worse than other well-known algorithms (LZ4, LZFSE, Snappy, for example). JPEG is designed for best quality at reduced bit rates, so it should not be surprising that it is good at doing that, even though it is old and newer algorithms are better.
- rhn_mk1 9y agoI hope the same. I love what people can do with vectorization, but personally, I'd be happier if there was an established standard for previewing content. As it is, a lot of previews don't work for users who don't trust the site enough to enable JavaScript.
- robbrown451 9y agoIf you've got JS turned off, isn't lack of image previews about the smallest issue you'll face?
- zeveb 9y agoNot really; it's actually one of the biggest ones. There are several categories of sites which fail due to reliance on JavaScript: - Sites which should work perfectly but don't work at all (e.g. Blogger). These are so annoying because serving text & images is exactly what the web is good at, and requiring JavaScript to do it is just abusive and borderline evil. - Sites which work perfectly fine, except that all the images are blurry, low-res placeholders. These are so annoying because they're actually serving images. Their developers know how to do the right thing, but obstinately refuse to do so. - Sites where small things don't work. They are annoying, but at least one can read them. Ars Technica gets a special mention for the fact that its articles are perfectly readable but the comments are not. I chalk this up to incompetence and laziness. - Single page apps which really need to be single-page apps. They're annoying because they would almost certainly be better as native apps, but they really are doing something that the static web can't do.
- rhn_mk1 9y agoArs Technica can be fixed with the following CSS loaded into Stylus: .comments-row { display: inherit; } Seeing that it's such a small change, it really makes me wonder why they don't already include it.
- city41 9y ago> They're annoying because they would almost certainly be better as native apps I definitely disagree. If something is truly an application and can also be done on the web, I vastly prefer that over native apps. Not having to worry about different OSes, different machines, updating, deployments, etc. Webapps have significant advantages over native here IMO.
- badsectoracula 9y ago> I'd love to see browser support for FLIF Wouldn't WebAssembly make waiting for browser support unnecessary?
- jerf 9y agoFor certain values of "unnecessary", yes. We've still got a few steps to go before we can decode an image with SIMD instructions (assuming FLIF can use those to speed up, though I imagine it can as any modern image format ought to take that into consideration), and I'm not sure what the story is for pushing images efficiently to the browser, but you should at least be able to put something together that works in WebAssembly now and speed it up in various ways later.
- flukus 9y agoDo we need a new format? I remember jpeg's had this kind of functionality back in the days of dialup, all the patents for that should have expired long ago.
- fencepost 9y agoAre you sure you're not thinking of interlaced GIF? That was used pretty widely for images in the days when the processing for jpeg could actually be serious work for a pc.
- flukus 9y agoPossibly, I just remember being a grateful teenager when my adult images loaded progressively. Wouldn't gif have been a poor format for that even with progressive loading?
- fencepost 9y agoProbably, but the last time I really cared about load times enough that interlacing or progressive downloading was an issue would have been back in the early 90s on dialup and well before progressive JPEG was even a thing. IIRC, watching a JPEG paint on a 386/25 or maybe an early 486 was something that could likely be measured in full seconds or tens of seconds, not tenths of seconds.
- ClassyJacket 9y agoProgressive JPEG is a thing and was widely used in the 90s and early 2000s. Remember when images would load all pixellated at first, and then appear clearly? https://www.thewebmaster.com/dev/2016/feb/10/how-progressive-jpegs-can-speed-up-your-website/ https://www.thewebmaster.com/dev/2016/feb/10/how-progressive...
- masklinn 9y ago> Are you sure you're not thinking of interlaced GIF? Yes, interlaced JPEG has that property: each "pass" in the file adds detail, you can stop at any point. They're more expensive to process but compress better than non-progressive JPEG. PNG also has an interlaced mode, however it compresses less well than non-interlaced. Because of the way jpeg works, it also looks better early on, especially when the PNG renderer does no interpolation on the early interlacing phases. Interlaced GIF is actually pretty crappy as it's one-dimensional, so it has a "blinds" effect both during initial rendering and during refresh phases: https://nuwen.net/png.html https://nuwen.net/png.html
- TazeTSchnitzel 9y agoRemember JPEG 2000 and its wavelets? Second Life uses it ubiquitously, its progressive loading of textures is distinctive.