Handle HEIC/HEIF media import (image crate cannot decode it) #90
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Source: Audit section 3.
Context:
crates/bds-core/src/engine/media.rsSUPPORTED_IMAGE_TYPES includes image/heic and image/heif (matchingspecs/media_processing.alliuminput_formats), but thumbnails/dimensions go through theimagecrate (util/thumbnail.rsimage::open), which has no HEIC decoder — so a .heic import will be accepted as an image and then fail at dimension probe / thumbnail generation. bDS2 (Elixir, libvips-based) handles HEIC.Task:
specs/media_processing.alliuminput_formats (spec must match code either way; validate withallium).regenerate_missing_thumbnailsmust not loop forever on undecodable files.Acceptance: .heic import either produces thumbnails+dimensions like bDS2, or is cleanly rejected per updated spec; test with a heic fixture.
Implemented in
e9f2cdb. Added cross-platform pure-Rust HEIC/HEIF decoding with hpvcd, including orientation, clean-aperture display cropping, 8/10/12-bit conversion, alpha preservation, and a single shared decode for all thumbnail variants. Imports now store real HEIC/HEIF dimensions and generate the small/medium/large WebP plus AI JPEG artifacts. Added a real HEIC fixture and regression coverage for both extensions, display dimensions, and thumbnail outputs. Thumbnail repair now matches bDS2 by skipping SVG, continuing past undecodable images, and reporting processed/generated/failed counts through core, Lua, and CLI paths. Neutral review checked the issue, bDS2 thumbnails/file handling, and media/media_processing Allium rules. Verified with cargo machete, cargo clippy --workspace --all-targets -- -D warnings, cargo build --workspace, and cargo test --workspace (531 core tests passed, 1 explicitly ignored; all workspace tests passed).