Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Image file formats that didn’t make it

tedium.co

Post reply on HN
Print view View original

151–160 of 210 posts

Re: Image file formats that didn’t make it

#151

Post by Zardoz84 »

crummel wrote: post #116
ahartmetz wrote: post #16

JPEG2000 is a big one that seems to be missing. It is used in medical imaging or something, because laws? But its visual quality is worse than old JPEG, despite a PSNR advantage. Apparently, compression researchers used to think that people care about PSNR.

I worked on a library that had to process PDFs and grabbed a bunch of PDFs from archive.org and other open sources for testing, and as I recall, about 2% of them had at least one JPEG2000 image. So if you're in the PDF space it's probably still worth considering.

If you need to generate miniatures from PDFs, you must handle JPEG2000 and JBIG

Re: Image file formats that didn’t make it

#152

Post by NL807 »

klodolph wrote: post #63
Macha wrote: post #50

Earlier quoted context omitted.

TGA files still show up in video game textures surprisingly often

That's probably because of how simple the format can be, with basically a header and footer tacked on to some RGBA data. Surprisingly, with PNG, the deflate compression can slow you down, depending on what you are doing with the data. Saving a little bit of IO when you're accessing local data can turn out to be a losing proposition. TGA makes it easier to just shove pixels around, from program to program. TGA has all…

Not only that, but you can use TGA to write 16-bits per channel, which is very useful for raw data, or linear RGB colour spaces.

Re: Image file formats that didn’t make it

#153

Post by duskwuff »

jandrese wrote: post #131
duskwuff wrote: post #81

Earlier quoted context omitted.

PICT was a really weird format. It's a stream of drawing instructions for Apple's old QuickDraw graphics layer. This could include bitmap graphics, but could also include (semi-)vector operations like drawing lines, circular arcs, polygons, or text.

Of course this means making a third party reader means re-implementing QuickDraw and probably getting some nastygrams from Apple's lawyers.

Apple wouldn't care. QuickDraw doesn't exist in current versions of macOS -- Preview.app can't even display them.

I've actually toyed with the idea of a PICT to SVG conversion tool. It's potentially useful for viewing certain old documents in the (long obsolete) Apple DocViewer format.

Re: Image file formats that didn’t make it

#154

Post by tinus_hn »

ElectricalUnion wrote: post #141
chriscjcj wrote: post #110

Earlier quoted context omitted.

TIFFs are uncompressed or compressed with zip or lzw which is lossless. JPEGs are lossy and can't possibly be lossless. Pitting one as an alternative to the other is apples an oranges. When I read that sentence you quoted, I figured that the author is either lacking knowledge on the topic they're blogging about or they are trolling.

> JPEGs are lossy and can't possibly be lossless. https://jpeg.org/jpegxl/

File formats exist that have JPEG in the name, that have certain features JPEG does not, and that cannot be decoded by all of these programs that can decode JPEG files. A JPEG XL file, for all intents and purposes, is not a JPEG file.

JPEG is a file format from decades ago. Obviously it’s possible to do better today. But it’s not possible to just invent a new format and have it as widely usable as JPEG. PNG did this with GIF but really only because GIF was seriously hobbled by software patents. It’s doubtful the millions of colors and alpha transparency would have won over compatibility otherwise.

Re: Image file formats that didn’t make it

#155

Post by jamesfinlayson »

klodolph wrote: post #63
Macha wrote: post #50

Earlier quoted context omitted.

TGA files still show up in video game textures surprisingly often

That's probably because of how simple the format can be, with basically a header and footer tacked on to some RGBA data. Surprisingly, with PNG, the deflate compression can slow you down, depending on what you are doing with the data. Saving a little bit of IO when you're accessing local data can turn out to be a losing proposition. TGA makes it easier to just shove pixels around, from program to program. TGA has all…

Half-Life is a little old but I wrote a parser for the .tga files it uses and it was simple (but reading the full spec... yeah it can get complicated with all the different flags).

Re: Image file formats that didn’t make it

#157

Post by dvhh »

acdha wrote: post #149
jandrese wrote: post #129

Earlier quoted context omitted.

The patent situation was exacerbated by the fact that JPEG2000 started getting pushed right about the time the GIF patent situation blew up so everybody was reluctant have a repeat disaster. Add in the fact that JPEG2000 showed at best a marginal improvement over JPEG and it's not hard to just stick with the proven technology. Having no good reference implementation is just a nail in the coffin.

I would describe JPEG-2000 as more than a marginal improvement over JPEG: it's one format which supports lossless and lossy compression, it compresses a good bit better and the artifacts are less visually distracting, has better progressive streaming, and full support for variable bit depth and colorspaces. If you look at it technically, it'll win on just about every point. Unfortunately for the standard, most of the…

But compression time were atrocious and decoder were not as fast as the jpeg one (at the time).

Marginal support from tool/browser didn't help boost its popularity, and patent situation as pointed in parent comment just shut the coffin on this otherwise ok format.

At the time vanilla jpeg had compression artifact and had worst compression rate, but was good enough at the time, even now because of its ubiquity the "successors" are still having a hard time dethroning jpeg.

Re: Image file formats that didn’t make it

#158

Post by powerpiglet »

jandrese wrote: post #133
mixmastamyk wrote: post #75

Found VRML in there unexpected. But was expecting MNG but didn't find it. Interesting history with that one, a few browsers implemented it but then removed it. Leading to a lot of geek angst. https://en.wikipedia.org/wiki/Multiple-image_Network_Graphic...

I was never sure why MNG failed so spectacularly. Eventually it had to be replaced by full up H.264 videos and a lot of places are still using old fashioned animated GIFs because firing up a full fat video codec for a 32x16 animation with a dozen frames is silly. Was it really just the lack of interest from browser makers preventing people from using it?

I remember being excited about MNG, but finding the open-source libmng a pain to use. It was all based around callbacks with the library driving the animation cycle. Not a great fit if you were interested in using MNG for things like sprite animation.

Re: Image file formats that didn’t make it

#159

Post by amelius »

enriquto wrote: post #7

Tiff is very much not dead. It is likely one of the image formats more widely used today. Terabytes of new tiff images are prodced every hour and distributed by many remote sensing operators. It is a really flexible and robust format also. How else are you going to store a floating-point multispectral image of 8 bands and 50.000 x 50.000 pixels, arranged tile-wise for easy cropping?

Writing tiff files is faster than any of the compressed formats.

That's why I often use tiff to save images initially, and then compress in the background.

Re: Image file formats that didn’t make it

#160

Post by __david__ »

mountainofdeath wrote: post #112
a_e_k wrote: post #95

Earlier quoted context omitted.

AFAIK, digital cinema packages (DCP) used for shipping movies to theaters and showing them on digital projectors are still based on JPEG2000 image sequences.

Is there a reason h264 wasn't used? It has been widely available since at least 2006 and supports all kinds of resolutions, etc.

jpeg2000 has a number of positive traits:

* The industry doesn't want you to see compression artifacts, ever. Digital Cinema has no inter-frame compression, it's encoded as a series of individual jpeg2k images at a pretty reasonable quality.

* If one frame has a glitch, the glitch doesn't propagate over a bunch of frames the way x264 style compression does.

* jpeg2k at too-low a quality doesn't have jpeg/mpeg style square artifacts—instead certain parts of the picture will look slightly blurrier.

* jpeg2k has an interesting property where a 4k image can be encoded (with the proper parameters) such that when decoding you can stop at some point midway through a single frames data and have the equivalent encoded 2k image. Which means you can encode for 4k and ship it to theaters that only have 2k projectors (and that 2k hardware isn't required to render to a 4k framebuffer and then downsample).

* Since it's more modern than jpeg was (and dcinema was standardized before something like webp came along), it has a lower bytes/quality ratio than jpeg. IE, to achieve equivalent quality image from jpeg you'd need a lot more data.

* Support for deeper color depths and a much wider gamut. This is of course limited by what a projector can recreate, but they didn't want to limit to rec 709 or something.

They didn't care about patent encumbrance because they didn't need push this out the consumers—the jpeg2k patent stuff only affects the decoders and encoders, both of which are owned by people who can afford to pay.

Post reply on HN