Live data from Hacker News

Free Lossless Image Format

flif.info

311–320 of 374 posts

Re: Free Lossless Image Format

#311
post #245

Earlier quoted context omitted.

BSD/MIT, or ASL2 are pretty much the standard if you want to see something as widely used as possible, which this sounds like might be the case. Cool work in any case! One thing the page could use is "how much processing power does this use, compared to other things?"

Yeah, GPLv3 AND LGPLv3 are the kiss of death for any corporate use. The patent clause in GPLv3 makes it legally impossible [1] to be used by any corporation that licenses patents; it's a completely broken clause, and GPLv3 should be banished. Without a BSD/MIT/ASL2 license as an option, you'll never see this in Internet Explorer or Chrome. Probably not even Firefox. [1] Companies license patents in bulk from other co…

You are wrong, and a drama queen.

The only thing (L)GPLv3 patent clause obliges propagators to do (ie not mere users; not even mere modifiers) is to grant their users licenses to applicable patents which they own. The permissive Apache license v2 demands from contributors the very same. It is the software patents that should be "banished", not freedom preserving licenses.

TL;DR: (L)GPLv3 prevents patent trolling through free software.

Disclaimer: This is not to be treated as legal advice.

Re: Free Lossless Image Format

#312

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…

I, for one, applaud your license choice. Please also see my reply to SomeCallMeTim.

Re: Free Lossless Image Format

#313
post #130
post #119

Earlier quoted context omitted.

JPEG has something cooler, you can first load a black-white smaller picture, then load more color and more detail.

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.

I mean like this

http://storage.googleapis.com/marc-pres/boston-event-1012/im...

Re: Free Lossless Image Format

#314
post #261
post #132

Earlier quoted context omitted.

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

Part of the beauty of FLIF is that there are no dedicated thumbnails, though.

As long as you don't directly work with FLIF, cause tools don't support it, having the file browser's preview-feature work using FLIF would be awesome. This way it doesn't need to store n previews for the supported preview resolutions but could store just a flif of the max preview size per document (psd, jpg, png, svg, pdf) and then, when you seek 3 pages down, the system reads the first kB of each such preview to render it and reads the next kB to improve the images, etc.

Sure, for actual flif files you would not have a separate preview file.

Re: Free Lossless Image Format

#315

BE SKEPTICAL! Not a single mention of "signal to noise ratio" (SNR). If you are going to list compression rates you have to give the associated quality -- SNR is used in the literature. I was suckered into "fractal image compression" by those selling the snake oil back in the 90's -- I am far more skeptical about these things now.

could you go into detail about what you mean with "associated quality"? These are lossless compression algorithms that are being compared here. The only other pertinent details regarding a lossless compression algorithm are the Compression Ratio, CPU usage, and Memory usage.

Because I am an idiot. Disregard. Move along.

Re: Free Lossless Image Format

#316
post #84

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…

> Sharing code is no longer cool if people have to share back. Or at least so it seems. There are plenty of licenses which require/encourage that. The problem with GPL is that everything that touches the GPL code has to become GPL or compatible. Adobe for example will never put this in Photoshop, or Microsoft in Internet Explorer, as they do not want to GPL their software. Net result is no wide support for this image…

You're not quite right. Everything that touches the GPL code has to become GPL, period. GPL compatibility only exists in one direction. A license is compatible if it is relicensable as GPL, the GPL itself isn't compatible with anything.

Rant: I really want to like the GPL, but this requirement is downright hostile towards other open source licenses. And in my opinion it's not even necessary for the GPL's mission. Surely, it would be enough to require that all other parts of the combined work must also be distributed under open source licenses, not necessarily the entire GPL. Some parts of the GPL, like the installation instruction requirement and the anti-tivoization clause, should apply anyway if only some parts are GPL'd, and the reduced protection would easily be outweighed by a strengthened open source community.

Re: Free Lossless Image Format

#317
post #254

Earlier quoted context omitted.

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.

Nah, it's the camera makers that are holding things back by sticking to proprietary formats and in some cases obfuscating them. There's OpenEXR, HDR, and DNG (the last of which is a true RAW format). The big issue with creating a true interchange format is that RAW files don't have proper color information for all pixels (they instead have red, green, or blue data for any given pixel, sometimes deliberately blurred, etc.) and interpolating the values to produce reasonably nice faux color for each pixel is actually very hard and the algorithms the different companies use is presumably protected by patents.

Re: Free Lossless Image Format

#318
For all the GPL-hate in this thread: GPL protects this specific implementation and not the algorithm. Even if the authors released this under GPL, this would only be a minor nuisance to getting this unicorn into all kind of products via re-implementations of the same protocol.

Re: Free Lossless Image Format

#319
post #192

Earlier quoted context omitted.

No kidding. If you want an image format to become widely adopted and standardized, GPLing the code is a pretty bad idea.

Not just an image format, everything you want to become widely adopted and standardized should refrain from using the GPL, even the FSF[1] recommends using the Apache License in this specific case. Some libraries implement free standards that are competing against restricted standards, such as Ogg Vorbis (which competes against MP3 audio) and WebM (which competes against MPEG-4 video). For these projects, widespread…

Note that the Apache License isn't compatible with GPLv2. If you don't make use of any patents use BSD/MIT/ISC instead.

Sadly there isn't a real alternative permissive license with a patent clause. There is a license called COIL[1], but it hasn't seen much adoption yet.

[1] http://coil.apotheon.org/

Re: Free Lossless Image Format

#320
post #253
post #220

Earlier quoted context omitted.

The GPU!- skipping those pixels hurts the cache, even if swizzled :) And my eyes - shimmering car grills and garden fences begone!

Wow, okay, this comment and its parent lost me :)

Rough context: When the GPU (or the CPU back in the days) had to draw a texture, it had to sample pixels, maybe one, maybe four and do some say bi-linear filtering in between them, and then use that pixel as a result.

Now several problems:

1. If your texture is sampled roughly one pixel from it to one pixel on the screen, and if all pixels are read linearly ("horizontally"), then you are good with the cache, cause for the first pixel you've read the cache maybe cold at that address, but it'll load the next pixels just in case you need them, and here is the catch - you need to get always benefit from that - it's like always using your coupons, and deals, and your employer perks. So the CPU/GPU might read 4, 8, 16 who really knows (but you) bytes in advance, or around that pixel.

2. But then you turn the texture 90 degrees, and suddenly it's much slower. You draw a pixel from the texture, but then the next pixel is 256, 512, or more away ("vertically), and then next too, your cache line of 4, 8, 16, 32 or 64 read bytes that you did not used, and by the time you might need them again, the cache discarded them. Hence the slowness now - much much slower!

4. To fix it, you come up with "swizzling" - e.g. instead of the texture being purely scan-line by scan-line, you kind of split your image in blocks - maybe 8x8 tiles, or 32x32, and then make sure those tiles are linearly written one to each other. You can go even further, but the idea is that under any angle, if you decide to read, you most likely would hit pixels from the same cache line you've read before. It's not that simple, and my explantation is poor, but here is someone who can do that better than me: https://fgiesen.wordpress.com/2011/01/17/texture-tiling-and-...

8. But even with swizzling, tiling, whatever you call that magic to keep pixels together in any direction really together stops working as soon as you have to draw that big texture/image on a much smaller scale.

16. Say 256x256 would have to be drawn as 16x16 - And you say I don't need mipmapping, I don't need smaller versions of my image, I can just use my own image - well then nomatter how you swizzle/tile, you'll be skipping a lot of pixels - hop from here to there, and lost cache lines.

32. For that reasons mipmaps are here to help, but stay with me for one more minute - and see how they almost fix the shimmering problem of textures with "fences", "grills on a car", a pet's cage, or something like it.

64. And when you hear the artist ready to put real spider-man logo on the character made out of real polygons, and real grill in front of the car, made out of real polygons, and real barbed-wired made out of polygons very nice looking fence - then stay away, as these polys woulds shimmer, no good level of detail can be done for them (it'll pop) and such things are just much easily done with textures and mipmaps - it kind of solves a lot of problems.

128. Read about impostor textures.

Post reply on HN