[lightscape-jm]

What does this change?

Follows up the two notes from the #930 review.

1. CMYK pictures: you were right to ask. On a CMYK picture a Black box came out white, not black. Box copied an sRGB black image into the picture channel by channel, which gave C, M, Y and K all 0: white paper. What was under the box was still gone (every pixel inside it was the same white, black-ink text included), so nothing could be read back, but it wasn't the black box the user drew.

The fix is one line: the black image is made in the picture's own colour space (black.ColorSpace = image.ColorSpace) before it is copied in. sRGB black becomes C 0, M 0, Y 0, K 255 in a CMYK picture, and 0 in a grey one. I kept the composite rather than filling a crop of the picture, as the new image already copies every pixel and its alpha, and the change stays small. Happy to switch if you prefer the crop.

Pixelate and Blur were already right on CMYK (measured: the covered colour matches the original), and grey pictures were already black.

2. Extra channels (found while checking 1): a TIFF can carry channels beside its colours and alpha (extra samples, which ImageMagick reads as meta channels). Pixelate and Black box paste in an image that has only colours and alpha, so those channels kept the part pixel for pixel, and the saved TIFF still had them. Blur works on a copy of the picture and covered them already. A new ClearExtraChannels sets them to 0 inside the part after Pixelate and Black box. It copies the part out (which keeps every channel), clears them there and copies it back, so the picture's pixels are never written directly (the note on Pixelate says why). Pictures without extra channels are not touched. This one has been in Pixelate since the tool was added.

3. Comment wrapping: the comments and file headers that #930 added or changed in HideTool.cs, AreaHider.cs, Preset.cs and HideAreaSet.cs are rewrapped at 120, as are the others from that PR (HideCanvas.cs, HideWindowViewModel.cs, HideWindow.axaml, HideAreasTests.cs). Comments only; no code lines changed.

Type of change

• Bug fix
• New feature or improvement
• New format or engine
• Translation
• Documentation
• Build, CI or dependencies

How was it tested?

• dotnet format --verify-no-changes
• dotnet test: Core and the App Pixelate / blur tests pass, and the new test passes. On my Mac the same 6 Engines tests fail on unmodified main (FFmpeg without some encoders, LibreOffice).
• Tried it in the app (what you converted or clicked, and on which OS): macOS 26.6.2, Apple silicon. Measured through the image engine before and after the fix, on CMYK pictures built in code:

Picture	Before (inside the box)	After
CMYK TIFF, black-ink text on white	C 0, M 0, Y 0, K 0 (white)	C 0, M 0, Y 0, K 255 (black)
CMYK JPEG, black-ink text on white	C 0, M 0, Y 0, K 0 (white)	C 0, M 0, Y 0, K 255 (black)
CMYK TIFF, random noise	one value, white	one value, black
Grey JPEG and PNG	black	black (unchanged)

And on a TIFF with two extra channels of noise (sampled inside the part, original values left in each extra channel):

Style	Before	After
Pixelate	2,100 of 2,100	none: all 0
Black box	2,100 of 2,100	none: all 0
Blur	blurred already	unchanged

New tests (tests/Filee.Engines.Tests/HideAreasTests.cs):

Test	Checks
Extra_channels_of_a_tiff_keep_nothing_of_the_part (Pixelate and Black box)	a TIFF with RGBA and two extra channels, each its own noise: every extra-channel value inside the part is 0, and every channel outside the part is as it was. Fails on main (the original 184 is still there).
A_black_box_on_a_cmyk_picture_is_full_black_ink_and_its_text_is_gone (TIFF and JPEG)	a CMYK picture with lines of black-ink text, built in code: the output stays CMYK, inside the box is no C, M or Y and all K on the lines and between them (exact for TIFF, within JPEG's blocks for JPEG), and outside it is still white. Fails on main with 0,0,0,0.

Screenshots (UI changes)

None: the window draws boxes black already; only the saved file changes.

Checklist

• New UI strings are in all src/Filee.App/Assets/i18n/*.json files (none)
• New third-party code or binaries are listed in THIRD-PARTY-NOTICES.md (none)
• The PR does one thing (unrelated changes go in a separate PR)

🤖 Generated with Claude Code

[KnifeLemon]

Thanks for following up so quickly, @lightscape-jm, and for measuring instead of guessing.

• CMYK: making the black image in the picture's own colour space is the right one-line fix. Keeping the composite is fine; no need to switch to a crop.
• Extra channels: good catch. A TIFF's extra samples keeping the hidden part pixel for pixel is exactly the kind of leak this tool must not have. Copying the part out, clearing those channels and copying it back keeps the rule that the picture's pixels aren't written directly.
• The comments are rewrapped too.

CI is green. Merging.