A data line such as `nan 0 0` starts with a letter and was skipped as an
unknown keyword, so a file with enough other entries still parsed.
(CodeRabbit review on #2540.)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Mask ids come unchecked from develop.merge, sidecars (lc:settings) and
pastes. With a mask id of u32::MAX, next_mask_id() and Preset::apply
added 1 to it: debug builds panicked, release builds wrapped to 0, so
the second new mask got the same id as the first.
next_mask_id() now falls back to the lowest id no mask uses when the
highest is at the limit, and Preset::apply takes each preset mask's id
from it instead of counting on its own, so mask.add, mask.brushStroke,
mask.duplicate and presets with masks all get unused ids.
The sam3.safetensors on community mirrors (AEmotionStudio/sam3,
1038lab/sam3) is a conversion of Meta's original sam3.pt: its tensors
keep Meta's names, and its RoPE tables are C64. Renamed to
model.safetensors, it failed to load with "unsupported dtype
Some("C64")", which read like a LightCraft limitation.
Weights::open now lists a tensor of another dtype instead of failing
the whole file; reading it fails with the dtype error (LightCraft
computes RoPE itself and never reads those tables). Sam3::load_on then
checks the format: when the backbone's first tensor in Hugging Face
naming is missing and the file has Meta's detector.backbone. or
tracker. tensors, the error says it is Meta's original checkpoint and
that model.safetensors from facebook/sam3 in the Hugging Face format
is needed. docs/ai-masks.md says so for installing by hand.
Render cost is pixels x samples (CPU and GPU), and only mask.add / mask.update capped the list, so a
sidecar's lc:settings, a preset, develop.merge, render --settings or a catalog / history load could
carry thousands and stall a render or lose the GPU device. MAX_COLOR_RANGE_SAMPLES moves to
lightcraft-develop and ColorRange::samples deserializes through a capped visitor (the first 64 in
order, the rest skipped as IgnoredAny); the CPU and GPU renders also take at most 64 for settings
built in code.
UPDATE_APP (native builds; craft-update is a native-only dependency) carries our 128 px icon and accent (#f2a516, its colour in ArtCraft Launcher). The updater, the self-update
helper and craft-update's startup prompt all get them through crate::UPDATE_APP; the
prompt draws the icon, the accent and "by ArtCraft" (craft-update's default developer).
craft-update is pinned to storytold/craft-libs main at 1065653e7 (#434).
Clippy fixes for Rust 1.99 in untouched code (same logic):
- crates/engine/src/cmd/export.rs
- crates/ui-egui/src/dialogs/rules_editor/rules_move.rs
- crates/ui-egui/src/panels/detail.rs
AGENTS.md (and CLAUDE.md where present) gets a CI workflows section: workflows only call
craft-common-actions at @main, with no other jobs; feature and fix PRs don't touch CI and
link or open a craft-common-actions issue (a PR only for a small fix that is safe for
every app and does not increase CI time); legacy jobs
aren't added to and move only as their own task, staying until a shared workflow runs them.
windows-arm64.yml moves from its SHA pin to @main. The pinned revision is on
craft-common-actions main and the workflow (and the actions it calls) is identical
there, so nothing changes in behaviour.
The test's stored image and LightCraft's size of the photo were both 20 × 10, so
fitting radials to the photo's size instead of the stored image went unnoticed.
The photo is now already in the library at its shown 10 × 20, as a vertical shot
is.
The catalog's XMP is merged before the develop row, and its masks were taken as
they are, on the stored image: when the row has no masks of its own to replace
them, they stayed a quarter turn off on a vertical shot. They now go through the
same frame as the row's. A radial is fitted to the stored image before it is
turned, so its radii swap with the stored aspect and not the sidecar default.
Updating a photo already in the library keeps its Rotate Left / Right and Flip in
LightCraft, which LightCraft draws masks after, but the masks went through the
catalog's orientation only: an upright photo turned right in LightCraft got an
unturned gradient. They now go through the catalog's orientation and then the
photo's own.
With Show Pins on, Object and Describe masks had no pin on the photo, so they could only be picked in the Masking panel. An Object component's pin now sits at its first click and a Describe component's in the middle of what its segmentation selected. Clicking the pin selects the mask; dragging it changes nothing and adds no History step. Subject, Sky, Background, People, Landscape and the range masks still have no pin.
A hostile segment now lays only its end point, so five of them no longer
fill the stroke budget. The test asserts the endpoint-only count directly
and proves that a stroke which has spent its count takes no more through
push_dabs_counted, which tracks the budget across buffers.
aiongg