GeoTIFF

A regular TIFF stores only pixel data, so a DAM has no way to know where on Earth the image sits unless a companion world file travels with it. GeoTIFF embeds georeferencing directly in standard TIFF tags — coordinate reference system, pixel scale, and tiepoints/transformation — making the file self-describing. A DAM can read this metadata straight from the file, index it for spatial search, and never risk losing georeferencing if the companion file goes missing.

No. Unlike a plain image paired with a .tfw world file, a GeoTIFF's georeferencing tags are embedded in the TIFF structure itself, which is why the format needs no companion file to stay geolocated.

Yes — because GeoTIFF is fully compliant TIFF, any standard viewer, browser plugin, or image library can open one and render the pixel data correctly. What gets lost is the geospatial layer: generic viewers simply ignore the embedded coordinate reference system, pixel scale, and tiepoint tags, so the image displays as a flat picture with no sense of location, scale, or projection. Proper display of that context requires GIS software or a DAM plugin that parses the GeoTIFF-specific tags.

Size comes from what the format is used to carry, not the format itself. GeoTIFF commonly holds high-resolution satellite or aerial imagery with multiple spectral bands (e.g., red, green, blue, near-infrared) at full bit depth — often 16-bit or 32-bit per band rather than the 8-bit typical of a photo. Unless LZW or DEFLATE compression is applied, that combination of resolution, band count, and bit depth multiplies file size quickly, so archives of many scenes can consume substantial storage.

The GeoTIFF Working Group first released the specification, version 1.0, in November 1995 — well before OGC involvement. The Open Geospatial Consortium formally adopted it as an official OGC standard in September 2019, published as version 1.1, document 19-008r4. That revision preserved backward compatibility with the original 1995 tags while tightening interoperability, notably by integrating the EPSG Geodetic Parameter Dataset registry for coordinate reference system definitions used across GIS and DAM tooling.

The archival GeoTIFF should stay untouched — converting or recompressing it risks losing the embedded georeferencing tags that make it useful for GIS work. For previews, a DAM is better served by generating a lightweight derivative, such as a JPEG or PNG thumbnail rendered from the pixel data, or by re-encoding as a Cloud Optimized GeoTIFF (COG), which adds internal tiling and overviews so viewers can stream low-resolution previews over HTTP without downloading the full file.

Beyond standard file metadata, a DAM should pull the geospatial tags that make GeoTIFF distinct: the coordinate reference system (projection and datum), pixel scale and tiepoints or the full affine transformation, and the resulting geographic bounding box. Band count and bit depth are also worth capturing, since they explain file size and processing needs. Tools built on GDAL, such as gdalinfo, can read these tags directly and expose them for indexing and spatial search.

Yes, with caveats. GeoTIFF is self-describing and self-contained — no companion world file to lose track of — and it rests on both a stable 1995 baseline and a formal OGC standard (1.1, 2019), so long-term readability is well established. The tradeoff is size: uncompressed or lightly compressed multi-band imagery can be very large, so a DAM archiving many scenes needs adequate storage planning and should avoid altering the original file when generating previews.