[
https://issues.apache.org/jira/browse/TIKA-4861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18109540#comment-18109540
]
ASF GitHub Bot commented on TIKA-4861:
--------------------------------------
dschmidt opened a new pull request, #3099:
URL: https://github.com/apache/tika/pull/3099
Raw camera formats were detected by extension only; a stream without a name
was `image/tiff`, parsed by the plain TIFF parser, and the previews of
TIKA-4824 never appeared.
`RawTiffDetector` tells the TIFF-based formats apart by their image
directory, in this order: a `DNGVersion` tag means DNG; a vendor `Compression`
code names Nikon, Sony, Pentax or Samsung (ExifTool's rule); otherwise a CFA or
LinearRaw image plus the `Make` tag catches the uncompressed variants, while a
TIFF a camera wrote stays a TIFF. It reads a bounded prefix into memory, walks
the IFD chain and SubIFDs there, and resets the stream. RAF, RW2, MRW and the
other ORF byte orders get magic entries. `image/x-raw-samsung` did not exist,
it is added and handled by `RawTiffParser`.
No SRW, RAF, RW2 or MRW samples are in the repo, so those are covered by
signature bytes only; if someone has files they can share, I will add them.
https://issues.apache.org/jira/browse/TIKA-4861
> 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
> 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)
