Hacker News Reader

Comment by enriquto | Hacker News Reader

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?

View on HN

AKA: Thousands of Image File Formats.

I still remember trying to explain to a previous employer why I needed Debabelizer to create appropriately-striped TIFFs in addition to Photoshop. In hindsight, the me of today would have said then, "I just need it to do this job, which will make you far more money than it costs to buy a single license." The me of then wasn't quite as savvy.

I regularly outline how much engineering time could be saved with some minor capital expenses. They choose the longer and more expensive route every time.

Oh, my. DeBabelizer was an extremely powerful and extremely eccentric tool. Weird, weird, weird. But powerful.

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."

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 sorts of weird options which you can ignore, but with PNG, compression is mandatory.

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?

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?

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).

When I worked on Call of Duty (~7 years ago) almost all of our source images were TGA. The runtime format that almost all games use are various block compressed formats (BC7, ASTC, etc) and usually these are grouped in some kind of package/archive format (although engines are moving away from that in order to stream at the asset level) and lz4 compressed on disk.

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...

> 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.

For quite some time TIFF was the default format for screenshots on OS X, which was probably one of its more prominent uses by the general public. During that period it was also pretty common for developers to use TIFF for application assets like toolbar icons and splash screens.

At some point that all shifted over to PNG, but macOS support for TIFF remains good to this day.

It’s because TIFF and Postscript are friends.

Source: NeXTStep ;-)

I'll never pass up the opportunity to add random NeXT trivia -- Grab.app is one of several applications that came from NeXTSTEP/OpenSTEP with relatively few modifications, along with Preview.app, Terminal.app, TextEdit.app, Chess.app, and probably many others.

For anyone with curiosity and time to burn, comparing early OS X with NeXT/OpenSTEP in VMs is fun, just to see what changed and what stayed. Some parts are extremely different, while some software seemed to be copy-pasted over, while others clearly had a lot of polish put into them for the consumer market. Fun times!

Preview existed in OpenStep?

Hmm, I don't remember TIFF for screen shots. It was PDF (perhaps PDF-wrapped TIFF?) ca 2002–4 which is not too long after the first usable OS X.

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.

TIFF it's a recommended format for digitalised documents by the American library of Congress. https://www.loc.gov/preservation/resources/rfs/stillimg.html

also, DNG format (a raw format) it's a derivated from TIFF.

Yes, TIFF was (probably still is) the standard for capturing X-ray detector images with tons of channels, weird numbers of bits per channel, and custom metadata. I actually wrote a TIFF decoder in my first job. It is a crazy format though - "bi-endian" in that you have a choice of endianness.

Yea, I was confused when I saw TIFF in the list. I get email attachment with TIFF occasionally through my job. I know TIFF is still common in other fields. It is possible the author is in the fields that don’t encountered TIFF enough and went with the assumption that it is forgotten format.

When I was doing imaging, tiff was my go-to. It's uncompressed so huge images would pop open quickly (compared to loss-less png). I could store 16-bit CMYK images in tiff which no other format (except maybe PSD) would do.

Several years ago, I attended a talk at an imaging.org conference where the presenter, an archivist from the Smithsonian, described how they used tiff in their work.

TIFF also supports optional compression (usually LZW or Zip).

TIFF is wonderful because it's so optimized for performance. When you get the tiling lined up just exactly right with your storage device block/page/stripe size and your CPU cache sizes, it just screams.

I think all the RAW formats generated by digital cameras are really just slightly customized TIFFs.

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.

Don't forget having multiple images in one file - 200.000x200.000 pixel main tiled, pyramidal jpeg or jp2 encoded image, thumbnail, label, overview and barcode. Next to the standardized metadata like resolution and vendor-specific xml with descriptions of channels, wavelengths, antibodies and complete provenance. With libtiff and libtiff-tools to help you make sense of it.

I remember dealing with massive (for the time) TIFF files back in the 90s. I had some full page B/W scans at 1200 dpi which, converted into PostScript turned out to be virtually impossible to convey to my service bureau for outputting to film. I ended up having to send camera ready copy to the printers for them to photograph and strip into the plates in order to meet my press deadline. CD-R was still something in the future and I ended up having to support about 3 or 4 removable media drives to deal with incoming files from my authors.

TIFF is still used in forensics/evidence processing by law enforcement agencies world-wide.

Seeing it on this list makes me think the author didn't dig very deep when writing this article.

The OpenEXR format, from the film industry, can also store an image with that configuration.

True, although TIFF (often used with GeoTiff) can also store 64-bit float (double), which OpenEXR doesn't support.

In this day and age I'd rather use the .npy file format used to save numpy arrays. It's trivial to read and write from C (and any other language) without any dependencies. The openexr api always seemed a bit cumbersome to me.

Scanners often have TIFF or multipage TIFF as one of their delivery formats.

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.

Reply on news.ycombinator.com