Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Free Lossless Image Format

flif.info

Post reply on HN
Print view View original

171–180 of 374 posts

Re: Free Lossless Image Format

#171

Post by logfromblammo »

russnewcomer wrote: post #73

I don't see any comparison here on the impact of decompressing? Is this going to hit a processor harder than JPG/PNG/BPG/et al will, and thus be a hit to people on mobile devices?

Processor and storage are much cheaper than network bandwidth this year.

The most relevant tradeoff calculation now would probably be bandwidth versus battery power consumption.

The FLIF image decoding library might want to be battery-aware, such that it can automatically scale back the power consumption at lower battery charge levels, in a user-configurable fashion. Or perhaps it caches a fully decompressed or partially decompressed file to storage, so that it only does the battery-devouring steps once.

Re: Free Lossless Image Format

#172

Post by mthoms »

colanderman wrote: post #166
jessaustin wrote: post #154

Earlier quoted context omitted.

However jpeg is lossy.

So is a FLIF that you only download half of.

If compared to the original yes, but that's apples to oranges. They are different resolutions.

It'd be more accurate to compare it to a pre-generated resizing of the original image (at the same effective resolution as the "half downloaded" FLIF).

Re: Free Lossless Image Format

#173

Post by kazinator »

robert_foss wrote: post #165
pierrebai wrote: post #129

Earlier quoted context omitted.

It's not about being apologetic or anti-freedom, it's all about the reality of software. If it gets reimplemented with a more libral license, then the more liberal version will dominate. If there is any incompatibility whatsoever, the more liberally licensed version will win. Look at gcc for an example: it has gcc-specific extensions and there are other compilers with more open license. These compilers are gaining th…

GCC has been around for 30 years. Only in the past 5 years has LLVM been around, and LLVM really is the only compiler to ever have matched GCC. The value GCC has provided to the software community in large is immense. Do you think it would have survived this far if it had been MIT-licensed all along? To support this argument, I'd like you to think about all the other compilers that never had a 10th of the traction of…

Unfortunately, a sample of one isn't statistically significant. That a GPL-licensed compiler suite is overwhelmingly popular rather than an MIT- or BSD-licensed one could be little more than a historic accident.

BSD Unixes are BSD-licensed and have "survived this far".

The SBCL implementation of Common Lisp is licensed as a "a mixture of BSD-style .. and public domain" [source: http://www.sbcl.org/history.html] It is a popular CL implementation.

GNU Common Lisp [https://en.wikipedia.org/wiki/GNU_Common_Lisp], the GNU Project's Common Lisp implementation, is LGPL-ed and has been a floundering project.

The choice of license cannot be the determiner of what propels a project to the forefront of popularity in its class, because ... there are many more projects than licenses.

https://en.wikipedia.org/wiki/Pigeonhole_principle

Re: Free Lossless Image Format

#174

Post by omribahumi »

GhotiFish wrote: post #143
versteegen wrote: post #21

Earlier quoted context omitted.

Great, thanks. It seems there is no technical description available anywhere beyond what you quoted. They haven't written it up, and I couldn't even find comments in the source providing details. That's too bad, but he (I assume that's Jon Sneyers) does say he hopes to write it up later. Also, comments in that thread on speed [1]: In terms of encode/decode speed: both are slow and not very optimized at the moment (no…

awesome, thanks for the info! if flif does ultimately consume more CPU resources then that is a trade off I'm perfectly happy to make, I'd rather burn CPU than my heinously bandwidth capped internet.

Here in Israel, bandwidth cap is big for a cheap price - I'm paying around 13USD/month for a package including unlimited voice calls, unlimited SMS and a 3GBs data plan.

What interests me most is battery life - is more CPU and less radio power better?

Re: Free Lossless Image Format

#175

Post by jwr »

versteegen wrote: post #77
josteink wrote: post #71

Earlier quoted context omitted.

Sharing code is no longer cool if people have to share back. Or at least so it seems. The GPL-hate in here really is quite immense, even though time and time again, RMS has been shown to be right about his stance on freedom. Should we attribute it to people's desire for a quick ("free") fix over long term considerations? It's hard to tell, but I suspect the silicon valley influence here doesn't help. There everyone w…

As someone who made a negative comment about the GPL elsewhere in this thread, I think I'll comment. I have absolutely nothing against the GPL, and use it myself. However, using the GPL for a library seems like a bad idea, because there are a lot of people, especially at companies, which won't touch the GPL. So if you license a library GPL and it's useful someone is just going to come along and reimplement it with a…

> there are a lot of people, especially at companies, which won't touch the GPL

Exactly. And for reasons which not everyone is aware of, for example anti-patent clauses.

What people classify as "GPL-hate" is often a very pragmatic approach. I've seen this a number of times: companies have nothing against sharing improvements to the code, but do have a problem with a) having to share everything they wrote and b) anti-patent clauses which are landmines. And at companies I worked with, (b) was actually the bigger issue, especially if you build and distribute physical devices with software.

Re: Free Lossless Image Format

#176

Post by acdha »

rplnt wrote: post #75
iraphael wrote: post #23

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…

This would be great. A lot of "responsive" sites nowadays use only one image as well, the highest resolution available. So you are downloading that 4K jpeg whether you are on mobile or on a desktop.

Your example also shows why it needs to be left up to the browser: downloading a large JPEG makes more sense on an iPhone 6S+ with a 1080p display and LTE than the 1024x768 computers at the local school sharing a basic cable modem.

The part which would really make sense for this would be something like an extension to or which would allow you to provide the byte ranges for each resolution so the client could issue a standard HTTP range request for the level of pixels it actually needs. You'd still have one file to manage and CDNs could cache it intelligently rather than lowering hit rates by caching different versions.

Re: Free Lossless Image Format

#177

Post by mzs »

espadrine wrote: post #68
linkydinkandyou wrote: post #47

Earlier quoted context omitted.

JPEG 2000 has that same feature. FLIF claims it will beat the lossless compression ratio of JPEG 2000

It also claims to beat the lossy version, which cannot even be encoded for the transparent fish image at the tested file sizes: http://flif.info/example.php [ed. image size → file size to emphasize that they had a target byte count for the purpose of comparison]

One interesting thing from that page is that GIF89a allows interlacing. So it really can be that some combo every eighth line is displayed very early on. Moreover there is a notion of image blocks, so for that particular image taking 64x64 blocks for example you could first encode the fishy portions. Also if you used 16x16 blocks you could have true color, though it would be very large, though there would be some improvement running through gzip over http.

Re: Free Lossless Image Format

#178

Post by theoh »

mzs wrote: post #169
theoh wrote: post #130

Earlier quoted context omitted.

Thinking back to the old days, are you sure the black and white image you have in mind didn't come from the "lowsrc" attribute of an img tag? Progressive jpeg is typically full colour from the start, and it does offer the progressive enhancement of resolution that you mention.

It depends on the encoder, it very well could be the first pass is just Y.

I'd call that "grayscale" rather than black and white, but interesting suggestion. I've never seen it done but looks like all sorts of things are possible: http://hodapple.com/blag/2011/11/24/obscure-features-of-jpeg...

Re: Free Lossless Image Format

#180

Post by kazinator »

bdisraeli wrote: post #89
versteegen wrote: post #77

Earlier quoted context omitted.

As someone who made a negative comment about the GPL elsewhere in this thread, I think I'll comment. I have absolutely nothing against the GPL, and use it myself. However, using the GPL for a library seems like a bad idea, because there are a lot of people, especially at companies, which won't touch the GPL. So if you license a library GPL and it's useful someone is just going to come along and reimplement it with a…

If companies don't want to use code licensed under the GPL, they're probably welcome to pay the original the author for a separate license.

But that unfortunately erodes the free-as-in-beer advantage, since in this situation the software is effectively proprietary, and competes with proprietary code on an equal footing: bang for the buck.

"If we're going to pay to license freeware code as proprietary, let's look at all proprietary alternatives."

Post reply on HN