Images, Invention and a Life in 3D

Just Watching on a Big 3D Screen in my Bedroom

By Dr Thomas Judge · 26 September 2026

Stream to 3D is Windows software that converts ordinary 2D video and live sources into stereoscopic 3D for VR headsets and other compatible 3D displays. Video processing runs locally on the PC.

“I see images. I see problems in them. And I invent ways of making them do more.”

A few nights ago, I was lying in bed watching one of my favourite shows on what appeared to me to be an enormous 3D screen.

I was using Stream to 3D's AI-assisted Depth Guided conversion with Virtual Desktop. The screen looked perhaps 200 inches across to me, yet passthrough meant I could still see my bedroom around it, including my feet at the end of the bed. For a while it felt like having a private 3D cinema suspended in an ordinary room.

And, appropriately enough, I was actually watching Star Trek.

That was the moment when the name of my website, iwantaholodeck.com, felt particularly apt.

For anyone unfamiliar with Star Trek, a holodeck is essentially the ultimate immersive environment: a room capable of creating convincing, interactive simulated worlds around the people inside it. In the series it can become almost anywhere, from a forest or city to an entirely fictional world, and is used for recreation, training and storytelling. StarTrek.com has a useful explanation of the idea and what a real holodeck might involve.

The original Star Trek first appeared in September 1966; I was born the following month. We are almost exactly the same age. The holodeck in the form most people now recognise arrived in the 1987 pilot episode of Star Trek: The Next Generation, Encounter at Farpoint. It first aired that September, just as I happened to be starting my final-year, heavily 3D-oriented project at Warwick.

That project involved writing software to construct three-dimensional models and generate changing perspective views for physical holograms. At almost exactly the same time, Star Trek was imagining a room in which computation and imagery could create an apparently real world around you. I was not trying to build a holodeck, but the coincidence is rather wonderful.

Star Trek has always been escapism for me, but optimistic escapism. The optimism was never only about technology. It imagined a future in which people had become better at living and working together, and in which exploration, curiosity and cooperation were treated as strengths.

The technology was part of the same optimistic picture. It expanded what people could explore, understand, create and experience. The Enterprise computer could be talked to; the holodeck could make imagined worlds experiential; instruments revealed things that people could not otherwise see. What appealed to me was not simply clever machinery, but the idea that technological and social progress might reinforce one another.

That fascination with images and technology actually began long before I had either the mathematics or the computers to describe it.

Visual before computational

My interest in images began long before computing.

There is a photograph of me at about 13 years old in the photographic laboratory at school, developing and printing my own photographs. At that age, making an image was a physical process: film, developer, enlarger, photographic paper, light and chemistry. You had to understand exposure, contrast and how an image came into being.

I also used to draw and paint a great deal. A national examination piece that I submitted when I was 16 was called Extremes. It juxtaposed an astronaut with human evolution, the Earth and space. I was interested in scale, perspective and things occupying space long before I could have described any of that mathematically.

A couple of years later I was still painting imagined environments and architecture, often with strong perspective, layered spaces and changes of scale. Long before I was calculating perspective transformations in software, I was trying to create perspective with pencil and paint. Even my more conventional work tended to be about volume, form and the relationship of objects to one another in space.

That seems important to me now. The computing came later. The urge to make images feel spatial was already there, first through light and chemistry, then through drawing and paint.

Building 3D from first principles

I studied Computer Systems Engineering at the University of Warwick and, during 1987 and 1988, my final-year project was a 3D CAD and view-generation system for making multiplexed holographic stereograms.

I still have the glass holograms, and nearly forty years later they still work under a suitably positioned white spotlight.

I wrote the software completely from scratch in C on an Olivetti M28 80286 PC connected to an external 512 × 512, 8-bit RGB frame buffer. There was no Unity, no 3D code library and no modern graphics stack underneath the application. If I wanted a line, I wrote the line-drawing code.

I implemented Bresenham line drawing, polygon filling, masking, cursor drawing and movement, and the display-control mechanisms myself. The external graphics board was slow enough that even drawing interactively needed some ingenuity. I used the colour lookup table to keep the construction of a frame invisible and reveal it only when complete, and used related techniques to keep cursor movement usable.

The more interesting part was the relationship between the two-dimensional screen and the three-dimensional model. I implemented the perspective and inverse-perspective transformations and the matrix mathematics for rotation and inversion. I could draw a polygonal face in the 2D view, transform it back into the coordinate system of the 3D model, rotate it into the screen, turn the model and continue building from another viewpoint.

That interaction mattered because it made the system genuinely constructive rather than merely a viewer. I could work on the model from the screen in front of me, then turn what I had just created through three-dimensional space and continue from another angle. The software had to maintain the relationship between what I was drawing in screen coordinates and the underlying world model.

Today that kind of interaction feels ordinary because generations of graphics libraries and modelling packages have made it so. On an 80286 in 1987, there was no convenient stack waiting underneath me. I had to build the machinery that made the experience possible.

The project is also where Peter Bryanston-Cross enters the story, my supervisor on this project. He is a gifted physicist and engineer. Our natural division of labour over the years has usually been that I do the computing, software and IT while Peter brings the physics and engineering. Peter later became my PhD supervisor, and we have continued collaborating over a remarkable span of time.

The software won me the final-year project prize for software-development in 1988.

It was a substantial project for its time. I had built much of the graphics system beneath the application as well as the application itself, then used it to generate imagery for a real physical 3D process.

When software became glass

As you can see above, the project did not stop at the computer screen.

My software generated successive perspective views of wireframe models including a Volkswagen Beetle, the Space Shuttle, and an aircraft engine and wing. Colleagues in Mechanical Engineering at Warwick then used those images to make physical multiplexed holograms.

As I remember the process, each perspective view was displayed in turn on a large monitor. The recording material was photographic emulsion on glass. For each view, an approximately 2 mm-wide vertical strip of the plate was exposed as part of the optical recording process while the rest remained masked. The displayed view and exposed strip were advanced together.

The result was a sequence of narrow sub-holograms carrying neighbouring viewpoints. Move horizontally across the finished plate and the view changes; the two eyes also occupy slightly different horizontal positions and therefore receive slightly different information. The result is depth and motion parallax.

Those glass plates are not just souvenirs. They are physical evidence of software becoming an optical object.

Inventing algorithms for images

After my undergraduate degree, I stayed at Warwick for a PhD in digital image and video processing. My thesis, Quantitative digital image processing in fringe analysis and particle image velocimetry (PIV), brought together two substantial areas of quantitative image analysis. One of the major problems I worked on was automatic two-dimensional phase unwrapping.

In holographic and interferometric measurement, useful physical information describing the 3D shape of an object, or another parameter such as a temperature or pressure profile, can be encoded in phase maps which wrap repeatedly through 2π. They really are rather like contour maps. Recovering the underlying continuous phase, particularly in the presence of noise and genuine discontinuities, is a difficult image-processing problem.

During my PhD I invented a two-scale, tile-based minimum-spanning-tree method for automatic phase unwrapping. The idea was to apply graph theory hierarchically: rather than treating the whole phase field at one scale, I divided it into regions and used a minimum spanning tree to determine how those regions should be joined. The two-scale structure was my way of making a difficult image problem more tractable by changing the level at which part of the reasoning happened.

This was one of the original contributions of my doctorate and became part of a wider body of work on automatic phase analysis, holographic measurement and interferometry. In 1994, I published a review of phase unwrapping techniques in fringe analysis with Peter. It has remained a widely used reference.

I find it interesting that the core idea was not specific to optics: it was the application of a general mathematical structure, graph theory, to a visual reconstruction problem.

That work matters to this story because it established a pattern I now recognise very clearly. Give me an image-processing problem and I tend to want to work out what is really going wrong, then invent a computational way of dealing with it.

Much of my subsequent career took me away from optical engineering. I spent many years designing and delivering large computer systems, including around two decades at IBM. But the imaging thread never vanished. In recent years Peter, now Emeritus Professor of Engineering at Warwick, and I have again collaborated on digital holographic microscopy and optical diagnostics, including phase imaging of live human cells.

The tools changed; the attraction of extracting more information from images did not.

From temporal clues to AI depth

Stream to 3D grew out of the same instinct.

When consumer VR became practical, I kept coming back to a simple question: why should the enormous quantity of existing 2D video remain flat when we increasingly have displays capable of showing depth?

I first explored real-time 2D-to-3D conversion through an enhancement to the open-source Universal Media Server project. Release 13 shipped that real-time 2D-to-3D functionality for VR in December 2022. Users then asked for something easier to install and use, and that eventually became Stream to 3D, first released commercially in 2023. I designed it to sit between an ordinary source and the viewing system, producing standard stereoscopic output that can be used with different players and displays rather than tying the conversion to one headset.

The original Temporal method derives useful depth cues from relationships between frames. As I developed it, I encountered problems that needed new solutions. A cut between scenes could completely invalidate a temporal relationship, so I introduced scene detection. Fast-moving objects could create the wrong kind of motion relationship, so I developed fast-moving-object compensation. Temporal conversion could also become visually unstable, so I introduced frame stabilisation. And I developed fractional-frame computation so that depth was not constrained to crude whole-frame temporal offsets.

Those mechanisms were my own algorithmic responses to things I could see going wrong in the images. Each one came from the same cycle: observe the artefact, understand why it is happening, then change the processing model so that it behaves better.

Release 6 added a very different approach: Depth Guided conversion. It uses modern monocular AI depth estimation to infer spatial structure from an individual image, then Stream to 3D uses that depth information as part of constructing the stereoscopic views.

The important point for me is that Temporal and Depth Guided solve the problem differently. Temporal extracts information from change over time; Depth Guided estimates structure from the image itself. I deliberately kept both because their strengths are different. Stream to 3D therefore brings my temporal approach and AI-assisted monocular depth into the same practical video-processing system rather than treating AI as a wholesale replacement for what came before.

Having two very different approaches created another set of algorithmic questions for me. Rather than assuming that one method must permanently replace the other, I began exploring what could be learned from their different strengths, weaknesses, quality characteristics and performance demands. That work is continuing.

There is also a very 2026 aspect to how I now work. Most of Stream to 3D's architecture predates today's AI coding tools. What has changed, particularly in the last few months, is the speed at which I can investigate, implement and test an idea.

Being able to discuss a substantial engineering problem with a computer in ordinary language would have sounded like Star Trek to me in 1987. Now it is part of my working day. I still decide what problem I am trying to solve, what belongs in the product and whether the result actually works; the tools have simply shortened the distance between idea and experiment.

See the results: Compare Stream to 3D's Temporal and Depth Guided conversions, including a downloadable Meta Quest comparison pack.

What this looks like now

The bedroom experience that opened this article is one manifestation of all this. Once the system was running, the engineering disappeared and I was simply enjoying Star Trek on a huge stereoscopic screen floating in my room. I could still see the bedroom through passthrough, but the programme seemed to occupy its own large three-dimensional space in front of me. That is ultimately the point of the technology: the processing matters because of the experience it enables.

The next example is more personal. A couple of years ago, my eldest son gave me a Looking Glass Portrait, a small display capable of presenting view-dependent 3D imagery without glasses. It was exactly the sort of thing I should have loved, but I found the supplied authoring workflow cumbersome and unreliable, so after some experiments the Portrait mostly sat unused.

The Depth Guided work gave me a reason to revisit it. A Looking Glass needs something different from conventional stereo video, but I could reuse some of the depth-processing architecture and engineering knowledge developed for Stream to 3D.

I built my own workflow to derive relative depth from an ordinary photograph, create the required RGB-D representation, and pass it through official Looking Glass Bridge for the calibrated multiview rendering needed by the physical display. I also built the surrounding batch authoring and deployment process.

What began as a one-image experiment eventually became a locally processed collection of around a thousand family photographs installed on the Portrait. I ran the resulting collection standalone, with the computer connections removed, and thought it looked great. That mattered more to me than a laboratory demonstration would have done: photographs that had existed for years as ordinary flat images suddenly had a new spatial quality, and a device that had sat largely unused had become something personally valuable.

What I like about this is that the original workflow was the thing that stopped me using the Portrait routinely, so I treated that friction as another engineering problem and built a route that suited the way I actually wanted to use the display.

Almost forty years between two images

The historical hologram and the Looking Glass Portrait make an unusually satisfying pair.

In 1988, my software explicitly generated a succession of perspective views from a three-dimensional wireframe model. Those views were then encoded optically, strip by strip, into photographic emulsion on glass.

In 2026, I can begin with one ordinary two-dimensional photograph. Software estimates its depth and ultimately drives a digital display that presents different views as the observer moves.

The physical implementations are very different, but the perceptual idea is related. In both cases, the two eyes receive different views, and those views change as the observer moves from side to side.

The multiplex hologram achieved that through a succession of optically recorded views on photographic emulsion. Looking Glass uses calibrated multiview imagery together with the optics of the display to direct different views towards different viewing positions.

One process used explicit geometry, lasers and photographic emulsion. The other uses neural depth estimation, GPUs and a digital multiview display. The production mechanisms could hardly be more different, but the perceptual aim is recognisably related: make an image appear to occupy space.

Across very different technologies, I keep ending up in the software between the source image and the spatial experience. In the 1980s that meant generating explicit views for an optical recording process. Today it may mean estimating depth, constructing stereoscopic views or preparing RGB-D information for a multiview display. The implementation is different; the attraction is remarkably similar.

Apparently I am not growing out of this

I turn 60 shortly.

As part of my birthday celebrations, I am taking some friends to Bridge Command in London, where we will spend part of an evening acting as the crew of a simulated starship. Peter is coming too.

So, nearly forty years after my undergraduate 3D work, Peter and I are going to celebrate my 60th birthday by pretending to operate a starship.

That seems entirely appropriate. I plainly have not grown out of any of this, and I am not sure I want to.

Perhaps that is what I have always responded to in Star Trek: not technology for its own sake, but technology enlarging what people can see, understand and experience.

For a while, lying in bed watching Star Trek, I was not thinking about depth models, graph theory, codecs or GPU performance. I was just enjoying the programme on a huge three-dimensional screen that was not physically there. When the engineering disappears into the experience, that feels like success.

Writing this article has helped me understand the continuity a little better.

I see images. I see problems in them. And I invent ways of making them do more.

I still want a holodeck.

And apparently, at 60, I am still building, and seeking out, little pieces of one.