docs/parity-checklist.md: header from main with this PR's date and text; Histogram row gets this PR's clause; revision rows both kept
docs/whats-new.md: both entries, newest first
crates/ui-egui/src/panels/edit.rs: main split it into panels/edit/; the header call site stays in edit.rs and header_buttons, HeaderClicks and the overlap test are ported into edit/sliders.rs next to reset_tip. The reset_tip doc comment sits directly above reset_tip in the port.
Conflicts resolved:
- crates/engine/src/media.rs: main split it; the render and display-profile hunks are ported into media/render.rs
- crates/ui-egui/src/lib.rs, panels/detail.rs: main split them; alt_held is set in app/frame.rs, view_overlay and overlay_supports_window ported (panels/detail/window.rs)
- crates/ui-egui/src/tests_alt_preview.rs moved to tests/alt_preview.rs
- crates/pipeline/src/finish.rs, local.rs: main's code kept, sharpen_mask_weight and texture_sigma applied to it
- docs: both sides kept; summary counts from main (regenerated later)
The small HDR render of the last HDR drag is kept in Renderer. With HDR
switched off, dragging a slider still read it as the live histogram, so the
panel flipped back to the HDR layout. Read it only while an HDR edit is being
dragged. The LR-VIEW-HISTOGRAM row says so.
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>
Every output pixel goes through every eye, and nothing limited the list:
a sidecar, preset or agent with 100,000 eyes made one preview take hours.
The render resolves the first MAX_RED_EYES and redeye.add refuses more,
as Point Color does with MAX_POINT_COLORS.
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
On wasm32 a PRVW/THMB box or JPEG length near u32::MAX wrapped j + len and
start + size, so both bounds checks passed and the slice panicked (abort in
the web build). Use checked_add and bytes.get, and add a regression test.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ti8KemZbjE2ZgHgV1q1BM
The existing synthetic lossy RGB fixture tiles are re-declared grey by a
header edit (colour space RGB to Grey, dropping the 6-bit primaries field
a grey encoding does not carry, per the ColourEncoding bundle). Their XYB
frame data is unchanged, so they decode as one grey plane whose rendered
channels differ. The test checks decode against the gradient's BT.2100
luminance in the linear and sRGB curves.
Refs #275
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ti8KemZbjE2ZgHgV1q1BM
Lightroom Classic's HDR and panorama merges of monochrome raws store a
one-plane LinearRaw image as lossy (XYB) JPEG XL tiles whose codestream
declares a grey colour encoding (16-bit float with a linear curve, or
16-bit integer with the sRGB curve). Those were refused as "lossy JPEG XL
tile with a single colour plane", so the files opened preview-only.
A lossy grey tile is still coded as three XYB channels. It is now
restored like the RGB case: jxl-oxide renders linear sRGB (never the
declared encoding, which would clip), the single plane is the luminance
(CIE Y, D65) of that, then the declared transfer curve is applied.
One plane must be declared grey and three RGB; HDR curves, other white
points and intensity targets above 255 stay unsupported.
RENDER_CACHE_VERSION 70 -> 71: files that showed their embedded preview
before render from raw data now, under the same content key.
Refs #275
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014ti8KemZbjE2ZgHgV1q1BM
A photo that was given a creative or film profile cannot get back to its neutral look through the Profile section's reset, which is what the report describes as edits that refuse to go back to zero.
Make reset_section restore the whole profile (id and amount) when the Profile section is reset, so the section really returns to its default state.
Test: resetting_the_profile_section_restores_the_default_profile failed before the change and passes after.
aiongg