SixLabors/ImageSharp · error · InvalidImageContentException
The BigTIFF directory entry count exceeds the available…
Error message
The BigTIFF directory entry count exceeds the available data.
What it means
During BigTIFF EXIF parsing, ReadValues64 validates that the declared directory entry count can physically fit in the remaining data (20 bytes per entry plus an 8-byte next-IFD offset). If the count is larger than the available bytes can hold, the file is malformed and an InvalidImageContentException is thrown to prevent reading garbage or looping excessively.
Solutions
- Treat it as corrupt input: catch InvalidImageContentException around Image.Load and reject or quarantine the file.
- Re-export/repair the file with a trusted tool (e.g. libtiff's tools, ImageMagick) before processing.
- If it happens on files your pipeline produces, audit the BigTIFF writer to ensure entry counts and IFD offsets match the actual data written.
Example fix
// before
using var image = Image.Load(path); // throws on malformed BigTIFF
// after
try
{
using var image = Image.Load(path);
}
catch (InvalidImageContentException ex)
{
logger.LogWarning(ex, "Malformed BigTIFF rejected: {Path}", path);
} Defensive patterns
Strategy: try-catch
Try / catch
try { using var image = Image.Load(path); }
catch (InvalidImageContentException ex) when (ex.Message.Contains("BigTIFF"))
{ /* mark file corrupt / attempt repair with an external tool */ } Prevention
- Validate BigTIFF inputs at ingestion (identify + size checks) before processing.
- Quarantine files that fail metadata parsing instead of retrying them.
- If you write BigTIFF, assert that IFD entry counts match bytes actually written.
When it happens
Trigger: Loading a BigTIFF image whose EXIF/TIFF IFD declares an entry count exceeding (remainingDirectoryBytes - 8) / 20 — i.e. corrupt or truncated files, wrong offsets, or count fields pointing beyond the buffer.
Common situations: Decoding damaged/truncated BigTIFF files; files edited by tools that wrote inconsistent IFD counts; fuzzed or maliciously crafted images (this check is an anti-DoS guard).
Understand the failure class
Background: Schema validation failed / invalid input schema: payload rejected because its shape doesn't match the expected schema — this error's family across 28 libraries.
Related errors
- Data type is not supported.
- Invalid parametric curve type of
- Invalid curve segment type of
- Input string is not in the correct format.
- Input string length must be a multiple of 2
AI-assisted analysis of SixLabors/ImageSharp@59ce6af6fc (2026-09-13).
Data as JSON: /api/errors/a82e64c01bf38643.
Report an issue: GitHub.
Appendix: source
Thrown at src/ImageSharp/Metadata/Profiles/Exif/ExifReader.cs:231
{
this.ReadValues(values, (uint)subIfdOffset);
}
}
}
}
protected void ReadValues64(List<IExifValue> values, ulong offset)
{
DebugGuard.MustBeLessThanOrEqualTo(offset, (ulong)this.data.Length, "By spec UInt64.MaxValue is supported, but .NET Stream.Length can Int64.MaxValue.");
this.Seek(offset);
ulong count = this.ReadUInt64();
// Each entry occupies 20 bytes and the directory ends with an 8-byte next-IFD offset.
long remainingDirectoryBytes = this.data.Length - this.data.Position;
if (remainingDirectoryBytes < 8 || count > (ulong)((remainingDirectoryBytes - 8) / 20))
{
throw new InvalidImageContentException("The BigTIFF directory entry count exceeds the available data.");
}
Span<byte> offsetBuffer = stackalloc byte[8];
for (ulong i = 0; i < count; i++)
{
this.ReadValue64(values, offsetBuffer);
}
}
protected void ReadBigValue(IList<IExifValue> values, (ulong Offset, ExifDataType DataType, ulong NumberOfComponents, ExifValue Exif) tag, Span<byte> buffer)
{
this.Seek(tag.Offset);
if (this.TryReadSpan(buffer))
{
object? value = this.ConvertValue(tag.DataType, buffer, tag.NumberOfComponents > 1 || tag.Exif.IsArray);
this.Add(values, tag.Exif, value);
}
}View on GitHub (pinned to 59ce6af6fc)