feat(webdav): extract thumbnails through Tika

[dschmidt]

Thumbnails for everything webdav should not decode in-process: raw camera images, audio cover art, the rendered first page of a pdf, the metafile an office document carries, the icon of a windows binary, and whatever else Tika learns next. One generic step, no format-specific code here.

webdav PUTs the file to Tika's /unpack/preset/thumbnail and hands the image on undecoded, because the generator reads formats webdav cannot. Needs Tika >= 4.1 with the thumbnail preset active in its config ({"presets": {"thumbnail": true}}, TIKA-4856): the preset ships inert, and until a config names it the route answers 404.

The thumbnail is written in the format the image carries, mapped through OC_THUMBNAIL_FORMATS. Its default writes an icon as a PNG, since no generator writes icons back and the fallback is JPEG, which has no alpha channel and would turn a transparent icon black. A file that carries no thumbnail answers 404 rather than 500, so clients cache it as "no preview" instead of retrying.

Config: OC_TIKA_URL, OC_TIKA_THUMBNAIL_MIME_TYPES, OC_THUMBNAIL_FORMATS.

Verified end to end against apache/tika:4.2.0-SNAPSHOT: a pdf renders its first page, an mp3 yields its cover, a windows .exe and .dll yield their icon with transparency intact, an mp3 without cover answers 404. Sharp icons also want apache/tika#3309, which orders an icon group largest first; without it the entry a decoder picks is whatever the resource compiler happened to write first.

What a client is told it can preview still comes from the static mime list, so the formats above are reachable by direct request but not advertised yet. #3210 answers that from the index.

Stacked on #3397.

[codacy-production]

Not up to standards ⛔

🔴 Issues 3 critical · 1 minor

Alerts:
⚠ 4 issues (≤ 0 issues of at least minor severity)

Results:
4 new issues

Category	Results
Security	3 critical
CodeStyle	1 minor

View in Codacy

🟢 Metrics 94 complexity

Metric	Results
Complexity	94

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[Copilot]

Pull request overview

Adds embedded JPEG preview extraction for TIFF-based camera RAW thumbnails.

Changes:

• Adds RAW MIME routing and documentation.
• Implements bounded TIFF/BigTIFF preview extraction with EXIF orientation.
• Adds extraction, hardening, orientation, and decoder tests.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
services/thumbnails/README.md	Documents RAW thumbnail support.
pkg/thumbnail/mimetypes.go	Registers RAW MIME types.
pkg/thumbnail/mimetypes_vips.go	Registers RAW types for VIPS.
pkg/service/grpc/v0/service.go	Handles missing RAW previews quietly.
pkg/preprocessor/rawtiff.go	Extracts and validates embedded JPEGs.
pkg/preprocessor/rawtiff_test.go	Tests RAW extraction and hardening.
pkg/preprocessor/preprocessor.go	Routes RAW types to the decoder.
pkg/preprocessor/preprocessor_test.go	Tests RAW MIME routing.
pkg/errors/error.go	Adds the missing-preview error.

Suppressed comments (4)

services/thumbnails/pkg/preprocessor/rawtiff.go:142

• This bounds check can overflow before it checks the untrusted BigTIFF offset. For example, a first-IFD offset near MaxUint64 makes ifdOffset + 8 wrap below dlen, after which the slice on line 147 panics. Use subtraction-based bounds checks (or explicit overflow checks) before slicing so a crafted raw upload cannot crash the service.

		if ifdOffset == 0 || ifdOffset+uint64(countSize) > dlen {

services/thumbnails/pkg/preprocessor/rawtiff.go:204

• arrayOffset is file-controlled, so both additions here can wrap. With an offset near MaxUint64, pos + offW becomes a small number and passes the check, then data[pos:] panics. Reject offsets using subtraction/overflow-safe bounds checks before reading the SubIFD array.

					pos := arrayOffset + j*uint64(offW)
					if pos+uint64(offW) > dlen || len(queue) >= maxIFDs {

services/thumbnails/pkg/preprocessor/rawtiff.go:117

• BigTIFF widens the entry value field, but accepted LONG values are still 4 bytes. Reading every BigTIFF field as Uint64 misreads a big-endian inline LONG as value << 32; the 8-byte stride used later also misreads LONG SubIFD lists. Decode values and array strides from typ, not only from the container, otherwise valid big-endian BigTIFF/DNG previews are missed.

	// readOff reads a 4- or 8-byte offset/value depending on the container.
	readOff := func(b []byte) uint64 {
		if bigTiff {
			return order.Uint64(b[:8])
		}
		return uint64(order.Uint32(b[:4]))
	}

services/thumbnails/pkg/preprocessor/rawtiff.go:261

• Returning true immediately on a DCT SOF marker does not establish that the JPEG is renderable: the SOF length may be invalid, or the stream may be truncated before any scan. Because extraction keeps only the largest candidate, a larger corrupt candidate can then mask a valid smaller preview and make Convert fail instead of falling back. Validate enough of the stream to reject malformed candidates, or try candidates in size order until one decodes.

		case 0xc0, 0xc1, 0xc2: // baseline, extended sequential, progressive
			return true

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated no new comments.

Suppressed comments (3)

services/thumbnails/pkg/preprocessor/rawtiff.go:201

• SubIFD pointers may use TIFF type IFD (13) and BigTIFF type IFD8 (18), but isLongType accepts only LONG/LONG8, so valid preview-bearing SubIFDs using the pointer-specific types are skipped. Extend the type-width/read helpers to accept IFD/IFD8; otherwise such DNG/BigTIFF files incorrectly report no preview.

			case tiffTagSubIFDs:
				if !isLongType(typ, bigTiff) {
					continue

services/thumbnails/pkg/preprocessor/rawtiff.go:221

• In BigTIFF the value-or-offset field is 8 bytes, so a SubIFDs value containing exactly two LONG offsets is stored inline. Treating every count > 1 value as an array pointer interprets those two offsets as one bogus uint64 file offset and misses both preview IFDs.

				// count > 1: the value field points at an array of count offsets,
				// each of the tag's own width (LONG 4B, LONG8 8B)
				arrayOffset := readOff(entry[valAt:])

services/thumbnails/pkg/preprocessor/rawtiff.go:196

• Valid TIFF encodes both StripOffsets and StripByteCounts as either SHORT or LONG, but these guards reject SHORT. A raw file whose only embedded JPEG is a single strip using SHORT values will therefore produce ErrNoImageFromRawFile. Please read scalar SHORT values as 16-bit values for both tags (and add a regression case).

				if isLongType(typ, bigTiff) && count == 1 {
					stripOffset = readVal(entry[valAt:], typ)
				}
			case tiffTagStripByteCounts:
				if isLongType(typ, bigTiff) && count == 1 {

[rhafer]

As much as I'd like to have previews for my raw images (DNG in my case), I'd really prefer us to get not into the business of creating/maintaining a TIFF parser (even with the help of AI). Especially given the experience with the recent security flaws in libvips (which were also TIFF related).

I see your PR to evanoberholster/imagemeta got merged. So using that might help.

And then there is #1128 which suggests to replace the embedded thumbnailer with something like https://github.com/cshum/imagor for better scalability and broader images format support. (Unfortunately AFAICS imagor does not extract the embedded previews though, but tries to render the rawdata)

I am not giving this a 👎 , but I think we should not merge without further consideration.

@butonic any thoughts on this?

[dschmidt]

Thanks for the considerate review, @rhafer :)

One more idea - tika has a concept of embedded files. I've already implemented audio artwork support using that mechanism.
Currently I'm trying to get the jpeg extraction from raw tiff into tika as well: apache/tika#3037

I mainly wanted both extractions to implement the thumbnails relationship on driveItems, but thinking about it in the context of your concerns and the possible move to imagor it makes me think:

We could pipe audio files and raw images from the thumbnails service to tika for preview extraction.
If that works out well enough, it could be a blueprint for piping regular images to imagor (or to whatever image server else).
This would even rid us of the vendored https://github.com/dhowden/tag (which seems dead and I had to patch and fork for #3208).

Having implemented the original audio artwork thumbnails feature, I can say I'd happily drop the built in support for something more maintained like tika. Moreover, we'd use the same mechanism as in the search service and the supported file formats and features would always align (unlike with a completely different code path like right now).

Thoughts?

[dschmidt]

I liked my idea so much, that I immediately wanted to give it a spin 😁

+395 now, the built in approach had +936 - I'm satisfied :D
Main downside, we need to wait for the tika upstream pr and a release :)
... but I'm patient, you know ... ;-)

What do you think?

[dschmidt]

Tika PR is merged 🙂