Free Lossless Image Format
flif.info
flif.info
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 it down with html.
edit: more info on the responsive side of FLIF: http://flif.info/responsive.php
(Converting JPEG images to progressive format is one of the optimizations mod_pagespeed makes.)
FLIF claims it will beat the lossless compression ratio of JPEG 2000
[ed. image size → file size to emphasize that they had a target byte count for the purpose of comparison]
Edit: I was confused since with most coders you can specify precise mean squared error optimal truncation points (called quality layers) and it should have been very easy to obtain a stream of any particular file size.
Looks better than anything else but BPG at that size, to me, although FLIF obviously isn't optimized for lossy.
Judging from the video, something like that could work very well (and much better than with progressive jpegs).
The client could decide BY ITSELF to download only 2K for a thumbnail because it's currently on 3g.
It would take a few extra seconds when creating it, but could save both bandwidth and create a better user experience on mobile.
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).
Though I'll gladly take your logic and call the first 1/64th of a progressive JPEG lossess (which it is, since at that point you only have the DC offsets of basic blocks, which undergo no lossy compression).
The part which would really make sense for this would be something like an extension to <picture> or <img srcset> 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.
https://lh3.googleusercontent.com/-4tX6mfFoY4c/Vg7bg85RwcI/A...
It's been a long time but I think what I ended-up with was first scan MSB of Y DC, next six bits of Y AC. Then MSB of Cb and Cr DC, then a scan with a few bits of Cb and Cr DC and AC and finally the rest. The idea was that for a B&W, greyscale, or color thumbnail the same JPEG would be used but only the first N scans sent followed by 0xffd9 with a width and height in the img tag. Anyway, I can't be the only one that figured-out in the days of SLIP over modems that doing this trick was a good idea.
http://storage.googleapis.com/marc-pres/boston-event-1012/im...
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.
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 to enhance the thumbnail.
In practice, the simplistic resampling is not likely to be an issue -- of course you can create a malicious image which is white on the even rows and black on the odd rows, and then all previews would be black while they should be grey. But most of the actual images are not like that -- e.g. photographs. You can just decode at somewhat higher resolution and scale down from that. (You have to start from a power-of-two scaled image anyway.) Also note that Y is emitted at more detail earlier than chroma, so most of the error will be in those less important chroma channels. Other than that it's just Adam7 interlacing, but with no upper bound on the number of passes (so you could call it Adam-infinity interlacing).
Sure, for actual flif files you would not have a separate preview file.
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.
And my eyes - shimmering car grills and garden fences begone!
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.
The PNG and GIF comparisons are unfair; they're the same low resolution as FLIF, but given nearest-neighbor upsampling instead of bilinear. Most web browsers use bilinear or bicubic upsampling for progressive pictures now, so FLIF isn't nearly as unique as it presents itself. Aside from that, progressive is only useful if you're on a slow connection or the file is broken; in other cases re-rendering multiple times becomes a bottleneck and battery drain. In general it's rare that progressive decoding is a win anymore (although progressive encoding of JPEG is always a win).
In another comment I pointed out that jpeg2000 can be encoded to any size, even 1k, even though the q-scale doesn't go that low, by using the target size parameter instead. It looks better than anything but BPG and is fully progressive. Of course, J2K is a dead format outside of DejaVu, PDF, and the medical field, but it serves as a useful baseline.
A comparison to JXR would have been nice; it's an open, patent-indemnified format that fully supports progressive decoding, and compresses about as well as WebP. That format's the biggest disappointment for me, I thought it had everything in place to displace JPEG.
BPG could be made somewhat progressive, but only by changing the underlying HEVC bitstream, while one of its goals is to stay as close as possible. The inclusion of a thumbnail is the only recourse.
But it's not just the interpolation that makes a difference: PNG interlaces full RGB pixels (all 3 channels at the same time), while FLIF gives priority to luma so you get a chroma subsampling effect on partial files. Also GIF only has vertical interlacing and PNG only does 7 passes of 2D interlacing, which means that for huge images, the first pass can still take a while.
Another point: I am proposing to use progressive decoding to avoid having to download the full lossless image (so a browser supporting FLIF would need some mechanism to stop downloading the image file when "enough" detail is available). Repeated re-rendering is not necessary. E.g. on a mobile phone you would rather just download some prefix of the file (the size of the prefix could depend on the available bandwidth) and render it once, at least until the user zooms in on the image, or saves or prints it or something -- then the download should be resumed in order to load more/all detail.
And of course I'm planning to describe the algorithms and the exact file format in a detailed and public specification, which should be accurate enough to allow anyone to write their own FLIF implementation.
Cool work in any case!
One thing the page could use is "how much processing power does this use, compared to other things?"
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 companies for their own use all the time. They don't have the right to sublicense those patents to others; they're just protected against any lawsuits relevant to the use of the ideas in those patents. Yet GPLv3 requires that they provide a free license to any patent that they have a license to that might be required to use GPLv3 source code. So it's requiring them to do something they legally can't do. Selecting GPLv3 means that no large company will ever touch it as a result.
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.
Doesn't matter what you or I think of software patents (yes, they should be banned). Doesn't matter what you or I think GPLv3 says.
The lawyers at big companies see it as a problem, so it's a problem. End of discussion. No drama required; it's just the fact that big companies avoid using anything cursed with GPLv3.
Note that what you've argued before was very different from what you're saying now. You've narrowed the scope of the discussion (leaving out LGPL), but also its very nature ("legally impossible [1]", eh?).
Anyway, companies do use software licensed under both licenses, and even incorporate them into their services - hence the need for AGPL. Maybe others wouldn't see GPLv3 as that much of a problem if people didn't spread FUD about its supposed "curse" ("no drama required" but you couldn't help it, huh?). And if they didn't defend harmful practices, like Linus does tivoisation.
But mostly what companies avoid is copyleft, because it mandates reciprocity and prevents leeching the community. For projects such as these, LGPL is an acceptable compromise. The only valid argument against it is that apps under incompatible licenses will not be able to use it where dynamic linking is barred, and such is the requirement for apps in the Apple's store. However, in this particular case, that wouldn't be a problem either if the platform itself provided a decoder, like iOS does for PNGs.
I have read the license. I'm like that.
And it still doesn't matter.
It's what the lawyers think. And they say it's verboten.
* You are lying that you read the license.
* You were lying about what the license says.
* You really dont want to admit that you have misunderstood the license.
Either way, you were wrong then and you are wrong now about what the lawyers think. Speaking of which, there are only a few possibilities here as well, only these are not mutually exclusive:
* You are intentionally dishonest because you have an agenda
* You are dishonest just to cover your behind
* You are genuinely careless about what you say
Even if we change the word 'think' for 'say', it's still a gross overgeneralization.
So all things considered, in the best case scenario, you refuse to admit when you are wrong, and will continue overgeneralizing. Forgive me, but it's really not worth the effort arguing under these circumstances. If you wanted to continue, you would have to make some concessions, but I doubt you will, so in all probability: Goodbye.
I was reporting what I was told by corporate lawyers. My own reading of the patent section does happen to side with the lawyers' reading: That if you distribute an app that's protected by a patent you own a license to, that you need to arrange a sublicense for all users of that software. Maybe not technically "impossible," but I didn't count "spending millions of dollars to fix the problem" among the likely corporate responses when I said "impossible." Especially when most GPLv3 code can be written from scratch for less than the cost to license patents.
Someone alleged Blizzard uses it; fine, their lawyers either disagree, weren't consulted, or are being ignored, but Blizzard doesn't make Chrome, Firefox, or Internet Explorer, so the point is moot if you care about web adoption, which would make the format relevant to anyone but a game developer.
What matters is what the lawyers for the big companies that control Chrome and IE won't let GPLv3 code into the code base. Many other big company lawyers take the same position (probably all companies above some size threshold), and that's all I've been alleging from the start. Criticize my delivery all you want, but that's what I was trying to say.
My agenda is to get the developers to change to a license that could actually be adopted into a web standard. Since you're refusing to actually read what I'm saying, I agree: Goodbye.
Companies wouldn't adopt things under "GPLv3", but they wouldn't a permit GPLv2 either. Or LPGL. Or Apache 2. Or MIT, or BSD, or any license. They permit nothing short of contributors assigning them copyright and the patents, just them (see eg. Webkit's and Chromium's copyright notices and CLAs). And yet, libpng is under a license. So yeah, I agree they'd write their own library - out of their selfishness. Let them.
With the "adopting a web standard" thing you're attempting to further move goal posts. But you fail, and not because your implication that standard bodies would accept permissive licenses is wrong - which it is, because they're exclusively public domain + patent clause (oh and the people building browsers still contribute somehow). You fail because you're mixing apples and oranges again; programs are not parts of standards. Standards describe file formats, and prescribe behavior of programs that process them. They are not concerned with implementations' licenses.
The spec can become a public domain standard, and all would still be well with the library under (L)GPLv3+. Free software should have the edge.
If they are using LGPLv3 libraries, then presumably their lawyers are OK with it, or they failed to run it past legal. Regardless, it's completely irrelevant to my point what Blizzard uses or doesn't use.
If you want to see a lossless compression format on the Web, you need the format to be picked up by, at a minimum, Google and Microsoft, the owners of the two top browsers in the world today.
Firefox would also be important, but would certainly follow if Google and Microsoft stepped up to support it. So really it only matters what Google and Microsoft think. If it's a license that they can freely use, then there's a chance it becomes a new Web standard. If it's only available LGPLv3, then Microsoft and Google would need to buy LGPLv3 exceptions in order to use it. A much bigger barrier to entry, and at least Google might object based on the concept that Web standards should be open. Mozilla would certainly resist if they weren't open -- though they eventually caved on H.264.
If you want to see adoption where it counts, you need cooperation from the companies behind the browsers with the market share.
No one is expecting Starcraft 2 to be the next big Web plug-in, so it's irrelevant to the product that they have LGPLv3 code in it (if they do). And if they do, Blizzard better hope that their lawyers are right in their interpretation of GPLv3, and that no one sues them hoping to take home a share of the profits you've pointed out that they are rolling in by forcing them to buy a license to get around the GPLv3 restrictions that they may or may not be violating. That's an expensive lawsuit even if they win.
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.
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.
"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+"
Basically anything copyleft is going to have a really big dropoff in use compared to say BSD, MIT or Apache 2.0.
A key attribute for companies in a heavy competitive market is that they have to use every tool available to get the best product out in least amount of development time. If a company decided to avoid a license just because of religious reasons, 10 other companies will jump into its place and out compete them.
A good example of this is when we see companies reaches out to developers directly to get permission, as the time to do that is worth compared to having developers spend time on unnecessary code. Large AAA games can easily have a long credit list of every license available that can be used in a proprietary product, including LGPLv3.
Yes, some platform holders will use it themselves, but that is not their preference. Ultimately, image encoding and decoding is a crowded market with many alternatives and I strongly believe that a copyleft-licensed component will always be passed over in favor of alternatives unless it is overwheingly compelling and a viable option.
Some companies explicitly prphibit the use of any copyleft licensed software in their development.
Certain conditions of the GPL and LGPL are impossible to fulfill on some platforms.
With that in mind, I feel like my assertions remain reasonable.
That's only guaranteed if you obtain copyright assignment from any contributors now. Otherwise, re-licensing will be a massive headache as you'll need to track down all the copyright holders for permission. Some might refuse or have have dropped off the map.
I think the concerns about the licensing are a bit premature - honestly, this is currently a research project, not a practical replacement for existing image formats. The licensing is only one of several impediments to adoption.
- The format has no spec
- The format may change, rendering all previous images unreadable
- The format has no javascript implementation, and no way of running on old browsers.
- As far as I can tell, there hasn't been a patent search done to see if it violates other patents from other organizations. For example, this one: http://www.google.com/patents/US7982641
- No peer-reviewed paper published yet?
However that doesn't mean that we can't recognize the accomplishment - this looks like a very promising research result, and I hope the project continues! Good work Jon!
While there's no paper there's a full Github repo which I'd actually say is quite impressive.
https://boards.openpandora.org/topic/18485-free-lossless-ima...
- for interlacing it uses a generalization of PNG's Adam7; unlike PNG, the geometry of the 2D interlacing is exploited heavily to get better pixel estimation, which means the overhead of interlacing is small (vs simple scanline encoding, which has the benefit of locality so usually compresses better)
- the colorspace is a lossless simplified variant of YIQ, alpha and Y channel are encoded first, chroma channels later
- the real innovation is in the way the contexts are defined for the arithmetic coding: during encoding, a decision tree is constructed (a description of which is encoded in the compressed stream) which is a way to dynamically adapt the CABAC contexts to the specific encoded image. We have called this method "MANIAC", which is a backronym for "Meta-Adaptive Near-zero Integer Arithmetic Coding".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 assembler code etc, just C++ code). A median file
took 3 seconds to encode (1 second for a p25 file, 6 seconds for a p75
file), which is slower than most other algorithms: WebP took slightly
less than a second for a median file (0.5s for p25, 2s for p75), PNG
and JPEG2000 took about half a second. It's not that bad though: BPG
took 9 seconds on a median file (2.5s for p25, 25s for p75), and
brute-force pngcrushing took something like 15 seconds on a median
file (6s for p25, over 30s for p75), so at least it's already better
than that.
Decode speed to restore the full lossless image and write it as a png
is not so good: about 0.75s for a median file, 0.25s for a p25 file,
1.5s for a p75 file. That's roughly 3 to 5 times slower than the other
algorithms. However, decoding a partial (lossy) file is much faster
than decoding everything, so in a progressive decoding scenario, the
difference would not be huge.
What interests me most is battery life - is more CPU and less radio power better?
It's a bit premature to discuss compression/decompression speed, because this is just a prototype implementation and there are probably many ways to improve the speed. Premature optimization is rarely a good idea.
Github repo here btw: https://github.com/jonsneyers/FLIF
The problem is more that Firefox / Chrome ship proprietary bits like the DRM modules that would violate the linking GPL coverage of flif. And that Chrome is proprietary.
Its going to need to be relicensed LGPL to be included.
Yes, it is compatible, the other way around. You can take BSD, MPL, MIT code and adopt it into a GPL project, not the other way around.
EDIT: Even LGPL won't work here as it will prevent use on Windows Phone, iOS and Android.
Possibly not coincidental, the latest LGPL version I could find in the 'legal' section is 2.1.
(1) they may be overly cautious, given that they mention the L4 kernel, lua, and Tiny Scheme.
LGPL code is everywhere in Android and iOS. There are numerous apps built on GStreamer for both platforms, which is LGPL.
I wouldn't be surprised if Microsoft pulled the pig-headed move though.
You're not going to find LGPLv2.1 or LGPLv3 anywhere in them, however. Starting with LGPLv2.1 you are required to allow the end-user to replace a compiled binary you provided of the LPGL'ed component with their own, something that obviously cannot be guaranteed on any of the mobile platforms I listed.
I suppose I should have clarified the version, but it's important to note that the FSF has tried to pull the tivoization card with more than just v3 of their licenses.
Also, if it's a file format and not just a particular library, shouldn't it be possible to reimplement support for it under different licenses on different browsers?
Also, I'm not sure how far do you have to deviate from the original code to not be covered by its license.
This only works to avoid copyright infringement. Patent infringement cannot be avoided in this fashion.
Because multiple implementations are useful.
You see how unsupported WebP is at the moment. Simply having a better compression ratio isn't gonna cut it.
Almost, Stallman (well, the FSF) advocates Apache 2:
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 use of
the code is vital for advancing the cause of free software, and does more
good than a copyleft on the project's code would do.
In these special situations, we recommend the Apache License 2.0.
If this is worth using (and it's the first thing in several years that made me sit up and say 'ooOOoo') it won't get lost. There will be a way for the world to use it.
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 use of
the code is vital for advancing the cause of free software, and does more
good than a copyleft on the project's code would do.
In these special situations, we recommend the Apache License 2.0.
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.
If you're trying to drive widespread adoption of a competing file format, then don't GPL the only code that implements it. Make a brain-dead reference implementation with a license as unencumbered as you can stand. (Then code up an elegant implementation and GPL that.)
https://github.com/jonsneyers/FLIF/issues/3
The title incorrectly suggests Creative Commons (which is inappropriate for code), but the discussion does suggest better alternatives.
Realistically a basic rendering and conversion implementation should be at least Apache 2, or something even more permissive (MIT/BSD/ISC). It was my first thought/comment when I saw the GPLv3 notice... They should switch the license quickly if they want to see adoption/support. Getting a free standard in place is more important than using a copyleft license.
In principle, using the GPL license for the reference code is OK if his intent is to encourage other people to build more refined, practical, and performant implementations. But the real problem with his choice of license is that a lot of people can't even look at the code for fear of tainting themselves legally. Given that there is no desperate market demand for a better-PNG-than-PNG, it wasn't a good idea to handicap the proposed format by saddling it with various restrictions and legal minefields.
If the reference code is strictly of proof-of-concept quality, which it sounds like it is, then there was no reason not to use a more permissive license.
https://en.wikipedia.org/wiki/JPEG_2000#Progressive_transmis...
And the Digital Cinema formats widely used today rely on this so a 2K or 4K stream can be extracted from the same file.
What's "new" about FLIF is the better lossless compression rate
Here is a thorough analysis of how good that lossy image is: http://flif.info/example.php
It shows how very good lossy BPG is, but also how good FLIF is against anything but BPG (and against lossless BPG).
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 wants to take everyone else's hard work and code, build a weekend SaaS and get rich. The GPL, while not preventing that, is clearly in opposition to that goal.
The ideal of the GPL was that it would force other projects to switch to GPL, but it doesn't seem to happen too much in practice because the modern world has an abundance of alternative software for any task. Think long term: chances are someone in the next 50 years will be annoyed enough to reimplement whatever you're doing.
I don't agree with corporate apologeticism which seems to be the norm here. If a company wants get something for free, expecting it to publish source code changes is not an actually high threshold. It might be in terms of corporate politics, but in actuality it is not hard.
Obviously the issue is not about publishing changes to the library, it's about publishing the rest of the source which just uses the library as a building block.
I'd be willing to testify as a technical expert in a court of law that the GPL cannot reasonably rule out dynamic linking; that dynamic linking to a program is a form of use (like invoking a command line and passing it arguments) and not integration. The proof is that dynamically linked components can be replaced by clean-room substitutes which work exactly alike, or at least well enough so that the main software can function.
For example, a program can be shipped with a stub library which behaves like GNU Readline (but perhaps doesn't have all its features). The users themselves can replace that with a GNU Readline library. Thus, the program's vendor isn't even redistributing the GPL'ed component. They can provide it as a separate download or whatever. However, if they were to include a GNU Readline binary for the convenience of the users, then the program supposedly infringes. This is clearly nonsense.
You can also turn this around and ask if its legal to use process call within a other program without invoking the need for additional permissions. FSF view that it should be legal, but it has never been tested. By now however an industry standard has formed around the FSF guidelines and most courts would just look at it when deciding. This is what commonly happen when no one go to court to find out what the rules actually should be.
Yes, so obviously your argument cannot be that "in theory, we could replace this with a workalike".
You better have the workalike, and that's what you should be shipping.
A powerful argument that you aren't infringing is that your shipping media are completely devoid of the work.
> don't care if its use or integration
For the sake of the GPL, they must care in this case, because the GPL specifically abstains from dictating use; it governs redistribution!
The only parts of the license relevant to use are the disclaimers; the only reason a pure user of a GPL-ed program might want to read the license at all is to be informed that if the program causes loss of data (or whatever), the authors are not liable.
GPLed programs get used all the time. A proprietary app on a GNU/Linux system can use the C library function system() which might invoke /bin/sh that is GNU Bash, and even depend on that functionality.
> For example, if I buy a painting and cut it into pieces and rearrange them, I actually need an additional license beyond what I got from purchasing the copy.
But what if that cut-up never leaves my house?
Or what if I only distribute instructions which describe the geometry of some cuts which can be made to a painting, and the relocation of the pieces?
Maybe so, because the exclusive right is framed as a right "to prepare derivative works based upon the copyrighted work" (separate from reproduction, distribution, and other copyright rights).
I don't think I was infringing back in kindergarten when I cut up newspapers to make strips for papier-mâché. In any case, my courtroom argument there could be bolstered by the remark that the resulting work was painted, entirely concealing the original content.
And that according to FSF is legal because it do not create a derivative work. You said above that "GPL cannot reasonably rule out dynamic linking", but now you are picking and choosing which part of FSF interpretation of derivative is correct and which is wrong. I just wanted to point out that the law could have been easily interpreted in a different way if someone had challenged FSF interpretation 25 years ago.
> But what if that cut-up never leaves my house? Or what if I only distribute instructions
Again, the law is both clear and quite fuzzy at the same time. The author has the exclusive right to transform their work, and as such, you could get charged even if it never leaves your house. In EU its a bit different, since it talks about moral right which protect the integrity of the authors work, through the end result is likely to be the same in many cases.
As for just giving out instructions, the legal nature of those are extremely fuzzy. If I provide instructions that reproduce a copyrighted video (by compressing/encrypting the data that represent it), I will still run foul of copyright infringement. From what I have seen, courts tend to take a "common sense" approach to this problem and if the end result is an infringement, then the indirect steps that will cause an infringement becomes infringement too. Judges collectively seem to rule against people who they perceives as trying to bypass laws by technicalities.
I don't see how you perceive a position change here. The FSF considers dynamic linking to be derivative; I do not agree.
We both consider the invocation via command line not to be derivative.
> now you are picking and choosing which part of FSF interpretation of derivative is correct and which is wrong.
Have been all along. "Dynamic linking is derivative" is almost complete bullshit in my eyes.
It's pretty much pure use. We map this object into memory and then call it.
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 the upper-hand.
Making it GPL instead of LGPL is just a bad political choice. Especially for something which need wide adoption to even live. Image formats can only exist if they get adopted.
I do agree that the LGPL is a reasonable choice for prototype implementation of a specification. I don't think using the GPL is a huge loss compared to LGPL for a prototype.
I'd like to ask a non-rhetorical question; On an individual basis is it not better if all software was available as sourcecode?
And if so, does that not mean the choice of not-publishing sourcecode is done for other reasons than what's best for the individual(s)?
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.
Far as compilers, proprietary are winning out in terms of longevity, it's a select few proprietary vs GCC in terms of performance, GCC in uptake, LLVM with decent performance/uptake, and some others with intended academic uptake. So far, that's barely any GPL, one industrial BSD, quite a few academic (MIT/BSD licensed), and many proprietary. Apples to apples, GCC is barely special except in what it offers for free and how hard it is to extend. That's why LLVM was designed and why Apple built on it, among other companies and OSS-loving academics. After a mere market survey, GCC suddenly doesn't look amazing.
Now what's your thoughts on GPL getting the only development when I bring up Apache, BIND, FreeBSD, Sendmail, and so on? Plenty get development. Success stories, just like GPL, still have little to do with copyleft of the license and a lot to do with community or resources.
Where performance mattered we always used the commercial, proprietary, Intel compilers and/or the Microsoft compilers.
"If we're going to pay to license freeware code as proprietary, let's look at all proprietary alternatives."
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.
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 format, which is a net loss compared to a e.g. LGPL/MPL scenario where companies could do that but still would have to contribute to the library if they made any changes/improvements.
I mean, I get it if you'd like closed-source browsers to go away. You're entitled to that position. But that's not the effect that making this library GPL will have.
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.
> You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:
> c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
It really does not work like you would want it to. Technically, you only add the GPL, so the work will then be licensed under both licenses at once. But the GPL is so restrictive that this doesn't make much difference in practice beyond maybe retaining the original license text.
The license talks about when the the entire work is being distributed. Individual parts licensed under a different license can be used in other works under completely different licenses and the GPL do not impact such use.
Say for example that you created some GCC code and put that under MIT. When distributing GCC, GCC as the "entire work" will be GPLv3 which also then apply to the MIT part. However, the MIT license will also apply to that part, must be kept in every copy, and you could take that MIT part and put that into LLVM and GPLv3 would not suddenly impact LLVM.
When modifying a GPLv3 project, your own additions can always be any GPLv3 compatible license (as I stated above). In most cases that would not make much sense but in a few cases, say in a compiler, it might make sense if you want to use that code in several project with different or even proprietary licenses. Nothing in GPLv3 prevents this.
> Sharing code is no longer cool if people have to share
> back. Or at least so it seems.
The GNU project has specifically commented on cases where using an more permissive license makes sense, one being to encourage the widespread use of a file format or standard.
I personally like copyleft quite a bit, but I don't think it makes sense for this particular case.
I'm fine with GPL for a LOT of things... For others I feel that MIT/BSD/ISC/Apache2, etc are better choices.
A software application that's GPL3, great... A library you want to see make it into diverse, embedded platforms, not so much.
Just imagine if SQLite was GPL-only, barely anybody would use it.
Better example would be libpng
The issue in this case is that image formats need widespread support to take off, and picking a license that is incompatible with 4/5 major browsers ensures that won't ever happen.
There are plenty of projects at these companies that would be unreasonable to open source - and due to frequent reuse of code within a company, GPL is an unreasonable license due to its ripple effect.
Contributing back to open source projects is the most enjoyable part of the process (Google for example, actively encourages this, and makes it incredibly easy).
GPL projects are dramatically reducing their pool of potential contributors. I'd love to contribute to them, but I can't.
For opensource applications, they're seeking widespread user adoption. To that end, they want to keep users & developers focused on a single project & codebase. Releasing under a license like the GPL ensures they can easily incorporate features from any knockoffs/forks... which pretty well ensures there won't be any longterm knockoffs/forks (unless the project is mismanaged).
GPL isn't so great for opensource libraries though. They don't care about users, they want widespread adoption by developers and their applications. Since applications may have all kinds of licensing requirements of their own (many of which can't mix with GPL), licensing a library under the GPL automatically limits the library's potential adoption.
Which is why LGPL makes a lot more sense for a library. It allows incorporation of forks, but at the same time allows widespread adoption of the library.
Of course, the BSD license almost makes great sense for a library, but mainly for ones which have little expectation that there will be significant enhancements made under closed-source forks; or ones whose purpose is to contribute a basic reference implementation for the greater good.
E.g. a BSD license works well for something like a reference PNG decoder, to encourage adoption of the format; but less sense for something like ffmpeg, where the project's survival depends on garnering as many contributions as possible from a limited base of coders (experts in the intricacies of video codecs).
Thus I think it's less hate, and more frustration that by using the wrong license, the project has hobbled itself at the start, which clack of contributor interest before the project even gets off the ground... and folks would like to see something (like) this succeed.
The tragedy is that there's already a decent license for this exact need:
http://www.gnu.org/licenses/lgpl.html
That would allow e.g. Firefox to use the format as long as they either did not modify it at all or were willing to relicense any changes they made to the image codec itself under the same license, which is a much more reasonable requirement.
This is important because adding a new image format is already expensive. Mike Shaver wrote a good comment explaining why Firefox never shipped JPEG 2000 support due to the expense of having a high-performance, reliable and secure implementation:
https://bugzilla.mozilla.org/show_bug.cgi?id=36351#c120
If you're adding to that already big cost the requirement that you override the project's decision about what license to use and go through and get permission from everyone who's ever provided a patch to relicense their code, it just doesn't seem likely to happen.
1. The GPL is incompatible with many other licenses, including free and open source licenses. Viral licenses do not play nice with one another. 2. For many people, the risk associated with the GPL death penalty is simply too high. Even the watered down GPLv3 version has some scary scenarios.
Aside from that, a lot of people simply aren't bothered by a proprietary fork of free or open source software with a permissive license. Keep in mind that permissive licenses or proprietary forks do not affect freedoms 0-3.
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
The JPEG image format also supports progressive images, in browsers today, and no one has figured out how to use that for single-file responsive images yet.
(You might be able to do something in HTTP/2 where you set the priority of the stream to 0 after you have enough of it for your needs, but I don't think anyone has gotten this working yet.)
<img src="foo.jpg">
<img src="foo.jpg"
bytes-1x="(H+N)"
bytes-2x="(H+N+M)" ...>
If we want something that can catch on, it needs to be something where browsers and servers can negotiate in a fully automated way. Or we can just use srcset/picture.
I will compare this using lodepng as a baseline and hope to report soon.
In other words, it's a lovely idea, but due to a poor choice of license, it won't get any adoption. C.f. Ogg Vorbis, where the license for the specification is public domain, and the license for the libraries are BSD-like.
To quote FSF:
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 use of the code is vital for advancing the cause of free software, and does more good than a copyleft on the project's code would do.[1]
[1] https://www.gnu.org/licenses/license-recommendations.html
UPDATE: See lt's helpful comment above.
So even if you stay strictly within the free software universe, even only within in GPL universe, a strong-copyleft license is a bad choice for a library.
Is that correct?
"In terms of licenses: GPL is all you get for now. I can always add more liberal licenses later. LGPL for a decoding library, or maybe even MIT? We'll see, I'm not in a hurry."
https://boards.openpandora.org/topic/18485-free-lossless-ima...
(Edit: As I clarified, I meant usable for adoption in other non-GPL projects. But OK, I deserve the downvotes for adding very little, and will think twice before posting such a reply next time)
Pure bullshit. Unusable for whom? Proprietary software developers? That's the intent.
Apple and Google won't touch GPLv3, so that means this image format is dead on arrival as a web format.
Sure you can use it locally to compress your photographs, cool. But it won't be a web standard with GPLv3.
Google is currently using webp everywhere, too, despite no major browser actually supporting webp.
(I do not consider Chrome a browser, but mal- and spyware)
But even the FSF recommend sometimes using don't-care-about-user-freedom licenses for strategic reasons, for example driving adoption of a new free codec...
Their reasons being things like added security risk, lack of demand, lack of support in other browsers, patent risk etc, which all apply just as much to this format.
If you want to use it commercially without publishing source, just buy a licence from the author. Buying licences isn't exactly uncommon. Or are OS X/iOS/Windows also unusable for you?
And the author delivered: With GPL3 source.
> Also commercial "standards" by one party are worthless
Very true, but I can't see how that applies to this project? First, the existence of this repository doesn't preclude proper standardization. Second, the reference implementation is freely licensed, not commercial.
The opposite, going from something like MIT or BSD doesn't require ANYONE to be okay with it, the license permits it.
My point was, if he had released his code as MIT/BSD and then wanted to change it to GPL it would be fairly ineffective -- people could still use the old MIT/BSD version in their proprietary products.
It is a lot easier to restrict now and liberalise later once more thought has been given to the options, than it is to draw things back in later if you decide you want more control for any reason.
Why not? As far as I know, GPL3 let you to dinamically link without having to open the source code the resulting software.
https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic
For but Apple it's not even a licensing concern. Apple doesn't have a problem with the GPLv2, but doesn't touch the GPLv3 because of the patent clauses that it contains. The bash in OS X is a version from 2007 because that's the last GPLv2 version of bash. But Apple has no problem including git because that's also GPLv2 and not v3.
It's not the patent clauses that are the issue: https://news.ycombinator.com/item?id=8868994
I wonder if they had a real legal person OK that claim.
For example, if commonly used libraries such as minified Javascript source files are encoded and distributed incrementally, we don't have to repetitively download various versions of the same library from different CDNs for different websites, which will save a huge amount of Web traffic.
BTW, credit to the flif people for linking competitor formats bpg and webP
More practically, since browsers won't have an flif decoder there isn't an easy way to embed the images online without reencoding them in a different format, which would rather defeat the purpose of putting up sample images.
>More practically, since browsers won't have an flif decoder there isn't an easy way to embed the images online without reencoding them in a different format, which would rather defeat the purpose of putting up sample images.
Did you follow the link I posted? I think Bellard put together a pretty nifty demo. Note: Bellard credits xiph.org as the originator of the demo page. http://people.xiph.org/~xiphmont/demo/daala/update1-tool2b.s...
Having a Youtube video already shows that it works really amazingly well (especially coming from Adam7), but seeing it interactively on a selection of images would be nice.
After all, the single biggest feature is that you can actually stop downloading the image whenever you feel like you don't want to spend more bandwidth!
That's good but does it actually avoid patent minefields that others scattered around? That's equally critical for healthy adoption.
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.
How many transistors would be needed for and encoder? How about a decoder or a codec (encoder/decoder)? And what about clock speed? How long is the longest pipeline in the codec?
For any other modern codec the hardware aspect is a very important one. Usecases like smartphone browsers or smartwatches are very common, and on platforms like that performance==battery life==usefulness.
Awesome! I have been toying with custom png 'container' ideas in the past offering similar 'responsive' features (i.e various resolutions, lossy-lossless versions)
I would like to see the ASM.js version of the decoder and see how that one performs.
"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. "
Which, IMO, is totally fine.
The patent issue is a major one and not lightly ignored. I haven't checked patent status, but one of the things that was pretty contentious with JPEG 2000 during the ISO standardization process was patents around arithmetic coding -- not just the method for doing the encoding, but also things like context based modeling.
In reality, the majority of image compression comes about in the "modeling" stage -- be it predictive coding, context based encoding coefficients, etc.
I'm happy to see new advances in image coding, but having spent many years working with Glen Langdon and others, the depth of IP concerns is still fairly fresh in my memory.
They specifically say that "FLIF is completely royalty-free and it is not encumbered by software patents". So, I suppose people will be allowed to develop their own libraries with another license.
FLIF is Free Software. It is released under the GNU General Public License (GPL) version 3 or any later version. That means you get the “four freedoms”:
The freedom to run the program, for any purpose.
The freedom to study how the program works, and adapt it to your needs.
The freedom to redistribute copies.
The freedom to improve the program, and release your improvements to the public, so that the whole community benefits.This is far from my area of expertise, but lawyers smarter than me about these things disagree.
1000? 1? 0?
Zero. You are about as likely to be tainted from reading GPL code as to be tainted by reading HN, the news paper, or driving around in silicon valley and looking at building with programmers in them.
Maybe you should look up what 'clean-room' reverse engineering is. One person looks at the code, writes down how what it does, then gives that description to another person who writes CLEAN-ROOM code based upon the description.
There's no difference in doing a clean-room implementation of GPLv3 code than of any other code license.
One can reasonably argue that this is stupid and not the fault of the GPL. However, it's also reality, and a real block to adoption of technologies like image formats.
Clean-room implementation has been around for ages, I've done it professionally myself, both from source code and disassembly.
Also not every company has clueless lawyers, nor does a clean-room re-implementation of this format need to come from a company, I'd say it's more likely not.
Seriously this sounds more like GPLv3 scaremongering than anything else, I've never seen anything like this in my professional life as a developer.
edit: as for my personal preference, I think GPL is a great license for full application/solution style software, but for libraries/frameworks, I prefer permissive licensing.
Even if someone wants to sue over it, I'd say that legal battle is worth fighting because this is similar to how FOSS makes stuff compatible with proprietary software/protocols: reverse engineering their function to make a separate, compatible implementation. Knowing how important that is, I doubt even the zealots would sue someone using above methodology knowing it could set a precedent which might be used against them.
> Devices based on Google's Android platform, as of version 5.0 "Lollipop", support the Opus codecs. Chromecast supports Opus decoding. Grandstream GXV3240 and GXV3275 video IP phones support Opus audio both for encoding and decoding.
Developers were Mozilla and Skype (MS after the purchase)
>Its main developers are Jean-Marc Valin (Xiph.Org, Octasic, Mozilla Corporation), Koen Vos (Skype), and Timothy B. Terriberry (Xiph.Org, Mozilla Corporation). Among others, Juin-Hwey (Raymond) Chen (Broadcom), Gregory Maxwell (Xiph.Org, Wikimedia), and Christopher Montgomery (Xiph.Org) were also involved.
Standardized
> https://tools.ietf.org/html/rfc6716
Still I think most people have no idea about Opus as a codex and only thing OGG (Container which Opus uses) and Vorbis codec format (Which Opus was to replace).
Decode speed to restore the full lossless image and write it as a png is not so good: about 0.75s for a median file, 0.25s for a p25 file, 1.5s for a p75 file. That's roughly 3 to 5 times slower than the other algorithms. However, decoding a partial (lossy) file is much faster than decoding everything, so in a progressive decoding scenario, the difference would not be huge.
There's still room for optimizing the encode/decode speed, but it's not very useful to do that before the bitstream is somewhat finalized. The prototype implementation I have now is not extremely fast, but at least it's in the right ballpark. Most likely even an optimized decoder will still be slower than an optimized PNG decoder, but the difference will be small enough to not matter much (certainly compared to the time won by downloading less bytes). comradekingu likes this
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.
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.
If so, it can also be a hacky video format.
EG: A flif would specify how many megabytes it used per second. There would not be discrete "frames".
If a video flif said that it used 1MB per Second, and you wanted to see what the video looked like at 10.8 seconds, you would download 10.8MB .
what does it mean that the FLIF lines suddenly get worse than PNG over on the right-hand side?
Another way to view the graph is: the area under the curve corresponds to the total disk space needed to store a large corpus of images in the given format. So obviously lower is better.
If the site doesn't want animations, it will only show the first frame. For example, try uploading an animated GIF to Facebook.
Likewise Brotli will not beat FLAC at compressing audio, since FLAC is specifically written to do that.
edit: went and did a test on a couple of tracks, using brotli: bro --quality 11 --window 24 against flac -8 (best settings in both cases)
satie - gymnopedie no 1:
wav: 41.6mb
brotli: 28.1mb
flac: 14.7mb
ram jam - black betty:
wav: 41.8
brotli: 35.8
flac: 26.5
vangelis - tao of love:
wav: 29.4
brotli: 23.0
flac: 13.4
meat load - paradise by the dashboard light:
wav: 89.3
brotli: 78.3
flac: 58.5
Reason: Category 'Newly Registered Websites'
i want to see it in my browser and websites, home some browser support come from chrome and firefox
No but I'm excited, this is progress!