TIFF

TIFF is the format pro scanners write, the format Photoshop saves master files into, the format archival photo workflows standardise on. It’s also the underlying wire format of EXIF itself — every JPEG with EXIF carries a TIFF Image File Directory (IFD) inside an APP1 segment. When you parse EXIF, you are parsing TIFF.

That circularity is why TIFF metadata feels familiar: the same Make, Model, Software, DateTime, Artist, Copyright tags from JPEG EXIF live directly in TIFF’s IFD0.

What it carries

TIFF is built around the Image File Directory — a flat table of tagged entries pointing at values either inline (≤ 4 bytes) or out-of-line in the file. The relevant identifying tags:

• 0x010F Make / 0x0110 Model — camera body.
• 0x0131 Software — editing/processing tool.
• 0x0132 DateTime — file modification time.
• 0x013B Artist / 0x8298 Copyright — explicitly identifying.
• 0x013C HostComputer — the workstation that processed the file.
• 0x8769 ExifIFD / 0x8825 GPSIFD / 0xA005 InteropIFD — pointers to sub-IFDs carrying camera settings, GPS coordinates, lens serial numbers, interoperability metadata.
• 0x02BC XMP packet (binary form).
• 0x83BB IPTC/NAA, 0x8649 Adobe Photoshop image resources — additional creator metadata.
• 0x927C MakerNote / 0x9286 UserComment — vendor-private blocks and user-added text.

The image data itself is referenced by 0x0111 StripOffsets + 0x0117 StripByteCounts (for strip-based TIFFs) or 0x0144 TileOffsets + 0x0145 TileByteCounts (for tiled TIFFs). Those tags hold file offsets into the bytes that decode to the pixels.

What’s unique

TIFF can chain multiple IFDs (multi-image TIFFs) and reference SubIFDs (the Adobe pattern used by DNG to put the thumbnail in IFD0 and the primary image in a SubIFD). The strip has to handle both — which means rewriting offsets when the layout changes, not just dropping tags.

The other quirk: TIFF supports both little-endian (II) and big-endian (MM) byte order, signalled by the first two bytes of the file. Handlers that hard-code one endianness silently corrupt the other. Tracemute detects the byte order from the header and respects it through the rewrite.

What Tracemute does

The handler is a native IFD parser + rewriter working from an allow-list of structural and colour-calibration tags. Everything not on the list — Make, Model, Software, DateTime, Artist, Copyright, ExifIFD/GPSIFD/InteropIFD pointers, XMP, IPTC, Photoshop blocks, MakerNote — is dropped.

1. Parse the TIFF header (byte order + first IFD offset).
2. Walk IFD0 entries and recurse into SubIFDs (tag 0x014A).
3. Use exifr to extract identifying tags for the dossier so the user sees Make, Model, GPS coordinates, etc. before they’re removed.
4. Build a kept-IFD plan: structural tags only (image dimensions, compression, photometric interpretation, strip/tile offsets+counts, samples-per-pixel, planar config, ICC profile, resolution, colour map, JPEG-in-TIFF tables).
5. Lay out the new file: header → IFD0 → IFD0 out-of-line values → SubIFD chain → image strip / tile data. Patch StripOffsets, TileOffsets, JPEGInterchangeFormat, and SubIFDs pointers with the new offsets.
6. Copy strip / tile bytes verbatim from the source — the pixels are byte-identical.

What survives

Structural tags required to decode: ImageWidth, ImageLength, BitsPerSample, Compression, PhotometricInterpretation, SamplesPerPixel, StripOffsets / TileOffsets and their byte-count companions, PlanarConfiguration, JPEG-in-TIFF tables, ColorMap, YCbCr coefficients, transfer functions. The ICC profile (tag 0x8773) is kept per project policy. The image data — every byte referenced by StripOffsets or TileOffsets — is copied verbatim.

For multi-image TIFF chains (rare in camera output), only IFD0 is preserved in v1; the chain pointer is set to 0. If that affects a workflow you depend on, let us know.