TIFFREADDIRECTORY(3tiff)

✨ TIFFREADDIRECTORY ✨

okay bestie, so this is the 3tiff manual page for TIFFReadDirectory from the LibTIFF crew, and it's genuinely one of the most useful little functions in the whole library, no cap 💖

---

🌸 NAME 🌸

TIFFReadDirectory — get the contents of the next directory in an open TIFF file 🦋

---

🎀 SYNOPSIS 🎀

#include <tiffio.h>

int TIFFReadDirectory(TIFF *tif)

---

💅 DESCRIPTION 💅

okay so here's the vibe: this function reads the next directory in the file you specify and makes it the current directory. that's it, that's the whole job, and she does it flawlessly ✨

the tea is that applications only need to call TIFFReadDirectory() when they want to read multiple subfiles in a single TIFF file — because the first directory in a file is automatically read for you when TIFFOpen() is called. so like, directory number one is already handled, bestie, you just gotta come back for the rest 👑

---

🧚 NOTES 🧚

okay so this part is important, listen up 🫶

if the library is compiled with STRIPCHOP_SUPPORT enabled, then images that have a single uncompressed strip or tile of data are automatically treated as if they were made up of multiple strips or tiles of approximately 8 kilobytes each. iconic behaviour honestly.

this operation is done only in-memory — it does not alter the contents of the file. phew, your file is safe 💖

however (and this is the part where you gotta pay attention, fr fr), the construction of the "chopped strips" is visible to the application through the number of strips [tiles] returned by TIFFNumberOfStrips() [TIFFNumberOfTiles()]. so like, the count you get back reflects the chopping, not what's literally on disk. iykyk 😭

---

🌈 RETURN VALUES 🌈

• if the next directory was successfully read → 1 is returned, slay ✨
• otherwise → 0 is returned if an error was encountered, or if there are no more directories to be read.

(yes bestie, 0 is doing double duty here, that's just how it is 💀)

---

🔥 DIAGNOSTICS 🔥

all error messages are directed to the TIFFErrorExtR() routine. likewise, warning messages are directed to the TIFFWarningExtR() routine. so if something's up, that's where it gets announced 📢

here's the full lineup of messages, no skips, no shortcuts, we're listing every single one because that's the whole point 💅

• Seek error accessing TIFF directory: an error occurred while positioning to the location of the directory.
• Wrong data type %d for field "%s": the tag entry in the directory had an incorrect data type. for example, an ImageDescription tag with a SHORT data type.
• TIFF directory is missing required "%s" field: the specified tag is required to be present by the TIFF 5.0 specification, but is missing. the directory is (usually) unusable. 😬
• %s: Rational with zero denominator: a directory tag has a RATIONAL value whose denominator is zero. math said no 🚫
• Incorrect count %d for field "%s" (%lu, expecting %lu); tag ignored: the specified tag's count field is bad. for example, a count other than 1 for a SubFileType tag. so it just gets ignored, moving on 💅
• Cannot handle different per-sample values for field "%s": the tag has SamplesPerPixel values and they are not all the same; e.g. BitsPerSample. the library is unable to handle images of this sort. sorry bestie 😭
• Count mismatch for field "%s"; expecting %d, got %d: the count field in a tag does not agree with the number expected by the library. this should never happen, so if it does, the library refuses to read the directory. 💀
• Invalid TIFF directory; tags are not sorted in ascending order: the directory tags are not properly sorted as specified in the TIFF 5.0 specification. this error is not fatal though, so like, we survive 🫶
• Ignoring unknown field with tag %d (0x%x): an unknown tag was encountered in the directory; the library ignores all such tags. not our problem, not our business 🙈
• TIFF directory is missing required "ImageLength" field: the image violates the specification by not having a necessary field. there is no way for the library to recover from this error. game over 🎀
• TIFF directory is missing required "PlanarConfig" field: the image violates the specification by not having a necessary field. there is no way for the library to recover from this error.
• TIFF directory is missing required "StripOffsets" field: the image has multiple strips, but is missing the tag that specifies the file offset to each strip of data. there is no way for the library to recover from this error.
• TIFF directory is missing required "TileOffsets" field: the image has multiple tiles, but is missing the tag that specifies the file offset to each tile of data. there is no way for the library to recover from this error.
• TIFF directory is missing required "StripByteCounts" field: the image has multiple strips, but is missing the tag that specifies the size of each strip of data. there is no way for the library to recover from this error.
• TIFF directory is missing required "StripByteCounts" field, calculating from imagelength: the image violates the specification by not having a necessary field. however, when the image is comprised of only one strip or tile, the library will estimate the missing value based on the file size. ok so she's resourceful 💅
• Bogus "StripByteCounts" field, ignoring and calculating from imagelength: certain vendors violate the specification by writing zero for the StripByteCounts tag when they want to leave the value unspecified. if the image has a single strip, the library will estimate the missing value based on the file size. vendors really said "idk figure it out" and the library said "bet" 😭

---

🦋 SEE ALSO 🦋

• TIFFOpen (3tiff)
• TIFFCreateDirectory (3tiff)
• TIFFCustomDirectory (3tiff)
• TIFFquery (3tiff)
• TIFFWriteDirectory (3tiff)
• TIFFSetDirectory (3tiff)
• Multi Page / Multi Image TIFF
• libtiff (3tiff)

---

👑 AUTHOR 👑

LibTIFF contributors 💖

---

⭐ COPYRIGHT ⭐

1988-2025, LibTIFF contributors

---

okay bestie that's the whole page, we ate and left no crumbs 💅✨ this was LibTIFF 4.7, dated Jun 27, 2026 — go read some directories, you've got this 🎀🫶