Images, drawing primitives, and visual-asset substrates in Genera

Layer and load boundaries

Both image substrate system declarations set :advertised-in nil. That is an important product boundary: application and color software can depend on the substrates even though the operator is not expected to select them as ordinary stand-alone products. Images, in contrast, is a patchable named system and creates the IMAGES: logical pathname host if it does not already exist.

The Images system declaration also shows that native persistence is not in the minimal substrate. It loads FEP I/O and dump support before the full image object, then adds rescaling, RLE, Peano color mapping, outline/wire operations, and user interface code. Thus a program can have the essential object or interchange registry without every higher-level image-management feature.

Dependency picture

This is not a strict single inheritance chain. Dynamic Windows graphics and the image systems cooperate through stream and raster protocols, while FrameThrower implements a physical screen path. CLIM is another client of the graphics and window substrate; it is not implemented by serializing a CLIM display as an Images object.

Registry and lifetime

Essential Image maintains two registries:

• a string-equal hash table maps names to image objects;
• an EQ hash retains images that are in the database or currently own bit arrays.

The public FIND-IMAGE-NAMED interface returns the first object when a name collision has produced a list. NAMED-IMAGES likewise exposes only the first object for each colliding name. Naming is therefore a convenience registry, not a globally unique persistent identifier scheme. Applications that overwrite a name can make an earlier object unreachable through the ordinary name chooser without immediately proving that all of its storage was reclaimed.

An image can discard raster arrays while retaining enough descriptor and source file information to reload them. The implementation distinguishes named or otherwise retained images from garbage candidates and can recursively discard derived images. This supports large image workflows on machines where keeping every full raster resident would be expensive.

Image types and storage

Every instantiable essential type includes the RLE mixin, although the actual RLE implementation arrives with Images. Public presentation choices expose 1b, 2b, 4b, 8b, RGB, packed RGB, and RGBA. The broader internal type list also includes palette and random-map variants and packed YUV.

The storage-width multipliers are not cosmetic. Code allocating, cropping, or displacing a packed RGB or packed YUV raster must translate logical width into the wider byte-array representation. Treating all image types as a rectangular array of one element per visible pixel would corrupt those formats.

Metadata and derived representations

The native descriptor deliberately preserves more than pixels. Its standard interesting properties include artist, author, credits, comment, copyright, creation parameters, date, owner, title, pixel aspect ratio, X and Y resolution, X and Y position, frame properties, and the frame used to make an icon.

An image may cache representations at other depths and organizations. The source-defined derived-property set includes 1b, 2b, 8b, RGB, 32b, packed RGB, packed YUV, an image icon, and 2b/4b/8b Peano and palette images. These are derived caches, not proof that the source file originally contained every form. Killing derived images or changing the source invalidates caches independently of the image's descriptive metadata.

The standard map set contains one-bit grayscale, two-bit color and grayscale, four-bit color and grayscale, 256-level grayscale, a standard false-color map, a primary-only map, and a primary false-color map. Canonicalization lets a saved descriptor name a standard map instead of serializing an equivalent map object.

Multiple frames

An essential image can hold multiple frames under integer or symbol identifiers other than T. Each frame can have its own width, height, selected properties, and raster components. Methods save the current frame's descriptor, restore a different frame, enumerate or map selected frames, and delete frames.

This is enough structure for image sequences, fields, or related frames, but it does not by itself define playback timing, animation semantics, or a movie file. Those claims require the consumer or format. TIFF and BIN may carry image sequences; a single multi-frame object may also be used without being animated.

The dynamic format registry

An IMAGE-FILE-FORMAT record holds a symbolic name, pretty name, description, read and write functions, stream element type, canonical pathname types, and one of three calling conventions:

• :RASTER: the codec exchanges an array plus dimensions and properties;
• :IMAGE: the codec exchanges one image object;
• :IMAGE-SEQUENCE: the codec exchanges a list of image objects.

Readability and writability are computed from the presence of the corresponding function, so command completion can offer only input or output formats. New systems can register formats at load time. The table below is consequently the complete set of static registrations found in the inspected installed source, not a promise about every patched or site-extended world.

The read/write commands contain conditional UI for PICT and MacPaint, and the Image Substrate system declaration names a machine-gated MAC-FILE-FORMATS module requiring MacIvory Support on 3600 or IMach. No such source or compiled module, and no PICT or MacPaint registration, was present in the inspected tree. The UI branch therefore records intended cross-platform support or distribution drift; it is not evidence that this Open Genera installation can decode those formats.

No PNG or JPEG DEFINE-IMAGE-FILE-FORMAT registration occurs anywhere in the inspected installed Lisp sources. Four JPEG files nevertheless occur as static CL-HTTP web-demo payloads. Data-file presence is not evidence that the Genera Images registry can decode that data.

Native .image, .dump, and .image-icon

Native persistence is a split representation:

1. The .image file is readable Lisp containing a MAKE-IMAGE descriptor. It records the image type, name, interesting properties, frame/binary map, and enough information to locate bulk arrays.
2. The .dump sidecar stores the actual two-dimensional component arrays in the dump block format. It can use image RLE and can load into arrays, windows, or a continuation without requiring every pixel to remain resident afterward.
3. An optional .image-icon sidecar contains a scaled menu image. Icon creation can be queued to a background process, and the source image records whether an icon file exists.

The descriptor and sidecars are jointly an image persistence format. Copying only the small .image file does not necessarily preserve its pixels, while a bare .dump lacks the full object description and intended metadata.

The loader supports deferred binary loading, selected frames, displacement into an existing raster, scaling during load, field selection, color-map conversion, and direct-to-window operation. This explains why the native form is split: Genera can inspect and choose images without keeping all large arrays live.

For preservation tooling, the .image descriptor should be parsed as data and the dump blocks decoded inertly. Evaluating an arbitrary Lisp descriptor is not necessary to recover its declared structure and is inappropriate for untrusted input. The same caution applies to BIN: its implementation writes dumped forms and reads them with the Genera binary loader. “Data only” in the format's own description distinguishes it from executable application state; it does not make an arbitrary BIN file safe to execute.

BIN is not native IMAGE and neither is a snapshot

BIN writes a sequence of image objects as dumped Lisp forms and notes each loaded image while the binary file is loaded. Native IMAGE writes a textual object descriptor and separate bulk-array data. TIFF and PostScript can also return multiple images, but through their own interchange semantics.

None of these forms contains the complete processor, process, package, window, filesystem, and heap state expected of a Genera world. Conversely, mining a .vlod can reveal resident image objects, but their arrays may be discarded, derived, cached, displaced into windows, or backed by external sidecars. See Recovering code and assets from Genera worlds for the world-level evidence boundary.

Complete statically defined command surface

The installed Color manual describes the ordinary display-window menu entries Color Demo, Erase, Refresh, Save Image, and View Image. Save Image opens the common load/save dialog; View Image presents the currently known images as an icon menu when icons are available. These window operations are service UI, not a separate “Images application” with its own editor keymap.

Public linkage API

The minimal linkage file exposes stable procedural access rather than requiring every caller to send flavor messages directly. Its API families are:

The full Images system adds object methods and functions for copying images to and from windows; direct-to-window loading; depth and packing conversion; composition, primary-channel combination, grayscale combination, and remapping; histograms; scaled-image caches; perspective/quadrangle transfer; Peano-space color quantization and palette optimization; RLE stream access; and lifecycle operations for rasters, derived images, frames, and the image database.

IMAGE-WIRES is not a wire-format module. It skeletonizes one-bit imagery, finds raster outlines, tests containment, nests outlines, makes an outline image, and redraws outline point sequences. This makes raster-to-geometry analysis part of the image system even though the result is not the retained entity model of the Graphic Editor.

Scaling and display limitations visible in source

The rescaler contains named pixel-aspect conversions for square-to/from PAL, HDTV, and Abekas conventions. It also supports rotation, transposition, perspective quadrilaterals, dithering, jitter, requested dimensions, output type, and frame selection. Scaled images and menu icons can be cached and built by a background worker.

The Image Substrate display method has a VLM-specific fallback that treats the main VLM screen as one-bit when it is not a common color-hardware screen. Its fallback paths impose limits:

• a deep image at a mismatched depth may be converted to a one-bit raster for an integer positive scale;
• scaling a deep image directly at the same depth is rejected on one path;
• unsupported type/depth/scale combinations signal that the image cannot be drawn that way.

These are implementation limits of the inspected release, not a general claim that all Genera displays are monochrome. Physical color controllers and their specialized :VIEW-IMAGE operations take different paths.

What BITBLT supplies

The BITBLT subsystem is loaded before fonts in the core system declaration. On 3600 hardware it selects LBITBLT; on IMach and VLM it selects generated inner loops plus the Ivory driver.

The Ivory implementation:

• decodes two-dimensional raster arrays and validates dimensional layout;
• signals distinct row and column bounds conditions;
• supports source-dependent and destination-dependent Boolean ALUs;
• chooses forward or backward traversal for overlap;
• exposes clipped, masked, unpacking, and vector variants;
• handles first- and last-word masks and source alignment; and
• uses a generated table of specialized inner loops rather than one generic per-pixel loop.

IBITBLT-LOOPS specializes families by ALU, source dependence, destination dependence, mask use, direction, wrap case, word alignment, and unrolling. The source includes instrumentation hooks for recording a loop call and inspecting which inner loop is used. That macro-generated structure is why a source search for one hand-written BITBLT body understates the actual implementation.

Ivory color support adds raster repacking and color-depth transfer paths, including one-to-many, eight-to-32, masked, and matte operations. Low-level TV drawing uses rasterized rectangles, lines, and triangles. These are primitives used by higher drawing layers; they are not stored picture assets.

Dynamic Windows graphics above BITBLT

GRAPHICS-GENERICS supplies a much broader drawing model:

• affine transforms, composition, inversion, translation, scaling, rotation, and physical-unit conversion;
• stream drawing state, scan-conversion modes, clipping, and coordinate modes;
• device and binary graphics generic registration;
• lines, arrows, rectangles, triangles, circles, circular rings, ellipses, elliptical rings, ovals, arcs, and rounded corners;
• polygons, triangulation, winding-rule fills, and path filling;
• cubic spline construction and drawing paths;
• patterns, stipples, images, and graphics presentations; and
• byte-row raster encoding and decoding helpers.

Dynamic Windows adds output history and presentations around these operations. CLIM adds its own portable drawing protocol and application model. Neither layer should be described as an image-file decoder simply because it can draw an image onto a stream.

The 43 built-in stipples

GRAPHICS-PATTERNS defines exactly 43 source stipples:

• 12 gray-family tiles, from 50%, 25%, and 75% through sparse 5.5% levels, including HES-GRAY; and
• 31 pattern tiles, including diagonal hatches, alternate grays, rain, tracks, dashed and solid lines, bricks, tiles, hearts, diamonds, parquet, and weaves.

A stipple records dimensions, repeat phase, optional gray level, name, and presentation name. Device-pattern abstractions can turn it into a raster source, PostScript pattern, two-color stipple, contrasting pattern, or device-conditional choice. The values are tiny procedural constants compiled from Lisp source, not external image files. Their editor is documented with the Bitmap Editor in Bitmap, stipple, and raster paint editors.

Hardware purpose

The installed Color manual identifies FrameThrower as a high-performance framebuffer for XL400 and XL1200 systems. Its basic Photon board has 8 MiB of video memory configurable as an eight- or 32-bit-per-pixel framebuffer. An optional AVP board adds video interfacing. Documented signal families include NTSC, PAL, 601, HDTV, and noninterlaced 1280 by 1024 at 60 Hz.

Photon provides programmable scanout, genlock, global and line-index pan/zoom, map modes, and an on-board integer processor. That processor implements ordinary window drawing and image-processing operations intended to accelerate software including S-Paint and PaintAmation. Offscreen memory allocators hold fonts, sheet bitmaps, and save-under arrays for pop-up windows.

The manual reports a very broad speed advantage for remote/on-board drawing over Lisp execution. That number is a vendor documentation claim, not a benchmark reproduced here. A screen's remote-drawing state can be queried or disabled, and COLOR:DESCRIBE-STATE is the documented diagnostic entry point.

Declared software organization

FrameThrower is restricted-source software and serially loads:

1. FrameThrower XL Interface;
2. board probing and hardware-definition support;
3. FrameThrower system, framebuffer, board, and Photon objects;
4. Photon hardware definitions and operations;
5. AVP hardware definitions and operations;
6. video and sync support;
7. main and vertical command queues;
8. screens, views, and Block Index Tables;
9. framebuffer bitmaps;
10. initialization; and
11. the command interface expected by callers.

The XL Interface itself contains an XL notification/confirmation/timing layer, XL operations, and VME/configuration I/O. It is not a portable X11 interface. The name refers to the XL workstation hardware side of the FrameThrower.

What the compiled operational modules establish

The purchased release contains source for the system declarations and sync programs, but the 16 top-level operational modules are VBIN-only. Symbol names and strings can establish a bounded capability inventory, not source-equivalent control flow.

Compiled-symbol evidence shows:

• FrameThrower systems containing framebuffers, Photon boards, AVP types, bitmap registries, command queues, and sync-program state;
• main and vertical queue operations for BITBLT, characters, strings, stipples, lines, rectangles, triangles, circles, and shaded triangles;
• color/image operations named for RGB maxima, expansion, shrinking, box, diffuse, noise, edge-finding, clamping, geometry edges, and unpacking;
• screen views flattened into video blocks and Block Index Tables, with global map mode, pan, zoom, and per-view line placement;
• bitmap addressing modes named pixel, packed, plane, and logical-pixel, plus bit offsets and multi-board forms; and
• XL VME probe, read, write, block access, configuration, interrupt, microload, and diagnostic operations.

These names corroborate the architecture described by the manual and system declaration. They do not prove every routine's complete semantics, argument contract, hardware revision support, or correctness. A full implementation audit remains TODO until corresponding source or actual hardware is available.

Sync-program corpus

Five source files contain 44 DEFINE-SYNC-PROGRAM forms:

After accounting for two names split by Genera font/style escape records, the targets are 31 Photon forms, nine NTSC/PAL-AVP forms, and four Universal-AVP forms. The same display dimensions can be registered separately for different targets, so 44 forms does not mean 44 unique monitor timings.

Boot and console deployment

An XL1200 single-monitor station can use FrameThrower from the device PROM and FEP in a reduced-capability monochrome-like console mode before Genera starts; Genera later enables the full color system. FEP options select FrameThrower as the color-system type, a color-system number, and a startup program. The number allows more than one FrameThrower to be distinguished. The selected startup sync program is stored through disk-label/FEP configuration.

This deployment path is why FrameThrower cannot be tested by casually calling a probe in an Open Genera VLM. The local VLM has no VME FrameThrower board, and a random VME probe would add no historical evidence. This audit made no hardware call and loaded neither FrameThrower system.

Conventional-file census

The census matched versioned Genera filenames by the embedded canonical suffix, for example *.xbm.*, rather than requiring that .xbm be the host filename's final characters.

No standalone file matched any of these native or interchange data families in the inspected tree: .image, .dump, .image-icon, GIF, TIFF, TIF, PPM, PBM, CBM, XIM, XWD, Utah RLE, PCX, IMG, TGA, VDA, ICB, VST, or WIN. Source files whose base name happens to be dump.lisp were not counted as .dump image payloads. The twelve files with a canonical .bin suffix belong to documentation patch directories; they were not classified as image-registry BIN merely because their host extension has the same letters.

This result does not include the content of the VLOD, remote file servers, logical IMAGES: directories outside the source tree, CD-ROM media, user files, or arrays generated at runtime.

The eleven conventional visual files

The flower descriptions in the example are application metadata, not reliable authorship or redistribution provenance for the JPEGs. This repository does not copy those files or render them into the museum documentation.

The VRML example source creates the first two files from simple-scene and colored-simple-scene, and the third from example3; it exports each path through CL-HTTP. This is structured 3-D scene data, not an Images raster format, and the source also defines computed scenes that need not exist as stored files. The contributed example carries a 1996 Rainer Joswig all-rights-reserved notice, so this repository records metadata and checksums without copying or rendering the scenes.

Documentation pictures

The SAB implementation defines a dedicated picture record. A picture contains a type, optional source filename, name, and one of two payload kinds:

• an eight-bit binary encoding for a static picture; or
• a symbol naming a drawing function for a dynamic picture.

The repository's current ignored Genera help extraction rendered 850 picture placeholders across 181 decoded documents. That proves a substantial embedded or referenced visual-documentation family even though it does not publish the picture bytes. The 801-file SAB census is a file count; the 850 placeholders are record occurrences and can include multiple pictures in one document.

Some system declarations refer to documentation .pic inputs, but no standalone .pic file appeared in the installed filename census. The content may be embedded in SAB, omitted from this distribution, or generated during document building. The census alone cannot choose among those explanations.

Fonts, cursors, stipples, and procedural output

Fonts are raster assets but have their own recovery and usage evidence. See FED and the Font Editor generations, the Genera font catalog, and extracting resident Genera fonts. Mouse cursors are glyphs rendered from the MOUSE font, not evidence of a separate vector-cursor file family.

The 43 Dynamic Windows stipples are source constants described above. Bitmap and Stipple Editor documents may create new raster and stipple objects, but those are application output, not preinstalled assets in this census.

Mandelbrot and other Color demos can load from logical paths such as IMAGES:MANDELBROT;*, yet no corresponding standalone image data appeared in the inspected source tree. That is evidence of an expected external or optional image library, not permission to infer its contents.

MUNCH, LEXIPHAGE, QIX, rotate demos, splines, and similar programs generate visible results procedurally. A screenshot of one run would be an observation of the program, not “the image file” stored in Genera.

What was tested

A fresh, isolated Genera harness session named d34-images, generation 1, booted the purchased Open Genera 2.0 / Genera 8.5 world on 2026-07-18. In Dynamic Lisp Listener 1, the audit typed one read-only form which called SCT:FIND-SYSTEM-NAMED with its loaded-only argument for:

• Essential Image Substrate;
• Image Substrate;
• Images;
• FrameThrower;
• FrameThrower XL Interface;
• PostScript; and
• Compression.

The first six were not loaded; Compression was loaded. The form returned NIL after printing the list. The probe requested no optional load or file I/O, and touched no FrameThrower package, VME probe, board object, or image registry.

This establishes only the starting state of this exact world. It does not mean the source systems are unavailable. It also explains why the audit did not claim a live named-image count or a live registry-format count: obtaining those would have required changing the world's loaded-system state.

Portable runtime provenance

Shutdown followed the separately documented VLM cleanup-stall path: the prompt was observed, confirmation was sent and accepted, cleanup progress was observed, then the bounded harness forced termination after the confirmed stall. The final record is forced-stopped, forced_stop: true, orderly_vlm_host_shutdown: false, and state_may_be_incomplete: true. save_world_performed and guest_checkpoint_created remain unknown; the harness did not invoke Save World or create a process checkpoint. The unchanged private world proves only that the world file bytes did not change.

The raw screenshot remains in the ignored session tree. It was not selected for publication because it shows only listener text reporting unloaded systems, not the visual operation of an image application or FrameThrower. Publishing it would add a decorative reproduction without materially improving the architecture claim. A future article that loads and visibly exercises Images should capture and review the specific UI state under the screenshot publication policy.

What can be extracted meaningfully

With a rights-appropriate local input, meaningful non-snapshot recovery targets include:

• .image object descriptors and metadata;
• .dump and .image-icon raster arrays;
• BIN image-object sequences;
• registered interchange formats;
• live or world-resident essential-image object descriptors;
• named-image registry entries and frame descriptors;
• standard and generated color maps;
• stipple constants and patterns;
• XBM host-window icons;
• stored VRML scene graphs;
• BDF/BFD and resident bitmap fonts; and
• static SAB picture encodings.

Dynamic SAB pictures require the named drawing implementation and suitable runtime context. Displaced window rasters and hardware-backed images may require reconstruction rather than a simple byte copy. Derived images should be linked to their source property where possible instead of catalogued as independent original works.

What this repository may track

This page tracks only original analysis, counts, non-secret checksums, and reproducible method descriptions. It does not reproduce licensed source, image descriptors, dump blocks, XBM pixels, JPEGs, VRML scenes, document pictures, fonts, VBIN payloads, or world contents.

Any future Genera extractor should be inert, verify exact input identities, and place all recovered data under an ignored build/ tree. It may track a catalog containing names, types, dimensions, checksums, and provenance if that catalog does not encode recoverable proprietary pixel or source content. Generated specimen sheets remain derived licensed content and must not be committed merely because PNG is a convenient viewing format.

Public System 46 assets follow a different boundary. The CADR source and its license can support tracked recovery tools and selected public derivatives, while third-party embedded photographs or scanned pages may still require a separate content-rights analysis. See the CADR visual-assets inventory.

Runtime screenshots are a third category: they are not extracted font, picture, or source payloads. A limited screenshot can be publishable as evidence under a specific fair-use or permission review, but this does not authorize publishing an extracted image or a decorative gallery.

Purchased release source groups

The group manifests below were computed from sorted lines of relative-path<TAB>byte-size<TAB>sha256, including a final newline, with paths relative to the installed sys.sct/ root.

Key source files

FrameThrower compiled boundary

The 16 top-level operational VBIN files total 587,652 bytes. A sorted manifest using basename<TAB>byte-size<TAB>sha256 has SHA-256 7a7cb057d2e36bdba810b07389cb9156e094c82c7597740e25b441a4fecd0fb0. Representative identities are:

Installed manual evidence

All Genera sources and manuals in these tables are local licensed artifacts. The checksums support identification and independent inspection by an authorized researcher; they are not download links.