Hacker News Reader

Comment by espadrine | Hacker News Reader

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]

View on HN

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.

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.

Thanks for pointing this out! I only tried ImageMagick convert at minimum -quality. Sorry about that.

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.

I'm not picking on FLIF, it may well be better! But the concept of progressively decoding for different quality levels isn't what makes it new.

Reply on news.ycombinator.com