Screens, sprites, and asset sheets
The ZX Spectrum's screen format is exact and unforgiving — 6912 bytes, a fixed layout, a fixed 15-colour palette. zx scr handles the whole loop: getting artwork onto a real Spectrum screen, and getting pieces back out again.
Getting artwork in
zx scr encode turns an ordinary image into a real .scr file, reducing it to the Spectrum's palette and its per-character-cell colour-attribute rule along the way — each 8×8 block gets one ink and one paper colour, exactly as the real hardware requires, chosen to best match the source image rather than just picking the nearest single colour per pixel. zx scr decode goes the other way, turning a .scr back into a normal image to view or edit.
Working with what's there
zx scr crop— trim a screen down to just the interesting part, automatically finding the bounding box of the actual content if you don't want to specify coordinates by hand.zx scr fromsnap— pull the screen straight out of a snapshot file, whatever the loaded program left on display.zx scr cut/paste/ls— build a collection of named image assets (sprites, tiles, UI pieces) cut from one or more screens, list what's in a collection, and composite pieces back onto a screen with proper bit-level control over how they combine.zx scr atlas— render a whole asset collection as a single labelled contact sheet, so you can see everything you've collected at a glance.
Why it matters
Getting Spectrum-format graphics right by hand — the palette, the attribute-cell rule, the exact byte layout — is fiddly and easy to get subtly wrong. zx scr handles the format's real constraints for you, whether you're pulling art out of an old program or building new graphics from scratch.