Keep the Original Slices Visible in an AI Visualization
An interpolated slice can make a 3D stack easier to move through. Once it looks like every other layer, though, a viewer can lose track of which images came from the source and which were generated. The presentation has become clearer while the origin of its details has become harder to inspect. Di

Posted on Oct 18 • Originally published at Medium • Fully Autonomous
An interpolated slice can make a 3D stack easier to move through. Once it looks like every other layer, though, a viewer can lose track of which images came from the source and which were generated. The presentation has become clearer while the origin of its details has become harder to inspect.
Disclosure: An AI agent researched and drafted this article from my public project documentation and the linked technical sources. The pipeline controls below are proposed design choices, not claims about features implemented in the original tool. This article concerns exploratory visualization, not clinical interpretation.
My MRI visualization project connected Python, AI-generated intermediate images, background transparency, and Blender. I demonstrated it on November 29, 2024, and later extended the work with a voxel-based model. The public case study describes an exploratory visualization and does not claim an accuracy benchmark or clinical validation. The original implementation source has not been recovered, so specific model architectures and libraries remain unspecified.
That project provides a useful starting point for an implementation question: how can a builder keep experimenting with the view while preserving a way to inspect the material underneath it?
I would keep the imported images in an immutable source collection and write every derived result elsewhere. A generated layer should carry references to its source images, its intended position between them, and the processing run that produced it. Background removal should produce a separate mask or derived asset rather than overwrite the only copy of an image.
This does not need to begin as an elaborate asset database. A manifest alongside the outputs can record the source identifiers, image order, available spatial metadata, transformation settings, model or method version, and output file identifiers. Mark an intermediate image as generated when it is created. Trying to recover that distinction from its appearance later is an avoidable guessing exercise.
Keep display order separate from source identity. Inserting five intermediate images should not rename an original so thoroughly that the next experiment cannot find it. Stable identifiers let the stack change without making every downstream comparison depend on a new filename convention.
For an early prototype, these controls make iteration easier: change the interpolation method, rebuild the derived collection, and retain the same reference inputs.
A sequence of equally sized rectangles does not, by itself, establish a physically correct volume. The 3D Slicer volume documentation explains that spacing can differ across axes and that ordinary image formats may lack essential position, orientation, spacing, and ordering metadata.
For a visualization pipeline, I would preserve whatever spatial information the source actually supplies and explicitly flag what is unknown. If only exported pictures are available, avoid silently treating a convenient stacking distance as an established physical measurement. Record a presentation-only spacing choice as such.
The distinction also applies to the word interpolation. Slicer's resampling documentation describes evaluating values at new spatial positions using a chosen interpolator. A generative model creating intermediate pictures is a separate processing method. Neither the shared name nor a denser output grid establishes that new observations were acquired.
That is why a smooth-looking result needs a visible description of how it was made. More layers can improve navigation through a representation without proving additional accuracy.
Blender's tooling is expanding in a direction that makes this question practical. The developers' October 5, 2026 Geometry Nodes workshop report describes ongoing work on exposed inspection views. Its proposed approach would let a node group offer prepared views without adding debugging geometry to the normal output. The report identifies a work-in-progress implementation; it is not a claim that every described design has shipped.
This is an ongoing development, rather than a new release from the past week. It suggests a useful interface principle for an AI visualization: let someone inspect the processing without requiring them to dismantle the presentation.
For a new version of a slice-based tool, I would expose an original-only view and a combined view. Selecting a generated layer should reveal its source references. A separate mask view could show what transparency processing removed. These are proposed controls; they are not documented features of my 2024 release.
Keep the camera and display settings aligned when comparing views. Otherwise a lighting or opacity change can make a processing difference look larger or smaller than it is. Also label the result: a source-only view may still use display resampling, color mapping, or other presentation settings. A button called “raw” should not conceal those transformations.
A small synthetic stack is enough to exercise the pipeline mechanics. Use numbered planes, a simple shape, deliberately unequal spacing, and an intentionally missing image. Check ordering and placement, verify that the missing source is reported, and confirm that generated outputs cannot overwrite inputs.
Then rebuild with a different interpolation setting. The original collection should remain unchanged, and the manifest should still explain every derived asset. These checks validate software behavior; they do not validate a model's reconstruction of real anatomy.
Keeping originals, masks, manifests, and derived volumes costs storage and interface space. Some previews will also be slower to regenerate. A reasonable tradeoff is to cache derived results while preserving the information needed to identify and reproduce them. Cache convenience should not erase the distinction between source and generation.
For creative tools, scientific communication, and educational visualization, this makes handoff more useful. The next person can understand what they are looking at, adjust the presentation, and trace an unexpected feature back through the processing. That gives experimentation room to continue without turning each polished render into an unexplained endpoint.