[ Case study ]  Orkhan Mammadov · 2024–2025

How VISIONS Learned to Misremember

The making of VISIONS, from a March 2024 experiment in attention to 666 interactive paintings

Series introduction

In March 2024, I was on vacation in Thailand with my friend and colleague Slava Rybin. We were working on an experiment for my Derivatives by Genie project, and we started talking about how fragile human memory and attention are, and how we could make that fragility visible.

I work in AI and computer vision, and I joke that I now see everything the way a computer vision system does. It is a metaphor, but my eyes really do think closer to how these systems work. That is where the idea came from. I said to Slava: what if we take a painting, extract all of its parts with object recognition and dense captioning, and repaint those areas? Back then, the tools I knew for this were YOLO and DenseCap.

So we tried it. We exported the parts of a painting and generated new content inside each area. When I saw the first iteration, it was mind-blowing.

VISIONS became one of the most life-changing and technologically advanced projects I have ever worked on. Here is how we did it.

In the end, VISIONS grew into 666 interactive works, each starting from a different public-domain painting. A viewer can choose a detail, watch it change, go back, and follow another path. The painting seems to remember several possible versions of itself.

The project started as a rough experiment with a painting, an object detector, TouchDesigner, and an image-generation workflow. The plan for 666 browser artworks came later. Over twenty months, that experiment went through object detection, captions, segmentation, datasets, trained generative models, moving-image studies, spatial displays, sound, a large Python production pipeline, and a self-contained web player.

This series follows that path. Part I goes back to March 2024, and Part II looks at the experiments that widened the project through 2024 and early 2025. Part III explains the final image system in detail. Part IV shows how that system became an edition of 666 interactive artworks, and why its technical structure matters to the idea of memory.

[ FIG. 01 ]A 45-second teaser cut from original archive footage and recordings of the finished artworks.

---

[ PART I ]The question before the system

How VISIONS began in March 2024

Memory rarely works like an archive. When we remember, we rebuild a picture from fragments: a face, a color, a position, an emotion, a story we have repeated. Each time we rebuild it, something small can change. A detail disappears and another one arrives, and the rest of the memory makes the new detail feel as if it had always been there.

That instability was the starting point for VISIONS. I wanted to make an image that changes and leaves the viewer unsure of the line between seeing, remembering, and believing.

The earliest experiments were modest. Boxes moved over flowers, water, and fire, and each region became a temporary frame for attention. In mid-March 2024, the idea moved into paintings. TouchDesigner controlled the image and its timing, and ComfyUI generated replacements inside selected areas.

The first artistic rule was about time: change something inside a square, pause, then move somewhere else. Without the pause, the work would read as one continuous visual effect. The pause gave the viewer time to compare the image in front of them with a version they held briefly in memory.

The next step tied what the system saw to what it changed. Instead of writing every replacement prompt by hand, we let the system look at a region, describe what it thought it saw, and use that description to generate a new fragment. Once the fragment was in the painting, the system could look at the changed image again.

This created a recursive loop:

look → describe → replace → look again

A misread object could now become the instruction for a new image, and that new image could produce another misreading. The painting began to drift through a chain of machine interpretations.

[ FIG. 02 ]The main chronology. Related GAN, moving-image, depth, sound, and spatial branches fed into the investigation but are technically separate from the final interactive engine.

Evidence of an experiment in progress

I value the surviving March recordings because they are rough. They show the work becoming possible.

[ FIG. 03 ]Original development footage from 23 March 2024. The miniature painting accumulates local replacements while the TouchDesigner network and generation process remain visible.

One recording shows a miniature painting beside a TouchDesigner network. Crops move between components, and a local fragment becomes a figure, then a structure, then an accumulation of forms. Another recording shows two queued render components. Image generation was not instant, so it had to be coordinated with playback and recording.

Other files record the hours around the visible result: installing detection systems, handling callbacks, testing masks, fixing dimensions, and deciding when the system should wait. These technical problems shaped the rhythm of the artwork, because the time needed to generate an image became part of the time needed to look at it.

We tested several approaches in quick succession and talked about using DenseCap to describe regions. The packaged prototype used YOLO for detection, and we compared BLIP-generated descriptions with fixed prompts. The embedded ComfyUI workflow preserves an early DreamShaper inpainting setup with an LCM LoRA, five sampling steps, low guidance, and a small mask expansion.

These tools show that the final structure did not arrive fully formed. Each one answered a practical question:

• Where should the system look?
• How should it describe what it sees?
• How large should the editable area be?
• How long should the image remain still?
• What should happen after a replacement appears?

On 27 March, the prototype was packaged with the TouchDesigner project, detector files, setup instructions, and a six-minute walkthrough. The VISIONS pipeline was rebuilt several times after that, but the central gesture was already there: attention moves, a fragment changes, and confidence in the image weakens.

Why paintings

Paintings resist the machine in their own way. Their objects can be symbolic, stylized, incomplete, or hidden inside other forms, and computer vision often reads them less confidently than photographs. A hand can become a flower, fabric a landscape, and a shadow a body.

That ambiguity was useful. A public-domain painting also comes with cultural memory attached. We may recognize its period, composition, or emotional authority even when we cannot name it. A generated detail can borrow credibility from everything around it.

VISIONS began where two kinds of instability met: the machine could misread the painting, and the viewer could misremember it.

---

[ PART II ]The experiments that changed the work

From local replacements to a wider investigation, 2024–2025

After March, the project widened. We tested different source collections, object-finding methods, image models, and forms of presentation. Some of these experiments became essential to VISIONS, and others turned into related works. Some failed, and the failures showed what the project should avoid.

Learning how to choose a fragment

The first problem was selection. Whether a transformation is convincing depends on where it happens.

Crowded paintings gave us a lot to work with, but the overlaps were hard to handle. A single region might contain a face, a hand, fabric, an animal, and part of the background. Replace too much and the composition broke; replace too little and the result looked like a sticker. A useful region needed enough context to inherit the painting’s light, palette, and structure.

By autumn 2024, the experiments combined broader image descriptions, phrase grounding, object detection, similarity search, and segmentation. Pose and depth tests explored other ways of finding meaningful structure, and dataset tools searched and clustered paintings by their visual relationships.

[ FIG. 04 ]Original screen recording of a detection and segmentation pass over a set of genre paintings: boxes and labels first, then coloured masks. The file is dated 19 January 2025.

[ FIG. 05 ]Seven segmentation tests shared on 5 March 2025, shown uncropped. Each coloured region is a mask the system drew around a figure or an object.

One direction we abandoned cut out segmented figures and rearranged them on a new canvas. The archive records dissatisfaction with the composition. That failure showed that the tension was stronger when an unfamiliar fragment entered a familiar whole, so VISIONS moved away from collage and toward altering the internal evidence of an image.

TouchDesigner was where we controlled the system, and it also became a visual language. Boxes, contours, labels, connection lines, and pointer movement made the system’s attention visible. These marks staged a computational reading of the painting for the viewer; they were not a literal view into a neural network.

[ FIG. 06 ]A pipeline view dated 22 February 2025, with its original sound. Boxes, labels and masks move across one painting after another. The file name matches the pipeviz patches among the recovered TouchDesigner saves.

[ FIG. 07 ]Four short renders of a TouchDesigner network drawn as a graph, 3 April 2025. Operator names such as LoadBlob, LoadMask, MaskShape and RenderLabel show the patch loading object masks and drawing their labels.

[ FIG. 08 ]316 recovered TouchDesigner saves, February 2024 to October 2025, each placed by the mix of operators it contains. Colour shows the save date. The late blobs and visions families gather in their own region, away from the early experiments.

A project with several branches

In early 2025, the wider investigation included dataset visualization, generative-model training, image inpainting, video inpainting, feedback, depth, sound, and spatial presentation.

[ FIG. 09 ]Two of the twelve dataset-visualization renders from March 2025, side by side and muted. Their panels carry titles such as DATASET OVERVIEW, DATA BOX, LAYOUTS, POINT GRAPHS and DATASET DYNAMIC, and the small images are paintings.

The StyleGAN branch meant preparing and filtering image collections, and some paintings were expanded into vertical formats before training. The archive contains code, controls, raw latent sequences, and many rendered variations. This branch fed into Lost Memories from Latent Space.

Depth and feedback experiments led toward Rêveries. Their visual logic belongs to the same investigation of machine perception, but they work differently from the final VISIONS engine.

Moving images created another problem. Runway and Wan experiments animated paintings, while segmentation tests tried to follow objects through time. A replacement that looked convincing in one frame could lose its identity or shape as the image moved, so temporal consistency became its own research question.

[ FIG. 10 ]105 ComfyUI workflow copies, grouped into 26 distinct files, against the node types they use. FLUX Fill, Fooocus inpainting, upscaling and a Wan image-to-video workflow sit side by side in the archive.

[ FIG. 11 ]Three recordings from the TouchDesigner inpaint prototype, 4 to 6 March 2025. Each labelled object is masked and then repainted in place. Among the recovered saves, the inpaint patch was saved 752 times, more than any other.

We treated presentation as part of the work. Procedural grids divided screens into changing regions, data diagrams followed real node connections, and sound responded to tracked objects. We also tested language models as shader-writing partners. With virtual rooms, corridors, multi-screen layouts, and physical installations, we explored how a viewer might encounter these changing images at scale.

[ FIG. 12 ]Three spatial studies of the wider project, saved from Instagram and shown side by side without sound: a mirrored room, a corridor of paintings over a reflective floor, and a virtual room of fragments.

As of October 2026, an immersive VISIONS is on view at Art Club, the new media art museum at POST Houston. It is a site-specific installation made for the museum’s infinity room (Gallery 14, Level 1 North), where mirrored walls repeat the paintings, captions and wireframe traces in every direction. Visits are by timed ticket; details are on the exhibition page.

[ FIG. 13 ]VISIONS at the Istanbul Digital Art Festival in 2025, on a wall of six portrait screens. This is installation footage of the wider project, not the December browser player.

What survived into VISIONS

The final work kept several lessons from this period:

• A source image should remain recognizable long enough for a change to matter.
• The system’s interpretation should be visible, including its uncertainty.
• Local context is more important than an isolated mask.
• A transformation should open up new possibilities.
• The viewer’s attention should influence the order of events.
• Presentation, timing, and sound are part of the system, not decoration added afterward.

An April 2025 teaser announced 420 works, and the final collection became 666. The number changed because the form and scale of the project were still being decided.

[ FIG. 14 ]Five of the 94 per-painting recordings in the prototypes folder, dated 6 to 13 April 2025. Each one starts from a different source painting.

The decisive change was structural. Earlier versions produced evolving sequences, but the final work had to support choices: select another object, return to an earlier image, follow a different path. A linear animation could not do that, so the system needed a memory of its own history.

---

[ PART III ]How a painting learned to branch

The final VISIONS pipeline, one transformation at a time

In the final VISIONS system, nothing is generated when a viewer clicks. Generation happens earlier, during production, and the browser performs a prepared field of possible transformations.

[ FIG. 15 ]The production loop reads, changes, and reads the painting again. The delivered artwork starts once this loop is finished.

Working this way makes the artwork immediate and keeps control over its material. Each painting contains its source image, generated patches, object data, transition rules, and interface code, and the viewer explores this finite material in different valid orders.

1. Preparing a source

Each of the 666 works begins from a different public-domain painting. The final source set includes portrait and landscape images with different proportions.

The production code prepares an image at a controlled pixel area while preserving its aspect ratio. Later handover code includes a VAE encode/decode pass intended to make the original image’s texture sit more naturally beside generated areas.

In a historical account, the October production, the November repairs, and the December handover have to stay separate. The later code helps explain the system, but it may not match the exact configuration of every earlier render.

2. Building a working interpretation

The system finds candidate objects with several kinds of image analysis.

CLIP compares the painting with a vocabulary of text labels. Florence detects objects and grounds descriptive phrases in regions. MiniCPM writes a broader description of the scene, which gives more phrases to search for. SAM creates masks for the objects that are kept.

These models overlap and disagree. The code groups similar regions, compares labels to image crops, filters by size and quality, and gives each object two rectangles:

• an inpainting box, where the local replacement will be inserted;
• a context box, a larger surrounding area used to understand and generate the replacement.

The context box is important because a fragment needs the color, texture, structure, and objects around it. The mask helps identify and protect forms, and the larger crop gives the generator enough of the painting to produce a plausible continuation.

The resulting labels are the machine’s working interpretation and make no art-historical claim. Their errors are part of the material.

[ FIG. 16 ]The 58 objects the system found in VISIONS 001, each with its real mask, label and mask score. Blue objects were found in the source painting; pink, amber and white ones appeared only after earlier changes.

3. Choosing a valid object

The pipeline moves through an evolving graph. At any moment, the current state records which objects exist, and the system chooses an object that can be transformed in that state. Larger objects get more weight, but generation also avoids repeating a transition already produced for the same local conditions.

Before generating, Python reconstructs the current image from the source painting and any patches already active. This reconstructed image is what the next step sees.

4. Generating the local change

The selected object’s context window is cropped from the current painting, and the editable area is based on a padded rectangle. Masks for nearby objects that are still present protect overlapping forms.

Florence captions the local image. In the final production path examined in the archive, that short caption becomes the generation prompt. Earlier versions tried additional labels and retrieved tags, but that prompt-enrichment path is disabled in the later source.

[ FIG. 17 ]The 108 prompts of VISIONS 001 reduce to 40 distinct sentences. Placed by the words they share, they gather around men, women, children and the things they hold. The line follows the order of the transitions.

Python sends the context crop, mask, and prompt to ComfyUI. The production workflow uses FLUX.1 Fill [dev] with thirty steps and the settings preserved in the workflow. ComfyUI does the image generation, and Python controls the larger process around it.

The generated result covers the context crop. The system extracts only the required local rectangle and blends it back into the painting with a soft 32-pixel edge.

The model sees a larger context, but the artwork keeps a smaller patch.

[ FIG. 18 ]One real saved transition from decoded artwork 001. Grey marks the context window the model sees; white marks the smaller rectangle the artwork keeps.

[ FIG. 19 ]The same transition, separated into the layers the artwork stores: source, object boxes, masks, context and edit boxes, generated patch, and the patch in place.

5. Reading the changed image again

The changed area goes back through detection and segmentation, and the system may find one or more new objects near the change. Those objects get their own regions and masks, and they can become available in later states.

[ FIG. 20 ]Each arc runs from an object that was replaced to the new objects found inside its patch. In VISIONS 001, the 108 transitions revealed 40 objects that were not in the source painting.

The saved transition records:

• the selected object;
• the prompt;
• the relevant earlier patches;
• the patch coordinates in the atlas;
• which objects disappear;
• which objects appear;
• and the path used to reach that state.

[ FIG. 21 ]Every saved transition keeps its prompt. Here the 108 prompts of VISIONS 001 are written out as raw UTF-8 bits, one row per transition.

6. Why the order of changes matters

Say the viewer changes a figure and then an object beside it. The second replacement was generated in a context that already included the first patch. If the viewer reaches the same object by another route, its surroundings may be different.

VISIONS stores this dependency as local history. For a selected object, the system checks which earlier patches touch its context window, and a saved replacement is valid when that nearby history matches.

This keeps branching efficient. Instead of storing a full-resolution painting for every global combination, the work reconstructs the current image from one source and a set of local patches.

[ FIG. 22 ]All 108 saved replacements of VISIONS 001 laid over one source and averaged where they overlap. Brighter areas hold more alternatives; object 05, the curly hair, has seventeen.

[ FIG. 23 ]Two real initial transitions from artwork 001. Later choices can depend on the local history around the selected object.

The production target was 108 transitions per artwork. That number is a generation budget, not the number of global states and not the duration of a movie. Different valid orders can revisit and combine saved material.

[ FIG. 24 ]Seven hundred real pixels from each saved patch: on the left at their place in the painting, on the right as one stripe per transition, sorted by brightness. The stripes are the generated paint itself.

7. Performing the work in a browser

The final HTML package contains the source painting, a mask atlas, an inpainting atlas, state data, fonts, sound assets or synthesis code, and the bundled player.

[ FIG. 25 ]The browser loads prepared imagery and state. It resolves valid transitions and composites patches locally; it does not call the production models when the viewer clicks.

[ FIG. 26 ]What the player stores about VISIONS 001 as numbers: the 2,645 values in its state file, from object boxes and mask scores to the objects each transition adds or removes.

[ FIG. 27 ]The December player as text, one pixel per character, 1,890,795 in all. The fourteen modules written for VISIONS are marked in red within the full bundle.

When the viewer moves or clicks, the player finds the transitions available for the current state. It updates the object set, composites the matching patch, animates the reveal, and lets the viewer undo. When interaction stops, the pointer can keep moving through the available choices on its own.

Synthesized tones mark events such as selection, change, appearance, and reset. The sound belongs to the interface, not to the image-generation model.

So the browser is a performance space. It plays the prepared logic and imagery of the artwork locally and does not contact FLUX, Florence, CLIP, or SAM.

The artwork this article has followed, file 001, is on my website as VISIONS #666, and it runs below exactly as it does there.

[ FIG. 28 ]Live from orkhan.art. Move the pointer to see what the machine sees, click an object to remove it, and click empty space to go back. Token numbers run in reverse of file numbers, so file 001 is token 666. The site copy holds the same 58 objects, 108 transitions, source and atlases as the decoded file.

Open VISIONS #666 on orkhan.art

[ FIG. 29 ]Verified browser-player export: ten seconds, native vertical artwork dimensions, thirty frames per second, and no audio track.

---

[ PART IV ]Producing 666 unstable paintings

From one working system to an edition

A prototype only has to work once. For the edition, 666 different source paintings had to pass through analysis, generation, state construction, assembly, export, and checking. The production target of 108 transitions per artwork meant more than seventy-one thousand local generation calls across the collection.

[ FIG. 30 ]A pre-release teaser posted to Instagram, with its original sound. It ends on the line GET READY TO MISREMEMBER.

The archive records 71,482 transition rows in the initial production data. That is below the theoretical target of 71,928, because six runs ended short. Later folders preserve fixes, replacement material, metadata corrections, and revised player exports. The shortfall is not part of the concept. It shows how much practical work it took to finish a system at this scale.

[ FIG. 31 ]The initial launch corpus contains 71,482 saved transitions. The mathematical target, 666 works multiplied by 108 transitions, is 71,928.

[ FIG. 32 ]The same launch data, work by work: each column is one of the 666 works and each row one of its 108 transition slots. The six short runs leave the red gaps.

[ FIG. 33 ]A wall of finished works dated 10 October 2025: one painting is active in the centre while the others scroll past at the sides.

Production as part of the artwork’s history

The pipeline ran on GPU workers. ComfyUI generated the images, and Python coordinated jobs, saved progress, objects, patches, and transitions. TouchDesigner stayed the main environment for developing and recording the visual behavior, and the web player turned the saved results into distributable artworks.

[ FIG. 34 ]The final interactive system running in TouchDesigner on 17 October 2025, in the month before release, with its sound. The painting is Caravaggio’s Medusa, kept in its round format.

Each layer had its own job:

• Python organized perception, generation, history, and files.
• ComfyUI executed the image workflows.
• TouchDesigner developed the interactive and visual language.
• HTML and JavaScript delivered the final experience in a browser.

[ FIG. 35 ]1,319,074 operators across 316 recovered TouchDesigner saves, by type and date. The early saves change constantly; the later production patches settle into long, stable structures.

One screenshot cannot explain the work, because its form comes from the relationship between those layers.

Scaling up exposed problems that a single artwork could hide: duplicate sources, incomplete runs, mismatched metadata, missing seeds, changed model versions, and differences between the October production code and the December handover code. So preservation means keeping versions separate instead of collapsing everything into one supposedly final folder.

A finite work that feels open

VISIONS does not generate infinitely in the browser. Every visible replacement was generated and stored during production. The openness comes from how the viewer moves through the work: which detail they choose, which local history becomes active, when they return, and what they remember from the previous state.

This finite structure is important to me as an artist. The material and its boundaries are authored, but the work does not impose one montage. Each viewer composes a temporary version through their attention.

The source painting is the anchor and gives every replacement a world to enter. Because most of the image stays stable, the changed region can borrow authority from the whole. The viewer may know something changed without being sure what the original contained.

[ FIG. 36 ]Five of the 666 final 4K recordings, each 150 seconds long with sound, shown muted from the one-minute mark. Left to right: Bronzino’s The Holy Family (file 001, token 666), Vermeer’s Girl with a Pearl Earring, Goya’s Saturn Devouring His Son, Millais’s Ophelia and Fuseli’s The Nightmare.

[ FIG. 37 ]Four of the 666 different source paintings. The final set contains varied aspect ratios; “one painting with all its possible states” describes each work’s concept, not the collection’s source count.

[ FIG. 38 ]A clean artwork-only adaptation of VISIONS 008 for publication. It uses the original source and saved patches with a slower dissolve, removes the analytical interface, and is separate from the historical player.

OpenAI licensed an iteration of VISIONS that was never minted, and used it in a short film it posted on 23 December 2025.

Capability overhang means too many gaps today between what the models can do and what most people actually do with them.

2026 Prediction: Progress towards AGI will depend as much on helping people use AI well, in ways that directly benefit them as on progress in frontier models… pic.twitter.com/v2q6swfLhd

— OpenAI (@OpenAI) December 23, 2025

[ FIG. 39 ]OpenAI’s post on X. The licensed VISIONS iteration is on screen from 0:35 to 0:37 of the 1:03 video.

The archive as another memory system

The VISIONS archive contains thousands of TouchDesigner saves, ComfyUI workflows, code versions, render tests, datasets, presentations, audio experiments, browser files, and production outputs. It also contains false starts and contradictory plans.

[ FIG. 40 ]Every file in the archive census, 311,245 in all, by modification date and type. The bursts are copying and production periods; these are file dates, not authorship dates.

[ FIG. 41 ]The 761,447 files inside the archive’s ZIPs, by how much each one compresses. Images and video sit near the top because they barely compress; code, text and tables sit low.

That complexity is close to what the work is about. The project cannot be reconstructed from one “final” file alone. Its history is spread across fragments whose meaning depends on context.

So preserving the work means preserving relationships:

• which player belongs to which data;
• which workflow belongs to which production period;
• which experiment became another artwork;
• which visual was a real interface and which was an explanatory presentation;
• which number described a plan and which described the released edition.

[ FIG. 42 ]Twenty counts from the archive, each computed from its evidence file.

The March 2024 question is still the clearest thread through all of it: how fragile are memory and attention? The final work gives the viewer an image, lets them disturb it, and asks what they still believe was there before.

---

Credits

• Orkhan Mammadov: artist, creative director, AI researcher
• Slava Rybin: workflow development, motion graphics
• Marcin Ignac / Variable: web experience
• Farah Piriye Coene: art curator