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

251–260 of 374 posts

Re: Free Lossless Image Format

#251

Post by andruby »

jonsneyers wrote: post #232

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…

It would be useful if the metadata would include hints for responsive downloads. Eg: For 1/4 resolution download the first 10,000 bytes, for 1/2 resolution download the first 25,000 bytes.

Re: Free Lossless Image Format

#252

Post by radarsat1 »

hansjorg wrote: post #115
colanderman wrote: post #92

Earlier quoted context omitted.

Progressive JPEG has supported this for decades. Anyone over 25 should remember them from dial-up years.

I think the suggestion is that the client could just stop downloading at a set threshold, maybe taking current bandwidth, cost, etc. into consideration. Judging from the video, something like that could work very well (and much better than with progressive jpegs).

But how is that different from progressive JPEG?

Re: Free Lossless Image Format

#254

Post by alanh »

jonsneyers wrote: post #246
bhouston wrote: post #237

Earlier quoted context omitted.

Very neat stuff. Would be nice to support 16/32bit floating point for true HDR as well if can be easily accommodated.

Can be done. Basically just change the type of ColorVal and implement a float variant of writer() and reader() in maniac/symbol.h.

I want to chime in to say that the lack of a common image format (and displays, for that matter) with true support for high-range photos is really holding back digital photography in my humble opinion.

Re: Free Lossless Image Format

#255

Post by mzs »

theoh wrote: post #178
mzs wrote: post #169

Earlier quoted context omitted.

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...

Here's the Mandrill test image from SIPI and Utah as a 75% progressive JPEG with just the first scan of the most significant bit of just the DC for Y only, which is a totally expected scheme for the web back in the '90s:

https://lh3.googleusercontent.com/-4tX6mfFoY4c/Vg7bg85RwcI/A...

Re: Free Lossless Image Format

#256

Post by magicalist »

jo909 wrote: post #155
panzi wrote: post #132

Earlier quoted context omitted.

I think some formats already support embedded thumbnails. (EXIF metadata can contain thumbnails, I believe)

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.

Re: Free Lossless Image Format

#257

Post by magicalist »

hansjorg wrote: post #238
guelo wrote: post #207

Earlier quoted context omitted.

It's an interesting concept. But I'm not sure how it could work. Resizing introduces artifacts so best quality is always going to be achieved by reencoding for different resolutions. Also, how would the client know when to stop downloading?

You'd need to set the thresholds in the file manually, based on the artists judgement of quality. It would take a few extra seconds when creating it, but could save both bandwidth and create a better user experience on mobile.

This will have to be automated or it's going to be really annoying for development. To eliminate that, maybe the file format could incorporate some internal tags for good size thresholds, or even just a handful of coefficients at the beginning for a simple curve approximating the byte-to-resolution mapping.

Re: Free Lossless Image Format

#258

Post by hyperion2010 »

spullara wrote: post #188

One of the least interesting parts of this is that it is GPL. Someone should reimplement it with a BSD license so it can be used more widely. AFAIK & IANAL, but I don't think you could integrate this with FF, Chrome, Safari or IE.

I understand the sentiment behind wanting to GPL projects and I would myself if it didn't lower even further the already infinitesimal possibility of someone reusing my code.

Re: Free Lossless Image Format

#259

Post by iopq »

guelo wrote: post #240
iopq wrote: post #235

Earlier quoted context omitted.

The client would download the first 1KB for an icon, 4K for a thumbnail and the whole image for the full size. The best part is that all of those are actually the same file, not separate embedded thumbnails inside the file. The client could decide BY ITSELF to download only 2K for a thumbnail because it's currently on 3g.

Where are you getting 1KB and 4KB from? The compression is highly dependent on the image so there's no way to know the quality of the thumbnail image.

Maybe a future version of the format would specify useful cut-off points for browsers to make the decision inside the header. Then the browser can decide to download 4K version on wifi and 1K version on 3g.

Re: Free Lossless Image Format

#260

Post by thaumasiotes »

jonsneyers wrote: post #232

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?

Post reply on HN