Enhancement: detect TGA 2.0 via footer signature in guess_format

[gitfool]

Summary

guess_format cannot identify TGA files, which is expected and documented in the source ("TGA is not supported by this function"). TGA has no header magic, so it does not fit the front-of-buffer MAGIC_BYTES table.

However, TGA 2.0 files do carry a fixed signature: an 18-byte footer, TRUEVISION-XFILE.\0, at the very end of the file. This proposes an optional fallback that checks for that footer after the existing prefix scan misses, so guess_format can recognise TGA 2.0 while leaving the front-prefix table untouched.

Why this is worth considering

I maintain a tool that processes a large library of files containing embedded images of mixed formats. Sniffing by content (not extension) is essential because extensions are unreliable. Across the corpus, TGA is the only format guess_format fails to identify; the images decode fine once the format is forced via load_from_memory_with_format(_, ImageFormat::Tga).

Checking real files: every TGA in the corpus (17 images across 6 sources) carries the TGA 2.0 footer. None were header-only 1.0 files. So a footer check would have resolved 100% of the misses.

Scope and honesty about limits

This only helps TGA 2.0. TGA 1.0 has neither header magic nor a footer and stays genuinely unsniffable by any content-based method, so this is a partial solution for the format as a whole. The upside is precision: the footer is a fixed, spec-defined signature, so matching it should not produce false positives.

Spec reference

Truevision TGA File Format Specification 2.0 defines the 26-byte footer whose final 18 bytes are the fixed signature TRUEVISION-XFILE. followed by a null terminator. See the Library of Congress format description (fdd000180) and the Wikipedia summary of the Truevision TGA footer.

Design note

The current guess_format_impl iterates a front-of-buffer prefix/mask table, which does not fit an end-of-buffer check. The public guess_format receives the whole &[u8], and its doc comment already notes it is "not to be trusted on the validity of the whole memory block", so a tail scan is compatible with the current contract. I recognise the front-prefix structure is deliberate and a footer scan sits outside it, so a fallback branch (only reached when the prefix scan returns None) would keep the existing path untouched. It would not help streaming callers that lack the file tail.

Offer

Happy to send a PR adding a footer-signature fallback if the approach is welcome. Wanted to check the design direction first, since it steps outside the front-prefix model. If you would rather leave guess_format as is and keep TGA detection a caller responsibility, that is completely understandable.

[RunDevelopment]

Not sure if this is the best direction.

Right now, guess_format has the nice property that it's "free" in terms of IO operations (see #2950). Reading the end of the file obviously incurs a cost that all formats would have to pay, not just TGA.

---

I always thought that the TGA problem could be solved with heuristics. While TGA doesn't have magic bytes, not all sequences of bytes are valid TGA headers. For example, the second byte can only be 0 or 1 (arguably). Similarly, other header fields also have values that they cannot or are very unlikely to assume. For example, width and height probably aren't zero. So by rejecting all byte sequences that cannot or are unlikely to be TGA headers, we can be fairly certain that what we're left with are valid TGA headers.

Integrating heuristics into guess_format is fairly easy as well. Basically, we check for known magic bytes as before. If we can't find a match, check a list of format-specific heuristics (currently only TGA).

[gitfool]

Fair point, and #2950 makes the case well. The footer check breaks the "free" I/O property, since every caller would pay for a tail read just so TGA can be sniffed. I'll concede that.

The heuristic idea gives me more pause. The best it can ever return is "maybe TGA." A header check is a rejection filter, not a signature, so it can only say the bytes aren't inconsistent with a TGA header, never confirm one. Every other entry in MAGIC_BYTES is a positive identification, and "maybe" isn't much better than the current "unknown" for a caller that needs to be sure. Add the false-positive risk and I'm not convinced it earns its keep.

For my own use I can afford the stronger check anyway. I'm not I/O-bound, I already hold the whole buffer, so I'll verify the TGA 2.0 footer signature on my side and force the decode. I was mostly curious whether it could be upstreamed, but it sounds like leaving guess_format as it is makes the most sense. Thanks for thinking it through.