[Ugoyo]

What does this change?

Filee reads and writes Paint.NET's own .pdn files, with its own reader and writer (Filee.Engines/Magick/PaintNet.cs, PaintNetWriter.cs). The document part is .NET binary serialization. It is read as plain data with System.Formats.Nrbf, which never creates the types it names. It is written record by record, in the shape Paint.NET 4.2 saves, which every later Paint.NET opens.

• PDN → PNG, JPG, WebP, PDF, …: the visible layers are merged with Paint.NET's own blend formulas (all 14 modes, layer opacity).
• PDN → PSD/PSB keeps the layers: names (also stored as Unicode luni), opacity, visibility and the blend modes both programs share, with the merged picture first. ImageMagick's PSD writer puts visibility in the wrong flag bit and locks transparency on every layer, so SetLayerFlags sets the flags after writing.
• Any picture → PDN: one layer named Background.
• PSD/PSB → PDN keeps the layers: each pixel layer at its place on the canvas. Names are read from the file's own records (PsdLayerRecords: the Unicode name, or the Mac Roman one), because ImageMagick damages any name that is not ASCII.
• A preset that changes the picture (resize, rotate, …) gives one merged picture.
• .pdn is graded specialist in Design & print, like .kra. Settings schema 79 teaches the images donut .pdn (renumber if another change takes 79 first).

Type of change

• New format or engine
• Documentation
• Build, CI or dependencies (System.Formats.Nrbf 10.0.14, MIT, dotnet/runtime)

How was it tested?

• dotnet format --verify-no-changes on the changed files
• dotnet test: new PaintNetTests (Engines; .pdn files built by PdnBuilder) and PaintNetFormatTests (Core) pass. The same 18 Engines tests and 1 Core test fail on main in my Linux environment (missing Pandoc/FFmpeg/LibreOffice, running as root). App tests were not run: the headless suite hangs there.
• Real Paint.NET 4.2 files (pypdn's MIT samples): the PNG matches the thumbnail Paint.NET embeds. The PSD checked with psd-tools has the right names, opacity, blend modes and visibility, and no lock. PDN → PSD → PDN gives the same layers, pixel for pixel. pypdn reads the written files.
• Tried in the app: a PSD → PDN file with 4 layers (accented names, Multiply 70 %, a hidden layer) opens in Paint.NET on Windows with every layer as expected.

Checklist

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

[KnifeLemon]

Thank you for this. A PDN reader and writer of our own, with layers kept both ways and checked in Paint.NET itself, is a big piece of work, and reading the serialized part with System.Formats.Nrbf is exactly the right call.

A few things to change:

1. "Merge images" breaks on .pdn files. CanWrite now says yes to pdn, and IImageJoiner.CanWrite is the same method. The built-in "Merge images" preset is "same as source", so when the first file dropped is a .pdn, JobQueue picks pdn as the target. ImageJoiner.Join then calls ImageEncoder.WriteImage(merged, …, "pdn"), and ToMagickFormat throws "ImageMagick cannot handle 'pdn'". The FitToSize call after it would throw too. Could you either write the merged picture with PaintNetWriter.Write in ImageJoiner, or keep pdn out of what the joiner can write, so it falls back to PNG? A test with two .pdn files on the merge preset would cover it.
2. Check a pixel budget before allocating. The reader caps the canvas only at Array.MaxLength. ReadFlattened and ReadLayer allocate the full canvas and the full layer before reading any chunk, so a tiny file whose header claims 23,000 × 23,000 allocates about 4 GB before it fails. With chunkSize = 1, seen becomes a 2 GB array too. For PDN → PSD, every layer stays in memory, and with up to 4,096 layers that compress to almost nothing, a small file can ask for a lot. Could you check layers × width × height against one limit before the first allocation (something in the range of FITS' 256 M samples), and refuse a chunkSize that is unreasonably small?
3. Small: ImageEncoder.MaxSide could get "pdn" => 65_535. Then a very wide picture is scaled down to fit, as JPG and WebP are, instead of failing in PaintNetWriter.Write.
4. Small: PsdLayerRecords.Read catches only EndOfStreamException. Past the end of the file, reader.ReadBytes(4) returns fewer bytes and ReadUInt32BigEndian throws ArgumentOutOfRangeException, so an unusual PSD fails PSD → PDN instead of using ImageMagick's names. Catching that as well, or reading with ReadExactly, would keep the fallback working.

We'll take care of the settings schema number when we merge (79 is wanted by a few open PRs), and of the specialist count together with #1390. CI hasn't run yet because first-time PRs need a maintainer to approve the workflow. We'll start it.

[Ugoyo]

Thanks for the careful review! All four are fixed in d12f4d9:

1. Merge images: ImageEncoder.WriteImage now writes PDN with PaintNetWriter, so two .pdn files on "Merge images" give one .pdn. The joiner doesn't fit a PDN to a size limit (it's lossless, like an animation), so the queue refuses one that is too large. Test: Two_pdn_merged_make_one_pdn.
2. Pixel budget: before anything is allocated, layers × width × height is checked against 256 M pixels (as for FITS), and against what the rest of the file can unpack to. A large layer in chunks smaller than 4 KB is refused. Tests: A_pdn_claiming_more_pixels_than_it_holds_is_refused_before_anything_is_allocated, A_large_layer_in_tiny_chunks_is_refused.
3. MaxSide: "pdn" => 65_535, so a very wide picture is scaled to fit. Test: A_picture_wider_than_paint_net_opens_is_scaled_to_fit.
4. PsdLayerRecords: it now reads exactly the bytes it asks for. A cut-off or unusual record gives no names, so ImageMagick's are used, instead of failing. Test: A_cut_off_psd_gives_no_layer_names_instead_of_failing.

Noted for the schema number and the specialist count, thanks for handling those.

[KnifeLemon]

Thank you, all four are in and each one has its test. Routing PDN through PaintNetWriter in WriteImage, and checking the budget before anything is allocated (with the packing-ratio check on top), is just what we hoped for.

We merged main into your branch, moved the .pdn migration to schema 86 (main has taken up to 85 since, with #1390 at 85), and set the specialist count for both new formats. Thanks again, this is a big addition!