[
https://issues.apache.org/jira/browse/TIKA-5042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18139113#comment-18139113
]
ASF GitHub Bot commented on TIKA-5042:
--------------------------------------
tballison commented on PR #3535:
URL: https://github.com/apache/tika/pull/3535#issuecomment-6666101154
Bot recs. Again, an example file would be great if it is synthetic or asf
2.0 friendly, but not required.
```
Must fix
1. Component name mismatch (Cr3Parser.java:79 vs :166). A bare
@TikaComponent turns Cr3Parser into the name
cr-3-parser; I confirmed this in the generated META-INF registry. But
the parser looks up its per-request config
under "cr3-parser". The result is that the name users put in
tika-config and the name the parse context checks
are different, so a per-request ImageMetadataConfig for this parser is
silently ignored. MP4Parser and Mp3Parser
hit the same thing and set the name explicitly. Fix:
@TikaComponent(name = "cr3-parser").
2. docs/modules/ROOT/partials/supported-formats.adoc was not regenerated.
It should gain a Cr3Parser /
image/x-canon-cr3 entry. TikaCLITest fails when that file is stale, so
CI should go red (checks are still
pending).
Should fix
3. Embedded previews have no resource name. RawTiffParser names its
previews with
EmbeddedDocumentUtil.setGeneratedResourceName (THUMBNAIL prefix for the
large preview, IMAGE prefix for the
smaller ones); emit() here sets nothing. That affects file names in
/unpack output. Easy to align.
4. testLengthBeyondTheBoxIsIgnored doesn't test the box bound. It writes
Integer.MAX_VALUE as the length, which the
64 MB cap also rejects. If you deleted the jpegLength > box.end - jpeg
check, the test would still pass. A length
of prvw.length + 10 would be a real test: it runs into mdat, the JPEG
still starts with FFD8, and without the
check the parser would emit a truncated or garbage JPEG.
Test gaps (minor)
- The Canon maker note block (CMT3, read starting in
CanonMakernoteDirectory) has no synthetic test. Only the
author's hand check against 14 sample files covers it.
- Every test calls Cr3Parser directly. Nothing checks that
AutoDetectParser now sends image/x-canon-cr3 to Cr3Parser
instead of the MP4 parser, which is the bug the PR fixes. One assertion
in the standard-package integration tests
would cover it.
```
> Canon CR3: emit the embedded JPEG preview as THUMBNAIL
> ------------------------------------------------------
>
> Key: TIKA-5042
> URL: https://issues.apache.org/jira/browse/TIKA-5042
> Project: Tika
> Issue Type: Improvement
> Components: parser
> Reporter: Dominik Schmidt
> Priority: Major
>
> CR3 files are detected as {{image/x-canon-cr3}} (TIKA-3991), but unlike the
> TIFF-based raws (TIKA-4824, TIKA-4980) they yield no preview: CR3 is an ISO
> base media file, so MP4Parser reads it and emits nothing, and
> {{/unpack/preset/thumbnail}} answers 204.
> The previews are in Canon {{uuid}} boxes:
> * a JPEG preview of 1620x1080 in the top-level {{uuid}} box
> {{eaf42b5e-1c98-4b88-b9fb-b7dc406e4d16}}, as a {{PRVW}} record (the JPEG
> starts 20 bytes after the {{PRVW}} tag)
> * a 160x120 JPEG thumbnail ({{THMB}}) inside the {{uuid}} box
> {{85c0b687-820f-11e0-8111-f4ce462b6a48}} in {{moov}}
> Emitting the {{PRVW}} JPEG as {{THUMBNAIL}} (and {{THMB}} as {{INLINE}}, as
> the TIFF-based raws do with smaller previews) would give CR3 a preview.
> Checked with the CC0 sample "Canon - EOS R6 - 3:2.CR3" from raw.pixls.us.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
