[
https://issues.apache.org/jira/browse/TIKA-4861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18111680#comment-18111680
]
ASF GitHub Bot commented on TIKA-4861:
--------------------------------------
tballison commented on code in PR #3130:
URL: https://github.com/apache/tika/pull/3130#discussion_r3936781953
##########
tika-parsers/tika-parsers-standard/tika-parsers-standard-modules/tika-parser-image-module/src/test/java/org/apache/tika/detect/image/RawTiffDetectorFuzzTest.java:
##########
@@ -0,0 +1,136 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.tika.detect.image;
+
+import static org.junit.jupiter.api.Assertions.fail;
+
+import java.util.Locale;
+import java.util.Random;
+
+import org.junit.jupiter.api.Test;
+
+/**
+ * Randomized boundary test for {@link RawTiffDetector}'s directory walk.
+ * <p>
+ * The detector runs ahead of every parser, and {@code Detector.detect}
declares
+ * only {@link java.io.IOException}: anything else it throws aborts detection
for
+ * the document and the remaining detectors never run. So the invariant is
simply
+ * that no throwable escapes, whatever the directories say.
+ * <p>
+ * Inputs are well-formed TIFF and BigTIFF headers whose offsets, counts and
+ * entry values are drawn from the arithmetic boundaries
> Content-based detection for TIFF-based raw camera formats (NEF, PEF, ARW,
> DNG, SRW) and for RAF, RW2 and MRW
> -------------------------------------------------------------------------------------------------------------
>
> Key: TIKA-4861
> URL: https://issues.apache.org/jira/browse/TIKA-4861
> Project: Tika
> Issue Type: Improvement
> Components: detector
> Reporter: Dominik Schmidt
> Priority: Major
> Fix For: 4.1.0
>
>
> Most raw camera formats are still detected by file extension only. Without a
> name, a stream is detected as image/tiff (or application/octet-stream for the
> non-TIFF ones), parsed by the generic TIFF parser, and the previews
> RawTiffParser emits as THUMBNAIL embedded documents (TIKA-4824, TIKA-4851)
> are never seen. Clients that upload without a reliable file name, such as
> tika-server callers sending a bare body, get no thumbnail for these files.
> Two groups:
> 1. Formats with a fixed signature that tika-mimetypes.xml does not match yet:
> Fuji RAF starts with "FUJIFILMCCD-RAW", Panasonic RW2 with "IIU\0" (a TIFF
> variant with its own magic number 0x55), Minolta MRW with "\0MRM"; Olympus
> ORF also occurs big-endian as "MMOR" and as "IIRS" next to the "IIRO" we
> match. These are magic entries only. Canon CR2/CR3 already have theirs
> (TIKA-3991).
> 2. Formats that are valid TIFF files: Nikon NEF/NRW, Pentax PEF/PTX, Sony
> ARW/SRF/SR2, Samsung SRW and Adobe DNG. No fixed-offset magic can tell them
> from a plain TIFF, and the Make tag alone is not enough: Nikon and Pentax
> cameras also write real TIFFs with their name in Make. ExifTool identifies
> these by content in two steps: a DNGVersion tag (0xC612) means DNG, and a
> vendor-specific Compression value (0x0103) in any IFD names the format (34713
> NEF, 32767 ARW, 65535 PEF, 32770 SRW). That misses uncompressed raws
> (Compression 1), which can be caught by the image data itself: a raw holds an
> image with PhotometricInterpretation 32803 (CFA) or 34892 (LinearRaw) in IFD0
> or a SubIFD (0x014A), where a plain TIFF has 2 (RGB); there Make picks the
> vendor.
> Proposal: a Detector in tika-parser-image-module, registered via SPI, that
> only acts when the TIFF magic matches and reads the IFD chain and SubIFDs
> with a bounded reader (the one in RawTiffParser already handles classic TIFF
> and BigTIFF), applying those rules in that order and returning
> application/octet-stream otherwise so image/tiff stands. A caller-supplied
> type or file name keeps precedence as usual.
> Both parts can go into one PR; the second is where the review effort is.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
