[
https://issues.apache.org/jira/browse/TIKA-4861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr updated TIKA-4861:
----------------------------------
Component/s: detector
> 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
>
> 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)
