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

201–210 of 210 posts

Re: Image file formats that didn’t make it

#201

Post by NelsonMinar »

NelsonMinar wrote: post #134
iscrewyou wrote: post #25

Earlier quoted context omitted.

Geo-tiffs are the go to standard in GIS integration of any property map. Photoshop works really well with tiffs.

Was going to say the same thing; GeoTIFFs are common. But they are a "specialist" format in the way the article is talking about. Why is GeoPNG not a thing? PNG is based on TIFF's design with various chunks allowing all sorts of metadata storage. It'd be pretty easy to translate GeoTIFF's GIS stuff into PNG. Has that been done?

I asked some GIS experts on Twitter and GeoPNG is not a thing. Most folks seem to think GeoTIFF does just fine so there's no need for it. TIFF's support for more than 3 channels of data is a big help for multispectral remote sensing.

Re: Image file formats that didn’t make it

#202

Post by klodolph »

willis936 wrote: post #181
NL807 wrote: post #152

Earlier quoted context omitted.

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.

Does bitmap not tick all of these boxes?

I’ve never seen a 16 bits per channel BMP… is that even possible?

Re: Image file formats that didn’t make it

#203

Post by acdha »

dvhh wrote: post #179
acdha wrote: post #173

Earlier quoted context omitted.

Exactly: it seems like a classic “Worse is better” situation where JPEG 2000 is basically better across the board on features but none of that mattered as much as being widespread and fast enough. Something like TIFF or BMP wouldn't have been able to do the same since the file sizes are so much larger that they'd have had a noticeable impact on usability but JPEG was far over the “good enough” bar for most users.

I think facebook even had a backlash when it tried to switch to webp for serving image

Yes - anything which breaks “save as” is going to hit backlash. However, as a counter example Apple’s HEIC deployment has been smoother since it works for users when it transparently transcodes shares outside of the ecosystem with HEIC support.

Re: Image file formats that didn’t make it

#204

Post by poizan42 »

chriscjcj wrote: post #110
zwieback wrote: post #31

Earlier quoted context omitted.

That was my reaction. To be fair author says: "Of the formats listed here, TIFF is probably the one most likely to still be in wide use, but it has evolved into a more specialized format for professionals, in comparison to something like JPG."

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.

TIFF is more like a container format that can contain a ton of different formats including many lossy formats. That also includes not just one but two different ways of embedding JPEG data (Compression 6 vs 7). See e.g. https://www.awaresystems.be/imaging/tiff/tifftags/compressio...

Re: Image file formats that didn’t make it

#205

Post by giantrobot »

drdeadringer wrote: post #176
giantrobot wrote: post #102

Earlier quoted context omitted.

VRML Sourcebook [0]. I did a similar little project in VRML. I took the general organization of my homepage and VRMLized it. Authoring it was such a pain in the ass. I loved the concepts behind VRML, and still do. Unfortunately all of the implementations around it were terrible. When it was in vogue PCs weren't powerful enough to handle anything but the most trivial models. Dial-up was entirely insufficient to delive…

> I loved the concepts behind VRML, and still do. Unfortunately all of the implementations around it were terrible. Being ~18 years away and therefore memory is skewed, may I ask regarding how the implementations were terrible? Honest question.

On the playback/viewing side many VRML viewers were browser plugins. The idea being you might navigate from a web page to a VRML space or embed a 3D object in a web page. These were (as I remember) very sluggish and crash prone which took down the whole browser. Even dedicated VRML browsers weren't all that great.

I don't remember any without awful skeuomorphic buttons and view borders. Their navigation UIs also tended to be terrible. Most I ever tried aped 3D modeling apps using the mouse (a workstation mouse with three buttons) to fly through a scene. But with the typical PC mouse having two buttons (and a Mac with one) you had to use modifier keys to switch between fly and "look". VRML supported world gravity (intensity and a normal) so a viewer program could just navigate like a FPS game but I don't remember any that did.

Another issue I remember but may have just been my PC, because WRL files don't embed any linked content they've got to go fetch every resource referenced like on a web page. On my systems at least this led to a lot of pop-in as I moved through scenes, even locally. On dialup it's was a thousand times worse.

So modulo actual hardware performance, or lack thereof, you had poorly performing software with very alien feeling UI. While that is more than 20 years of time between me trying VRML and now those are things that stand out to me. Maybe none of these problems existed if you were blasting around on an SGI O2 workstation or knew just the right software to use. I had neither so I just stumbled around playing with stuff.

Re: Image file formats that didn’t make it

#206

Post by bick_nyers »

SavantIdiot wrote: post #130
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.

Isn't DiCOM a popular image format for medical imaging too? Or does DiCOM use Jpeg2000 under the hood?

In DICOM you have the notion of a transfer syntax, so you can choose your compression scheme (from a list of Dicom supported transfer syntax), such as JPEG2000. You can also just leave the images uncompressed as well. That being said, any images of sufficient size are very likely to be compressed, J2K being one of the most popular.

IMO, the flexibility provided by the container is not worth the development/support effort. It's better to do one or two things really well rather than have hundreds of edge cases.

Re: Image file formats that didn’t make it

#207

Post by a_e_k »

madmoose wrote: post #199
a_e_k wrote: post #82

Earlier quoted context omitted.

Yes, IIRC it's about an 18 byte binary header and then BGRABGRABGRA... or BGRBGRBGR... bytes for uncompressed (there's also an RLE mode, but I never use it). The only real gotchas are the channel ordering and that the image might be flipped top-to-bottom if you're not careful. These days though, I use tend to use the even simpler PPM format. It uses normal RGB byte ordering from top to bottom, and it's simple enough…

PPM P6 is also what I use all the time - I usually have to convert from paletted format to RGB first. A PPM paletted format would save me a lot of space. The built-in support for PPM in Preview on Mac OS X makes it extremely useful.

For my use, alpha is what I tend to miss in PPM. There's the PAM extension [0] but it's not nearly as widely supported as basic PPM. Usually at that point, I reach for PNG via stb_image_write [1].

[0] https://en.wikipedia.org/wiki/Netpbm#PAM_graphics_format

[1] https://github.com/nothings/stb/blob/master/stb_image_write....

Re: Image file formats that didn’t make it

#208

Post by jfrunyon »

klodolph wrote: post #144
jfrunyon wrote: post #124

Earlier quoted context omitted.

I believe PNG supports uncompressed files, usually with a compression level = 0.

The data is still a Deflate stream, it's just that the deflate stream will be a series of literal blocks. The idea behind "uncompressed" is that you can just copy the data into memory, and level = 0 does not achieve that (you still have to decode the deflate stream).

... what decoding needs to be done on a series of literal blocks?

Re: Image file formats that didn’t make it

#209

Post by mark-r »

hanche wrote: post #194
infogulch wrote: post #191

Earlier quoted context omitted.

Really? Slightly customized in what way? Would a tiff reader be able to decode them?

As far as I’m aware, all the tags (the T in TIFF) are in standard TIFF format. But your generic TIFF reader might haves some trouble getting the image data (I.e., the pixels).

For sure, you'd need de-Bayering for a start. And stuff like white balance will be in a custom tag.

Re: Image file formats that didn’t make it

#210

Post by secondcoming »

authed wrote: post #178
secondcoming wrote: post #142

ICO? Window's icon format. IIRC it was really two images baked into a single file; one a colour bitmap and another mask that's used for transparency.

Don't a lot of favicons still use that format?

Possibly. There was this HN news article from a short time ago [0]

"The vast majority of the favicons offered up by websites are PNG. 71.6% of images are PNG. 21.1% of /favicon.ico files are secretly PNGs, including Reddit’s. Strangely, only 96.1% of Apple touch icons are PNG. Presumably the other 4% are broken."

[0] https://news.ycombinator.com/item?id=28933391

Post reply on HN