Free Lossless Image Format • Hacker News Board

Re: Free Lossless Image Format

#321

Post by silverbacknet » Sat, Oct 03, 2015, 5:28 AM UTC

vidarh wrote: post #85

jpambrun wrote: post #76

Earlier quoted context omitted.

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 quali…

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.

He didn't try hard enough. OpenJPEG has a file size parameter, which can go well below its -q 0 size. I was easily able to generate a 16.9K jp2 by specifying the size: https://dl.dropboxusercontent.com/u/54412753/doom9/fish.jp2 which in png looks like: https://dl.dropboxusercontent.com/u/54412753/doom9/fish.jp2....

Looks better than anything else but BPG at that size, to me, although FLIF obviously isn't optimized for lossy.

Re: Free Lossless Image Format

#322

Post by anandvc » Sat, Oct 03, 2015, 7:33 AM UTC

jttam wrote: post #44

Does it use a middle out algorithm? :)

That's exactly what I was wondering! :)

Re: Free Lossless Image Format

#323

Post by erlend_sh » Sat, Oct 03, 2015, 7:38 AM UTC

jonsneyers wrote: post #232

To clarify: at the moment FLIF is licensed under the GPL v3+. Once the format is finalized, the next logical step would be to make a library version of it, which will be most probably get licensed under the LGPL v3+, or maybe something even more permissive. There is not much point in doing that when the format is not yet stable. It's not because FLIF is GPL v3+ now, that we can't add more permissive licenses later. A…

If that's the case, you should strongly consider setting up a CLA for your project so that you're free to switch licenses without any hassle when the time comes.

https://www.clahub.com/pages/why_cla

Re: Free Lossless Image Format

#324

Post by jonsneyers » Sat, Oct 03, 2015, 7:42 AM UTC

erlend_sh wrote: post #323

jonsneyers wrote: post #232

To clarify: at the moment FLIF is licensed under the GPL v3+. Once the format is finalized, the next logical step would be to make a library version of it, which will be most probably get licensed under the LGPL v3+, or maybe something even more permissive. There is not much point in doing that when the format is not yet stable. It's not because FLIF is GPL v3+ now, that we can't add more permissive licenses later. A…

If that's the case, you should strongly consider setting up a CLA for your project so that you're free to switch licenses without any hassle when the time comes. https://www.clahub.com/pages/why_cla

Done.

Re: Free Lossless Image Format

#325

Post by silverbacknet » Sat, Oct 03, 2015, 8:44 AM UTC

iraphael wrote: post #23

This is really interesting. One of the most interesting parts is the progressive decoding/responsive images. http://flif.info/example.php (go to the bottom of the page). Basically, the last example shows that, if you want a scaled version of the image, you can simply stop decompressing. No need for multiple image files. Just create one with very high quality and decompress until you get the quality you want and scale…

I don't feel like that page is entirely fair.

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.

Re: Free Lossless Image Format

#326

Post by belorn » Sat, Oct 03, 2015, 8:47 AM UTC

SomeCallMeTim wrote: post #282

davidw wrote: post #245

Earlier quoted context omitted.

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

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

Someone will have to call up Blizzard and tell them they have had the kiss of death when using LGPLv3 libraries in Starcraft 2. Without patents to do xml parsing or image handling, how can a game like that ever be sold with commercial success? The game only sold 5 million copies, and an other million for the expansion, so that can't possible have earned revenue for the company to support their employees and investors.

Re: Free Lossless Image Format

#327

Post by belorn » Sat, Oct 03, 2015, 8:59 AM UTC

binarycrusader wrote: post #297

ender7 wrote: post #289

Earlier quoted context omitted.

Please read the comments you reply to: "Once the format is finalized, the next logical step would be to make a library version of it, which will be most probably get licensed under the LGPL v3+"

I did, hence why I referred to "copyleft".

Except that game developers are already using LGPLv3, especially on the PC market which is only worth $25 billion in size.

A key attribute for companies in a heavy competitive market is that they have to use every tool available to get the best product out in least amount of development time. If a company decided to avoid a license just because of religious reasons, 10 other companies will jump into its place and out compete them.

A good example of this is when we see companies reaches out to developers directly to get permission, as the time to do that is worth compared to having developers spend time on unnecessary code. Large AAA games can easily have a long credit list of every license available that can be used in a proprietary product, including LGPLv3.

Re: Free Lossless Image Format

#328

Post by belorn » Sat, Oct 03, 2015, 9:09 AM UTC

CamperBob2 wrote: post #273

spullara wrote: post #188

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

Seems like the mistake the author is making is announcing something as a "product" when it's really still a "project." In principle, using the GPL license for the reference code is OK if his intent is to encourage other people to build more refined, practical, and performant implementations. But the real problem with his choice of license is that a lot of people can't even look at the code for fear of tainting themse…

People should not be reading HN or any news at all if they fear committing patent or copyright infringement from just looking at code. You lock those people into a bunker without internet and just a computer to do the work, and after we call all be safe that it was legal.

Re: Free Lossless Image Format

#329

Post by jonsneyers » Sat, Oct 03, 2015, 9:12 AM UTC

silverbacknet wrote: post #325

iraphael wrote: post #23

This is really interesting. One of the most interesting parts is the progressive decoding/responsive images. http://flif.info/example.php (go to the bottom of the page). Basically, the last example shows that, if you want a scaled version of the image, you can simply stop decompressing. No need for multiple image files. Just create one with very high quality and decompress until you get the quality you want and scale…

I don't feel like that page is entirely fair. 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;…

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.

Re: Free Lossless Image Format

#330

Post by silverbacknet » Sat, Oct 03, 2015, 9:18 AM UTC

versteegen wrote: post #21

lt wrote: post #6

This is really interesting! There seems to be some additional technical information here: https://boards.openpandora.org/topic/18485-free-lossless-ima... - for interlacing it uses a generalization of PNG's Adam7; unlike PNG, the geometry of the 2D interlacing is exploited heavily to get better pixel estimation, which means the overhead of interlacing is small (vs simple scanline encoding, which has the benefit of loc…

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…

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.