TIKA-4851: RawTiffParser marks only the largest preview as THUMBNAIL

[dschmidt]

Every JPEG preview used to be a THUMBNAIL, so for formats that store the camera's small thumbnail ahead of the full-size preview (PEF) the first THUMBNAIL was the smallest one, and a client had to compare the previews to find the representative one. Now only the largest preview (by JPEG length, a reliable proxy for its dimensions) is the thumbnail-0.jpg THUMBNAIL and the smaller ones are INLINE image-N.jpg. The PEF fixture covers the case where the small one comes first in the file.

https://issues.apache.org/jira/browse/TIKA-4851

[Copilot]

Pull request overview

This PR updates RawTiffParser so that, when multiple embedded JPEG previews are present in TIFF-based RAW formats, only the largest preview is treated as the representative thumbnail (THUMBNAIL / thumbnail-0.jpg) and smaller previews are emitted as INLINE images (image-N.jpg). This improves client-side behavior for formats where the smallest camera thumbnail appears before a larger preview (e.g., PEF; TIKA-4851).

Changes:

• Sort embedded JPEG previews by byte length (descending) before emitting embedded documents.
• Mark only the largest preview as EmbeddedResourceType.THUMBNAIL (thumbnail-0.jpg); mark the rest as EmbeddedResourceType.INLINE (image-N.jpg).
• Update unit tests and add a CHANGES entry describing the behavioral change.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
tika-parsers/tika-parsers-standard/tika-parsers-standard-modules/tika-parser-image-module/src/main/java/org/apache/tika/parser/image/RawTiffParser.java	Sort previews by length and emit one THUMBNAIL + remaining INLINE previews; update class/docs accordingly.
tika-parsers/tika-parsers-standard/tika-parsers-standard-modules/tika-parser-image-module/src/test/java/org/apache/tika/parser/image/RawTiffParserTest.java	Update assertions to expect only the largest preview as THUMBNAIL and smaller previews as INLINE.
CHANGES.txt	Document the new preview/thumbnail semantics for RawTiffParser (TIKA-4851).

Suppressed comments (1)

tika-parsers/tika-parsers-standard/tika-parsers-standard-modules/tika-parser-image-module/src/main/java/org/apache/tika/parser/image/RawTiffParser.java:185

• The inline comment says “JPEG length is a reliable proxy for its dimensions”, which is stronger than what the code can guarantee (compression can vary). Reword to describe it as a heuristic/proxy used for ordering rather than a reliability claim.

        //the largest preview is the file's thumbnail and goes first; the
        //smaller ones (the camera's own thumbnail, intermediate previews)
        //are renderings of the same image and follow as inline images.
        //The JPEG length is a reliable proxy for its dimensions here.
        previews.sort(Comparator.comparingLong(Preview::length).reversed());

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

tika-parsers/tika-parsers-standard/tika-parsers-standard-modules/tika-parser-image-module/src/main/java/org/apache/tika/parser/image/RawTiffParser.java:207

• The inline resource naming uses count - 1, but count is incremented before shouldParseEmbedded(). If an EmbeddedDocumentExtractor skips any preview, the subsequent INLINE images can end up with gaps in numbering (e.g., image-1.jpg without an image-0.jpg), because the counter is advanced for previews that are not actually emitted.

Consider keeping the “thumbnail vs inline” decision based on the sorted preview index, while maintaining a separate inline counter that only advances when an inline preview is accepted (and undoing the increment when it’s skipped).

                    EmbeddedDocumentUtil.setGeneratedResourceName(previewMetadata,
                            EmbeddedDocumentUtil.EmbeddedResourcePrefix.IMAGE, count - 1,
                            JPEG_MIME);
                }
                count++;