FTA:
"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."
Perhaps the MANIAC/CABAC decoding or encoding is computationally more intensive compared to the others? Concerning lack of support, just like with the BPG decoder you could generate the Javascript through Emscripten so any javaszcript enabled browser can view them. Personally an even more efficient lossy image compressor would be great (getting my avatar down to 1K and still sharp). When using diagrams or text the mozjpeg artifact eraser is adequate.
Because it is GPL3, it won't be supported by Google on Android, by Apple probably anywhere, or by Microsoft anywhere.
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]
I would suggest that this is a case where widespread use is more important than copyleft.
So, the free world can use this library and the proprietary world will have to develop their own if they want to use the format. Proprietary software developers get to piggy back off of tons of free software, and then when someone decides that they don't want to enable that for their particular program/library, people complain about it. It makes no sense.
I think license depends on your goal. If your goal is to create a web image format.. you need all the browsers to agree to include you. All browsers will not add a GPLv3 image type. Therefore it is dead before it launched.
No, that's backwards. Microsoft and Apple and Google prevent the usage of the GPL/LGPL. Don't blame the GPL for the bad behavior of large corporations that are using their immense power to try to stop copyleft.
A while ago I wanted to include a library in some GPLv3 software, but I couldn't because that library was GPL2-only with no "or any later version" clause. And both versions of the GPL are not compatible unless the GPL2 software has this "or any later version" clause.
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.
That's only the implementation, not the image format itself. Unless I am mistaking, you can't apply a software license like GPL to an image format, just patent it.
You're correct. There is no copyright for ideas, and licenses are just a way to "relax" your copyright. Unless it's patented you are free to make your own implementation of the format without any restrictions.
In the forum thread I linked elsewhere, the author wrote:
"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."
Wow, starting with an unusable license with the intention to switch to a more practical one later is a weird strategy. I guess that's one way to discourage people from adopting it before it's ready.
(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)
Not really propriety software - as you & bildung said, it's not a problem if you can just buy a license. I meant anyone working on FLOSS software that isn't GPL compatible, which is probably most FLOSS software. MIT, BSD, etc are very popular these days. And image formats are generally intended to be widely-adopted standards used across different applications.
Most "FLOSS" software is GPL. Almost all is GPL compatible.
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...
Firefox is GPLv3 compatible. It's quite likely that it will support this format - although, if it's the only major browser doing so, it will not be adopted by most web publishers.
I would be very surprised if Firefox added support. They have been very reluctant to include any additional image formats that weren't developed by Mozilla employees. See for example WebP and Jpeg2000.
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.
The Mozilla Public License is GPLv3 compatible. Firefox also contains code that is under different licenses that is not GPLv3 compatible, and thus firefox is not GPLv3 compatible
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?
> 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.
Starting with a more restrictive one leaves his options open; moving from restrictive to liberal is a lot easier than moving from liberal to restrictive.
Erm, what? If you have ANY contributors other than your core project team going from a restrictive to a more liberal license requires agreement from all of them, as they ALL have copyright somewhere in the project.
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.
I think it has more to do with maintain control initially.
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.
You can't link proprietary software with GPL libraries, only with LGPL libraries.
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.
WatchGuard is a disease. They also listed Hackaday as banned for "Hacking". Ever try to get a site unlisted from them? It's nearly impossible, and may only last a month or so before it goes back on the blacklist.
A million monkeys, scratching their heads, looking for a better way to save/send their photo albums. Progress has been on order for a while now, someone(s) is/was bound to crack it sooner or later.
- 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".
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 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.
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?
I hope the author can come back to tell us whether he did comparisons with different speed presets for BPG; it ranges from insanely fast to insanely slow, and that's probably just the default.
I only tried bpgenc with the default speed presets.
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.
I don't see any foundations or corporations backing this project. Without support (I hope something like this does gain wide scale support (SVG in browsers for the Internet please already!) I don't see this being accepted.
What you say it's true for a wide scale usage. However, imagine a small company, startup, or a sole developer using this for their projects or as a internal format. I found it very interesting even if there is not a widespread use of it.
It is interesting! I agree but I guess I am getting to old. I keep hearing awesome new formats and than they just waste away. The few success stories are few and in between. FLAC and OGG are a good example. OGG is a decent format and I prefer it to MP3 but it really just withered. FLAC is awesome but it is far from main stream. Heck even SVG is far from where it SHOULD be.
> 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.
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).
Well given that they're all lossless formats, the image should appear identical with any of the codecs, with only the file size (and encoding style) being different.
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.
Oh! Derp! I guess I am used to marketing-level abuses of language.
>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.
They could demonstrate interlacing comparisons by slowing down (through setTimeout()) the image processing in the browser.
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!
I couldn't see any information on speed performances. There is certainly a price to pay for these impressive results. It could be the compression time. I hope not the uncompressing time.
I am not relating to this project, but I am actually in the middle of the development of a 3d image retrieval server and this very interesting to my work right now.
I will compare this using lodepng as a baseline and hope to report soon.
I'm guessing that they're not releasing the numbers on that yet until the format is finalized. It's likely not gone through any serious optimizations yet.
Wow! Higher compression than any other format, full transparency support, progressive/partial loading AND animations?! I can't wait for this to get widespread adoption!
The GPL is compatible with BSD, MPL, and MIT licenses that Firefox / Chromium use.
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.
If Apple's attributions are correct (1), there is LGPL software on iOS, for example libiconv, and even GPL software (libgcc, libstdc++), but those have linking exceptions. WebKit also is partially LGPL.
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.
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.
The Mozilla Public License used by Firefox is compatible with the GPL.
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?
If the only spec is the code, that's going to be prohibitively difficult. There's a warning that the format isn't complete either, and you can expect breaking changes.
Technically, I believe the answer is 100%. If you're using the original code as a starting point or a reference for your code, then you're basically creating a derivative work.
Correct, you have to do a clean room implementation. You either start from a public standard, or you need two separate teams. One team is allowed to look at the existing code and make a detailed description of what it does, but not write any new code, and the other team can read the descriptions from the first team and write the new code, but they can't ever look at the old code.
This only works to avoid copyright infringement. Patent infringement cannot be avoided in this fashion.
And that, boys and girls, is how we got the PC clones. Thanks to Compaq no less. Could not happen today though, as back then IBM could not patent the BIOS chip.
You can copy how something works, copyright doesn't protect that, patents protect that. If the form of it is necessary for how the thing works then it's not an artistic expression and so you can copy that directly. Generally speaking there are not interoperability exclusions though so if the choice isn't technically essential you can't copy.
The real barrier to adoption is, for the time being, older browsers, anyway. Want to lose 20% of your potential market via IE in favor of some improved image compression? =\",
True enough... though there are a lot of other ways this can/could make it in the interim... much like webp through various optimizing/ha proxies. I to think GPLv3 will hinder peopler even trying to look at or support the format though. There are some legal minefields that many won't cross when it comes to copyleft... even if they wanted to many are in jobs that wouldn't allow it.
Based on how he's acted in the past, I think even Stallman would've advocated something like the MIT or BSD license for something like this -- having a patent-unencumbered alternative to formats like JPEG 2000 being used seems to be more important to a lot of Free Software people. In other words, the advantage of having widely-used file formats that are accessible to free software programs are considered greater than the benefits of having software become libre in order to use GPL'd file format libraries. Stallman defended the use of a non-copyleft license for Ogg/Vorbis on those grounds:
> even Stallman would've advocated something like the MIT or BSD license for something like this
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.
Yes, but let's give this a little time. If this was going to be another example of 'the code is the spec' it wouldn't go far anyway. That's a n00b mistake, and I don't think these guys are n00bs.
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.
Actually, now that I think about it a bit, maybe not. If your only interface to this is feeding it a compressed file and getting back a bitmap, then you haven't derived from it. You enter a certain legal gray zone, but you should be okay loading it as a dll.
That's just the first implementation. Anyone can reimplement it. And as noted elsewhere in the thread, it won't continue to GPLv3 after things settle down.
Totally. I really recommend watching the video under the "Progressive and lossless" heading. With just 20% of the file downloaded the image quality was already subjectively quite good. I didn't even know progressive loading within a single file was a thing, but it's a neat trick.
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 it down with html.
I assume you're talking about progressive JPEGs. These are still fairly common in my experience. It's just that with today's typical connection speed, you'll rarely notice.
There's also progressive PNGs. Progressive JPEGs have the advantage that they increase compression ratio (though they're more expensive to decode, as you need multiple passes and refresh)
They increase compression ratio? That's counter-intuitive. You're effectively imposing an ordering requiring certain information to be available first, so you'd expect the compression be at most as good as non-progressive. I guess the changed ordering makes the statistics simpler and easier to compress, or something like that.
The initial passes are lower freq, so they compress better. More over you have control over them when encoding so you can optimize there (and there are tools that do so), but the defaults used by all encoders are very good across most all images.
The downside is memory usage during compression. A non-progressive jpeg can be compressed locally but a progressive encoding requires the whole image. But this is only a small downside.
(Converting JPEG images to progressive format is one of the optimizations mod_pagespeed makes.)
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]
JPEG 2000 is capable of compressing 1969x1307 images without issues. I work with JPEG 2000 codecs every day. It is commonly used in Virtual Microscopy with images in the tens of gigabytes as well as with small 256x256 MRI. I don't know why the author does not present "JPEG 2000 at this size".
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.
That example is looking at a specific file size. So what he's saying is that he was unable to produce a JPEG 2000 image in a file that size from that image, not from an image of that resolution in general.
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.
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.
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).
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?
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.
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.
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.
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 <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.
I wonder if it would be feasible to have browser functionality that starts the download, then stops it once it has enough data to make an image the width of the element on the page. (Maybe then continuing the download later if it's resized larger?)
You could certainly build that in as a heuristic similar to how many browsers implement <video>: issue Range requests for a certain chunk size and stop once you have enough data. It's not as efficient as being able to get it all in one go but if you have a progressive image format that might be a better experience if it can start rendering quickly and fill details later.
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.
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:
Back in the '90s I was doing work funded by DEC and later NSF with JPEG and one of the things I did was find an decent way to store them at a smaller size and resolution. I found that having the first scan be just the MSB of DC of Y and then later the MSBs of the other two DCs was the same as having the first be all three give or take two bytes over more than 90% of our corpus and it let something display in about half the time (when a 9600 baud modem was target).
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.
Interesting, just last week I had a use for lowsrc for the first time in years and tried to use it, only to find out it had been removed from all browsers a while back.
please be aware that w3schools is a terrible resource loaded with inaccuracies and misinformation. It's the National Enquirer of web development. I'd recommend using MDN instead: https://developer.mozilla.org/en-US/.
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.
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 to enhance the thumbnail.
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.
hmm, how could it be? The pixels values have to fit into the eventual reconstructed image. If the values were different than any pixels found in the final image, it wouldn't be progressively loading, it would have several different size images embedded in it.
That's true. I tried a variant where the resampling would be better, but while it is possible, it hurts the compression rate significantly. At the level of a single step: if you have two pixels A and B that are both 8-bit numbers, then if you want some lossless way to store both (A+B)/2 (an 8-bit number) and enough information to restore both A and B, it will take at least one extra bit (9 bits, e.g. to store B and the least significant bit of A+B). So a 24-bit RGB image would become a 27-bit images when interlaced with better resampling (except for the very first pixel, which would need only 24 bits).
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).
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.
If you want to use a similar feature -today-, there's this service called Imgix: https://www.imgix.com/
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.
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.
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.
You're right about the interpolation method (bilinear vs nearest-neighbor), it's indeed not a fair comparison in that respect. However, I do think that most PNG viewers use nearest-neighbor (at least that's what my viewer did when I gave it a partial PNG file).
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.
IANAL, but I guess the file format itself is not covered by the GPL 3, only the reference implementation.
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.
They also go on to say. That might be a clear indication that this is in fact GPL v3.
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.
True, but the only complete documentation of the file format I found was the source code of the reference implementation. So the only way to write a new implementation is to study the reference implementation, which will make your new implementation "tainted".
Studying GPL'ed source code does not "taint" anything. You're absolutely allowed to do that. If you're really concerned about subconsciously copying elements of the original into your implementation, you could let somebody else study the original and write a spec.
Guess how many court cases has been about developers tainted from reading code.
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.
No documented format (actually an explicit acknowledgement that the format will likely change). The implementation is the spec, the implementation is GPLv3, so many companies lawyers will prevent engineers even looking at it to write a clean-room implementation.
>so many companies lawyers will prevent engineers even looking at it to write a clean-room implementation.
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.
The difference is that the lawyers for some companies will not sign off on employees even looking at GPLv3 sources. Rightly or wrongly, this really does make a clean-room implementation impossible.
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.
+1 for the "full app/solution" vs. library/framework applicability for GPL vs. permissive: That is exactly my opinion too. When I see GPL'ed libraries, I think "try before you buy"-style open source code, and these invariably also comes with an option to buy a commercial license.
The code won't but the spec/format can. What you do is have a third party look at the code. They need to identify a high-level description of what it does, what inputs the format takes, what outputs it uses, the storage format, and so on. Precise enough for someone else to implement it from scratch with likely compatibility. Yet, not copying the code itself and maybe not even copying the implementation strategy. Should avoid GPL tainting.
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.
The most solid feature is lossless responsiveness. Stopping the download gives you a lower-resolution image. When scaled, the image then becomes lossy.
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 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.
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 more liberal license. And such a waste of resources is sad to contemplate.
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.
In the context of this project which is yet to have a finalized specification I think the GPL is an ideal format. As a project it is important to have access to all of the pieces and avoiding incompatible forks of different kinds in the early stages. So for the purpose of developing a 'golden standard' prototype for FLIF, I don't think a non-GPL license would have served them better.
The author seems to have the same idea, and is considering re-licensing to MIT later on.
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.
> If a company wants get something for free, expecting it to publish source code changes is not an actually high threshold.
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.
You're free to link to compiled GPL libraries. There is nothing forcing you to change the license of your product unless you intend to integrate the sourcecode.
I also believe this, but it is not an established fact. The GPL does prohibit it, and so whether that is actually enforceable has to be tested in a court of law. So you are in fact not free to do this, if you have a boss above you who cares dearly about the company steering clear of hot water.
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.
The problem with that line of thought is that the courts don't care if its use or integration, but if the resulting work depends on someone else work. The word used in copyright law is transform, adapt, recast, and such changes requires additional copyright permission. 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. Components can not be cleanly viewed as separate when dealing with copyright.
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.
> but if the resulting work depends on someone else work.
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).
Might it be that this separation between those rights exists so that the copyright holder can contract out manufacturing services, while controlling distribution? The copy house is given the right of preparing copies, without having distribution 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.
> 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.
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.
> 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 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.
The FSF takes the position that linking is derivative work; this may or may not be an accurate legal position, but it's a popular position from the licensed creator and an entity which owns a lot of software licenses under the GPL, and which is very influential with people who choose to use the GPL, so even if it is ultimately legally incorrect, the risk of litigation, whatever they outcome, from linking is going to be unacceptable to most significant users, so a GPL library is unlikely to see uptake in major software for which the creator had a significant reason for choosing a non-GPL license, whether it is permissive or proprietary.
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 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.
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 GCC and how they were licensed.
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)?
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.
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.
kazinator was correct that saying one product made it proves nothing about overall effectiveness of its attributes. That's unscientific. If we're using uptake and maintenance as criteria, we might start with the venerable Sourceforge to see what percentage of projects go anywhere or get maintained under various licenses (esp GPL). Compare that to proprietary while we're at it. I predict results aren't going to look good for GPL's success rate and that's without a financial requirement.
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.
Is there any evidence that the author will sell commercial licences? Other comments are describing him as a strong proponent of free software, so it seems very unlikely that he is interested in selling proprietary licences.
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."
> 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.
> 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 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.
That's the whole point of GPL. To move people away from closed source by having a sperate ecosystem that cannot be contaminated. The problem is that the ecosystem hasn't been that compelling besides a few things such as Linux.
That's fine as a long-term goal, but it's pretty directly in conflict with the short-term goal of getting support for this image format into all browsers. If you want this in e.g. IE, someone will have to re-implement it with a license compatible with IE. And there will be compatibility bugs, non feature-parity, etc.
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.
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.
What you are describing in the rant is how GPL works, so surely there must be some misunderstanding here. If you use a GPLv3 library, your own additions to it can be GPLv3 or any compatible license. It can be mit, apache, BSD, mpl, CC-anything so long it allow commercial use, and almost any of the free and open source licenses. The entire thing to do not need to be GPL and in large projects its commonly not.
> 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.
There is no form of maybe in it. People who don't retain the original license text are committing copyright infringement.
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.
I'm not clear on what you are trying to say. Naturally, the GPL only applies when distributing GPL'd code, not when it's used solely privately. The license clearly states that all parts of the "work based on the Program" (anything derived from GPL code) have to be licensed under GPL. The FSF has always asserted that a derived work includes anything that statically or dynamically links to GPL'd code, although the term was controversial and v3 now mentions linking explicitly. So, when the section above talks about "the whole of the work and all its parts", that includes files that are by themselves not GPL'd. These have to be distributed under GPL as well if you want to include them.
The distributor must apply the license to the entire work, but individual parts can always be licensed under different license.
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.
But in practice if you don't care if someone using your code shares back the sharing actually increases. I guess many got fed up with RMS FUD, although from time to time some fun pops up with observation how RMS was right all along, or if he weren't then you will see how right he was in about five minutes.
It has nothing to do with requirement of code sharing. It's all about realism. So far there has been 0 successful file formats/codecs with GPL reference implementation and there is no reason to except FLIF to buck the trend. So its a huge shame that the effort now goes to waste because of avoidable political reasons.
> RMS has been shown to be right about his stance on freedom.
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.
Because GPLv3 code will never be adopted in IE, Safari, Chrome and likely Firefox... that's why. A reference implementation for an unencumbered format that doesn't also have a permissive license is unlikely to see wide adoption and support.
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.
If you want to your code to always be free, GPL is a good choice. If your want your code to be used by everyone, including e.g. all large browsers, you really need a permissive license.
Just imagine if SQLite was GPL-only, barely anybody would use it.
Perhaps, but the GPL licensing of this code isn't a barrier to them doing that, since most of them will be running web services that can use GPL code freely without having to release the rest of their code. If it was AGPL then maybe you would have a point.
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.
As a younger coder who has worked at the bigger firms that disallow use of GPL code in projects (Amazon, Google) - it is a huge disappointment to find a quality library that is GPL:
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.
I can't speak for others, but for me it's not about money at all. I just want awesome technology like this to thrive and become the standard instead of falling into obscurity due to licensing complications.
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.
Look at it from the perspective of someone interested in implementing this: once you put GPL code into a project, you're required to license the entire project under the GPL. That means that anyone trying to implement this format, even other open-source projects (i.e. every browser except for Internet Explorer/Edge, tools like ImageMagick, etc.) would have to relicense their entire project just to use it, which in practice means the format is never going to be adopted.
The tragedy is that there's already a decent license for this exact need:
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:
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.
Perhaps it is simply that GPL3 asks much in exchange for what would be a small piece of a larger project. Kind of like asking people to give you their email address and phone number so they can use the shopping cart at the store.
My personal feeling is that GPL is good for programs, but bad for libraries, as I end up having to make my whole program GPL (or GPL-compatible) if I use a GPLed library. Often I don't want to do that, and if I use a another library which has a GPL-incompatile license, then I'm stuffed.
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.
I hope the idea of progressive downloading partials can be applied to other files types as well.
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.
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?
Decompression speed is important. (And more important than compression speed.) But the bottleneck on mobile devices is increasingly falling on the mobile network. CPU performance per watt is falling dramatically where mobile bandwidth per watt is staying relatively static. If this continues eventually we'll get to the point where the power usage (e.g. for loading and displaying a web page) is completely dominated by data transfer, and more and more computationally expensive compression becomes the best way to save overall power by trading cheap cpu cycles for expensive bandwidth.
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.
An interesting aspect that has not been mentioned on flif.info nor here, is the implementability on silicon.
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.
"Free Lossless Image Format": the quality metric for lossless images is "identical pixel by pixel to the reference format".
(There's obviously a question about how to judge quality for a given partial download of a FLIF file, but for the total file there really isn't any question of quality metrics at all.)
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!
As someone who regularly has to read supposedly landmark papers - with no source code provided - this is far preferable in my opinion. Computer vision is terrible for this!
372 comments
[ 3.0 ms ] story [ 317 ms ] threadIn 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:
I would suggest that this is a case where widespread use is more important than copyleft.[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
Reason: Category 'Newly Registered Websites'
I wonder if they had a real legal person OK that claim.
https://boards.openpandora.org/topic/18485-free-lossless-ima...
Also, comments in that thread on speed [1]:
[1]: https://boards.openpandora.org/topic/18485-free-lossless-ima...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.
> 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).
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!
I will compare this using lodepng as a baseline and hope to report soon.
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.
https://lwn.net/2001/0301/a/rms-ov-license.php3
Almost, Stallman (well, the FSF) advocates Apache 2:
Source: https://www.gnu.org/licenses/license-recommendations.htmlIf 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.
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
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.
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.
No but I'm excited, this is progress!
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”:
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.
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).
https://www.law.cornell.edu/uscode/text/17/106
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.
https://en.wikipedia.org/wiki/Pigeonhole_principle
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.
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.
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.
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.
(There's obviously a question about how to judge quality for a given partial download of a FLIF file, but for the total file there really isn't any question of quality metrics at all.)
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.