[
https://issues.apache.org/jira/browse/TIKA-4851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18109392#comment-18109392
]
ASF GitHub Bot commented on TIKA-4851:
--------------------------------------
Copilot commented on code in PR #3091:
URL: https://github.com/apache/tika/pull/3091#discussion_r3886272957
##########
tika-parsers/tika-parsers-standard/tika-parsers-standard-modules/tika-parser-image-module/src/main/java/org/apache/tika/parser/image/RawTiffParser.java:
##########
@@ -68,6 +69,11 @@
* Both classic TIFF and BigTIFF containers (allowed for DNG since spec
* version 1.7) are supported for preview extraction; for BigTIFF, EXIF
* metadata extraction is skipped until metadata-extractor supports it.
+ * <p>
+ * The largest preview is marked
+ * {@link TikaCoreProperties.EmbeddedResourceType#THUMBNAIL}, any smaller
+ * ones are {@link TikaCoreProperties.EmbeddedResourceType#INLINE} images
+ * (TIKA-4851).
Review Comment:
The class Javadoc states “The largest preview is marked … THUMBNAIL”, but
previews can be filtered out (e.g.,
maxPreviewLengthBytes/maxTotalPreviewBytes), so this reads like an
unconditional guarantee. Clarify that this applies to the previews that are
actually extracted, and that the ordering is based on embedded JPEG byte length.
This issue also appears on line 181 of the same file.
##########
tika-parsers/tika-parsers-standard/tika-parsers-standard-modules/tika-parser-image-module/src/test/java/org/apache/tika/parser/image/RawTiffParserTest.java:
##########
@@ -43,12 +43,27 @@ private List<Metadata> parseByName(String fileName) throws
Exception {
return getRecursiveMetadata(fileName, metadata);
}
- private void assertPreview(Metadata preview, int index, int width, int
height) {
+ /**
+ * The largest preview: the file's thumbnail, always emitted first.
+ */
Review Comment:
The helper Javadoc says the thumbnail is “always emitted first”. That’s true
for the current default extraction path, but it’s clearer (and avoids
overpromising) to describe this as the largest extracted preview that the test
expects to be first and marked THUMBNAIL.
> RawTiffParser: mark only the largest JPEG preview as THUMBNAIL
> --------------------------------------------------------------
>
> Key: TIKA-4851
> URL: https://issues.apache.org/jira/browse/TIKA-4851
> Project: Tika
> Issue Type: New Feature
> Reporter: Dominik Schmidt
> Priority: Major
>
> RawTiffParser (TIKA-4824) emits every JPEG preview found in the IFD chain and
> SubIFDs as an embedded document with tk:embedded-resource-type=THUMBNAIL, in
> IFD walk order. A NEF typically carries a 160x120 thumbnail in IFD0 and a
> full-size preview in a SubIFD, DNG and CR2 similar, so the first THUMBNAIL is
> usually the smallest one. A client that wants the representative image has to
> parse the dimensions of every preview and pick the largest, which is a
> format-specific special case again; every other parser that emits THUMBNAIL
> emits exactly one.
> Proposal:
> - Only the largest preview (by JPEG byte length, or by the IFD's
> ImageWidth/ImageLength when present) is marked THUMBNAIL and emitted first.
> - The remaining previews are still extracted, marked INLINE (they are
> renderings of the same image, not attachments), keeping the current
> thumbnail_N generated names or switching the smaller ones to an image_N
> prefix.
> Motivation for both tickets: a generic "first THUMBNAIL is the preview" rule
> across all formats in a downstream consumer (OpenCloud's Tika extractor).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
