Compare images in the viewer

[SimonCropp]

Image files are compared as pictures rather than as text, wherever they turn up: a pair passed on the command line, or a move or delete the tray is holding. Previously they were read as text, which meant a pane of mojibake — and DiffEngine never routed one to the viewer at all, since its BinaryExtensions was empty.

An image is a side, not a mode

FileSide.Read (the renamed FileText) decides text or picture by extension. It has to be the extension rather than sniffed content, because the expected side of a brand new snapshot has no bytes to sniff and still has to render as a missing image rather than as empty text.

ImageRows then produces the same aligned Row lists DiffRows does — one row per property, each carrying its own side's value and coloured against the other, so a matching format reads unchanged and a differing size reads modified. An image comparison is therefore described by rows every head already draws.

Whether the two are the same file belongs to the pair rather than to either side, so it is the status line: images are identical, images differ, or only <file> exists, which is the normal state of a new image snapshot.

The picture is an enrichment on top

Pane.Image carries a path and the file header's dimensions. All three heads paint the picture under those rows — Windows with GDI+, macOS with ImageIO, Linux with raylib — so which formats draw is per platform while what the comparison says is not. A format a head cannot decode draws nothing and the rows still carry the comparison, which is the property the ASCII snapshots pin.

All three fit from ImagePane.Width/Height rather than from their own decoder, one blank line under the pane's rows, so the placement rule lives in one place instead of three.

Head	Drawn
Windows (GDI+)	.png .jpg .jpeg .gif .bmp .ico
macOS (ImageIO)	all seven
Linux (raylib)	.png .jpg .jpeg .gif .bmp

ABI

DEVIEW_VERSION 6: DeviewPane gained the picture. That widens an array element, so an older library would read every pane after the first at the wrong offset — this is a bump worth honouring. The rebuilt binaries are in this branch already (#752).

Notes

• Headers are sniffed by hand (ImageHeader) rather than by System.Drawing, which does not exist on macOS or Linux. Recognising the format and reading the size are separate answers, so a truncated JPEG stays a JPEG of unknown size.
• The extension list lives in DiffEngine and is linked into the viewer, so the tool registration and the renderer cannot disagree about what a picture is.
• Both image caches decode from a copy of the bytes and remember failures. GDI+ holds the stream it is handed, and a viewer keeping a handle on the received file is one that blocks the accept it exists to perform.
• Pixel baselines use a PNG built byte by byte with stored deflate blocks, because the pane prints the file's byte count and an encoder that packs differently on one platform would fail a baseline for an unrelated reason.

Outstanding

PixelTests.Images has no Linux or macOS baseline yet — this PR's first test.yml run is what produces them, as *.received.* artifacts to accept.

🤖 Generated with Claude Code