* Honor CARGO_BUILD_TARGET in FreeBSD packaging for aarch64 release builds
package.sh took the arch from uname -m. The release VM is an x86_64 guest that
cross-compiles aarch64 with CARGO_BUILD_TARGET set, so an aarch64 build was
named freebsd-x86_64 and read binaries from the host target dir.
Read the arch from CARGO_BUILD_TARGET when it is set, and read binaries from
target/<triple>/release. Skip the man-page example and the --version run when
cross-building, since the aarch64 binaries cannot run on the x86_64 guest.
Unset CARGO_BUILD_TARGET keeps the old behavior.
* Reject unsupported CARGO_BUILD_TARGET and resolve host-tuple in FreeBSD packaging
Accept only x86_64-unknown-freebsd and aarch64-unknown-freebsd. Any other
target exits 2 before any build, so a non-FreeBSD target cannot be packaged
as an x86_64 FreeBSD archive.
Resolve cargo's host-tuple alias to the real host triple before choosing the
binary dir, so the path matches cargo's output.
* Skip the photocraft-cli --version run when CARGO_BUILD_TARGET is set
A target build's binary may not run on the host (aarch64 on the x86_64 VM),
and under set -e the smoke run would fail the release after the archive is
written. The native path (CARGO_BUILD_TARGET unset) still runs it.
Prebuilt binaries packaged with --skip-build failed when the example
wasn't built with them. The package now leaves photocraft-cli's man pages
and completions out with a warning, as a cross build without an emulator
does.
The FreeBSD tarball carries them in the ports layout: man/man1,
share/bash-completion/completions, share/zsh/site-functions and
share/fish/vendor_completions.d.
The man-and-completions example is built in the same cargo build as
the binaries (--bins --example), and package.sh runs it from the
target dir. With --skip-build it must already be built, or the script
says so and fails. A dry run builds nothing, so it leaves them out.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* packaging: use [[ for bash conditional tests (SonarCloud S7688)
SonarCloud flags every bare [ conditional in bash scripts under packaging/ as a reliability smell (rule S7688). Convert the flagged [ ... ] tests to [[ ... ]]: safer word-splitting and no glob surprises, same semantics for these string and file tests.
* packaging/web: parse size overrides as base 10 under [[
* Open HEIC/HEIF photos (#355)
iPhones save HEIC by default and Photoshop opens it; PhotoCraft had no
HEIF code, so .heic was missing from File > Open and failed to decode.
Add Format::Heif to photocraft-codecs, decoded by heic-rs (pure Rust,
forbid(unsafe), MIT OR Apache-2.0, wasm-ready): single pictures and
grid-tiled photos, 8-bit to U8 and 10/12-bit to U16, auxiliary alpha,
ICC, EXIF and XMP. The container's irot/imir/clap are applied and EXIF
Orientation is rewritten to 1, so photos are never turned twice. Limits
are checked against the declared size before decoding. Read-only (no
pure-Rust HEVC encoder), listed in ASYMMETRIC_EXCEPTIONS.
File > Open (desktop, web) and the batch list accept heic/heif/hif.
Tests compare against Apple's own decode and a 16-bit source, cover
orientation, metadata, limits and every truncation; fixtures from
heic-rs and pillow-heif are attributed in ATTRIBUTION.md.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* HEIF: pin heic-rs exactly and add a decode_heif fuzz target
Review follow-up: heic-rs is young and parses untrusted files, so pin it
(=0.1.1) and fuzz the HEIF path. The target covers both orientation
paths and is meant to run with -timeout so a hang is reported, not
only a panic. It is added to the CI fuzz matrix.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* HEIF: a heic-rs panic is a malformed-file error, not a crash
Fuzzing decode_heif found two out-of-range slices in heic-rs 0.1.1 on
malformed files:
- in its box parser (boxes.rs:130), reachable from a 72-byte file, even
through the metadata-only probe;
- during HEVC reconstruction (hevc/decode/recon.rs:70).
The background job path catches panics, but the synchronous ones (jobs
off, the CLI) did not. The HEIF codec now runs the decoder under
catch_unwind and reports a panic as CodecError::Malformed, as
gpu/health.rs already does around wgpu.
The fuzz target also calls heic-rs directly, so its panics still reach
the fuzzer. The 72-byte input is a regression test, which fails
without the guard.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* HEIF: move the decoder into an optional photocraft-heif crate
The heic-rs decoding from #372 now lives in `crates/heif` (photocraft-heif, standalone, depends
only on heic-rs =0.1.1): probe, decode with a pixel limit, container transforms, alpha, 8/10-bit,
ICC/EXIF/XMP and the catch_unwind guard, behind a small API of its own (Info, Options, Decoded,
Error). photocraft-codecs uses it behind a new non-default `heif` feature; the apps and
photocraft-io forward it. HEIF detection, extensions and mime stay compiled in, so without the
feature a HEIC file is still recognised and opening it is a clear "HEIC/HEIF support isn't
included in this build of PhotoCraft" error. `cargo xtask layers` allows exactly codecs -> heif
between standalone crates.
The fixtures are no longer committed: `cargo xtask corpus --heif` fetches them from heic-rs
(tests/fixtures, v0.1.1) and pillow-heif (tests/images) at pinned commits, verified against
xtask/heif-corpus.sha256 (same bytes as the PR's copies). The fixture tests run with
`--features corpus,heif` (`cargo xtask test-corpus` enables both).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Build CI and official binaries with HEIC support (--features heif)
CI test and clippy, the FreeBSD job, and the macOS, Linux (and Flatpak), FreeBSD, Windows and
web packaging all build with the `heif` feature; CI also tests codecs/io without it on Linux so
the "not in this build" path stays covered. `cargo xtask wasm` also checks photocraft-codecs with
`--features heif`.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Docs: HEIC open is an optional build feature, on in official builds
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Brandon Thomas <echelon@gmail.com>
Dylan M. Taylor
aiongg
IvanandClaude Opus 5.5
