You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+9Lines changed: 9 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,14 @@
1
1
# Changelog
2
2
3
+
## 1.5.30 - 2026-07-14
4
+
5
+
### Fixed
6
+
-**Camera RAW thumbnails failed** (#99): Canon CR2 (and other camera RAW such as Nikon NEF, Sony ARW, Adobe DNG, Fujifilm RAF) died in `AssetGenerateThumbnails` with `tiff2vips: Old-style JPEG compression support is not configured`. Sharp's prebuilt libvips on macOS lacks old-style-JPEG support and has no dcraw/libraw loader, so it cannot read a RAW file's embedded image. The HEIC decode shim now also detects RAW by extension and pre-decodes it via Homebrew `vips` (fuller libtiff/libjpeg for TIFF-based RAW like CR2/NEF/ARW/DNG, plus libraw for the rest), the same libvips Docker Immich uses, before handing the result to Sharp. Works headless; OCR and face are untouched (RAW decode affects thumbnail generation only). Verified on an M4 Mac Mini with a real Canon CR2: bundled Sharp alone fails with the tiff2vips error, and with the shim it produces a valid thumbnail. Closes another macOS-only decode gap after the HEIC fix (v1.5.28). Reported by [@shtefko](https://github.com/shtefko).
7
+
- **Headless HEIC decode was silently falling back to `sips`**: Sharp's prebuilt libvips exports a bogus `VIPSHOME` (the GitHub-runner path it was built in, e.g. `/Users/runner/work/sharp-libvips/...`) into the process environment when it loads. The decode shim spawned the Homebrew `vips` with that inherited `VIPSHOME`, so `vips` looked for its loader modules (libheif for HEIC, the RAW loaders) in a nonexistent directory and failed with `VipsForeignLoad: ... is not a known file format`, falling back to Apple's `sips`. Because `sips` needs a logged-in GUI session, on a headless Mac the primary `vips` path (the entire point of the v1.5.28 HEIC fix) never actually ran, so HEIC thumbnails quietly depended on a desktop session. The shim now drops a `VIPSHOME` that points at a nonexistent directory before spawning a decoder, so `vips` uses its own compiled-in module path and decodes HEIC and RAW headless as intended; an intentional, existing `VIPSHOME` is preserved. Surfaced while adding RAW support and verified on a headless M4 Mac Mini (HEIC now decodes via `vips`, not `sips`).
8
+
9
+
### Performance
10
+
- The `vips` decode intermediate is now written as a lossless deflate-compressed TIFF (roughly 40% smaller than uncompressed) to trim peak memory and temp I/O when decoding large RAW frames. Pixels are unchanged; Sharp reads the deflate TIFF the same way.
Copy file name to clipboardExpand all lines: README.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -221,11 +221,13 @@ The native worker runs Immich's unmodified code. The ffmpeg and image processing
221
221
|**ML: Face recognition**| ONNX Runtime | ONNX Runtime with CoreML | Same model, CoreML acceleration. Numerically close embeddings. |
222
222
|**ML: OCR**| PaddleOCR via ONNX | Apple Vision framework (Neural Engine) | Different engine. Vision framework OCR is generally more accurate for Latin text, may differ for CJK. |
223
223
|**HEIC decode**| libvips built with libde265 | Homebrew `vips` (libvips + libde265), then Sharp | Sharp's prebuilt libvips on macOS has no HEVC decoder, so iPhone HEICs are pre-decoded by the Homebrew `vips` (the same libvips + libde265 Docker uses) before Sharp processes them. Works headless; pixels match Docker. Apple ImageIO (`sips`) is a last-resort fallback for a logged-in desktop only. |
224
+
|**Camera RAW decode**| libvips with fuller libtiff/libjpeg + libraw | Homebrew `vips`, then Sharp | Sharp's prebuilt libvips on macOS lacks old-style-JPEG and dcraw/libraw support, so Canon CR2/CR3, Nikon NEF, Sony ARW, Adobe DNG and other RAW originals fail thumbnail generation (`tiff2vips: Old-style JPEG compression support is not configured`, or a `multiband -> srgb` colourspace error). They are pre-decoded by the Homebrew `vips` (fuller libtiff/libjpeg for TIFF-based RAW, plus libraw for the rest), the same libvips Docker uses, before Sharp. Works headless; matches Docker. |
224
225
225
226
### What this means in practice
226
227
227
228
-**Thumbnails, previews, and video**: Identical to Docker. Same jellyfin-ffmpeg binary, same `tonemapx` HDR tone mapping, same output. VideoToolbox hardware encoding is faster but visually equivalent.
228
229
-**HEIC photos**: Thumbnails generate correctly. The default iPhone format (HEVC-coded HEIC, often tiled) is decoded by the Homebrew `vips` (libvips + libde265, a formula dependency) since Sharp's bundled libheif is AVIF-only. This works with no logged-in GUI session (a headless Mac Mini), and output matches Docker. Apple ImageIO (`sips`) remains a fallback but needs a GUI session, so it isn't relied on.
230
+
-**Camera RAW photos** (Canon CR2/CR3, Nikon NEF, Sony ARW, Adobe DNG, and other RAW formats): Thumbnails generate correctly. Sharp's bundled libvips on macOS can't decode these (no old-style-JPEG support, no dcraw/libraw), so they're pre-decoded by the Homebrew `vips` (fuller libtiff/libjpeg plus libraw), the same libvips Docker uses. Works headless.
229
231
-**CLIP search**: Search results are equivalent but not identical. A search that returns 20 results in Docker will return ~18-20 of the same results natively, possibly in slightly different order.
230
232
-**Face grouping**: Faces are detected and grouped correctly. The grouping boundaries may differ slightly (e.g., a borderline face might be grouped differently).
231
233
-**OCR**: Text extraction is at least as good as Docker for English/Latin text.
0 commit comments