A few months ago, I got hit once again by what I usually call the “shiny object syndrome”…
I came across one of those digital cameras designed to recreate the look of old film photography, and I immediately liked the idea. I’ve always been fascinated by old photographs and movies, particularly by how easily we can recognise the period in which something was recorded simply by looking at its colours, contrast, grain or even the way people appear to move on screen. So I started looking at the various models available and was seriously considering buying one… until I checked the price. Around $400 for something that, let’s face it, I would probably use occasionally, just for fun. Now, $400 isn’t exactly a fortune, but considering how many gadgets I’ve accumulated over the years, some of which have probably spent more time collecting dust than actually being used, I wasn’t particularly convinced that adding another one to the collection was a brilliant idea. My wife would certainly have something to say about it… 😀
Being a software developer, however, I have this rather unfortunate habit of looking at a piece of technology and wondering whether I could build something similar myself. It’s not necessarily about saving money, because anyone who has ever developed software knows perfectly well that the economics of these decisions rarely make any sense. It’s more about curiosity, the challenge of understanding how something works and that slightly irrational satisfaction of making it work yourself. So, instead of ordering the camera, I started investigating how these devices reproduce the appearance of old photographs and whether the same thing could be achieved using the processing capabilities of a modern smartphone. I initially assumed it would be a relatively straightforward exercise involving colour transformations, some film grain, perhaps a few optical effects and a collection of presets. As it turned out, I was rather optimistic…
A Century of Photography Is More Than a Collection of Filters
The first thing I discovered, or perhaps rediscovered, was just how much photographic technology has changed over the past 130 years. We tend to associate certain visual characteristics with particular decades, but the reality is considerably more complicated. Every period had its own photographic technologies, materials and processing methods, often with several very different approaches coexisting at the same time. A photograph taken in the 1920s is obviously different from one taken in the 1970s, but even two photographs taken in the same year could look dramatically different depending on the equipment, film stock, exposure conditions, chemical processing and printing techniques involved. A professional studio portrait, a family snapshot and a newspaper photograph from the same decade might have very little in common beyond the fact that they were produced around the same time.
This made me question the whole idea of having a single filter labelled “1950s” or “1970s”, as though an entire decade of photographic history could be represented by one particular combination of colours and grain. I started thinking that a more interesting approach would be to associate several photographic styles with each period, based on the technologies and processes available at the time, and then allow the user to control how strongly those characteristics are applied. For example, if I want to recreate the appearance of a photograph taken in 1960, perhaps I want the complete treatment, including the tonal response, grain, colour characteristics and optical imperfections associated with a particular process. Or perhaps I only want a subtle suggestion of that period, without making the picture look like something my grandfather discovered at the bottom of an old drawer. There is no particular reason why all these characteristics should be permanently tied together in a single preset, especially when software gives us the possibility of controlling them independently.
At this point, what had started as a relatively simple camera application was turning into a much more interesting research project. I decided to begin with the 1890s and work my way forward, investigating the photographic processes and technologies associated with each decade. This is where AI became particularly useful, although not in the way people might immediately assume. I wasn’t interested in generating artificial photographs that happened to look old. I wanted to understand what made real photographs look the way they did, identify the technical characteristics responsible for that appearance and then investigate how those characteristics could be reproduced through image-processing algorithms. In other words, I wanted to simulate aspects of the photographic process rather than simply imitate the final appearance of a few reference images.
I started using AI as a research assistant, gathering and comparing information about historical photographic technologies, film emulsions, spectral sensitivity, grain structure, tonal response, contrast, colour reproduction, dynamic range, optical characteristics, chemical processing and printing methods. The research also involved examining historical photographs and technical references to understand how different combinations of materials and equipment affected the resulting images. AI helped organise this information, identify relationships between different processes and explore how their characteristics might be translated into computational operations. Naturally, AI-generated explanations aren’t automatically reliable, particularly when dealing with obscure historical technologies, so technical claims and proposed simulations still need to be checked against actual references and tested against real images. Nevertheless, it made the research considerably more manageable than trying to investigate more than a century of photographic development entirely by hand.
One of the more interesting discoveries concerned the distinction between the appearance of a photograph when it was originally produced and the appearance we associate with it today. We often think of historical photographs as faded, scratched, stained or discoloured, but many of those characteristics are the consequences of ageing, environmental exposure, chemical deterioration or poor storage rather than properties of the original photographic process. A colour photograph from the 1960s, for example, didn’t necessarily have the faded colours we might associate with it today, just as a black-and-white photograph from the early twentieth century wasn’t necessarily covered in scratches and dust when it was first printed. This distinction matters because reproducing a historical photographic process and reproducing the appearance of an aged photograph are two different objectives. Both can be interesting, and both can contribute to a convincing result, but I wanted the application to recognise the difference rather than treating every imperfection as an inseparable part of a particular decade.
And Then I Started Looking at Moving Pictures…
While investigating historical photography, I began looking more closely at motion pictures, and that’s when things became considerably more complicated. With still photography, the processing is essentially concerned with the characteristics of an individual image, but video introduces another dimension because the appearance of motion depends on how images are captured, exposed, transported and displayed over time. Different recording technologies have used different frame rates, shutter mechanisms and exposure characteristics, producing motion that can feel quite different from what we’re accustomed to seeing in modern digital video. Early cinema, for instance, often exhibits a distinctive cadence that cannot be reproduced simply by reducing the frame rate or adding a sepia tint. The relationship between frame rate, shutter angle, exposure time and the resulting motion blur is an important part of the visual experience, and getting it wrong can make an otherwise convincing simulation look rather artificial.
Then there are the mechanical characteristics of film-based recording and projection systems, including gate weave, image jitter, flicker, exposure variations and other forms of instability. Some of these effects are relatively straightforward to understand individually, but reproducing them convincingly requires considering how they behave over time. Film grain, for example, is not simply a static noise pattern placed over the image, and mechanical instability doesn’t necessarily produce the same displacement from one frame to the next. Scratches, dust and other physical imperfections introduce further complications because their appearance and persistence depend on where they originated and how the film was handled, processed or preserved. Once again, it became important to distinguish between the characteristics of the original recording technology and those introduced later through ageing, repeated projection or deterioration.
The more I investigated these processes, the more I realised that applying a photographic filter independently to every video frame would only reproduce part of the effect. A convincing historical video simulation also needs temporal processing, with certain characteristics changing from frame to frame according to the behaviour of the technology being represented. This introduced a completely different set of technical considerations, particularly because I wanted the application to process a live camera feed rather than generate or render the final result offline. There is quite a difference between applying a collection of effects to a photograph and performing several spatial and temporal processing operations continuously while maintaining a responsive viewfinder and acceptable recording performance.
AI was again useful throughout this process, helping me investigate the underlying technologies, compare different approaches and work through possible implementations. But the fundamental principle remained unchanged: the application would capture actual photographs and video and process them using image-processing algorithms, rather than asking a generative model to invent the final images. Each historical style would be represented by a combination of characteristics and parameters, allowing the processing engine to reproduce different aspects of the selected photographic or cinematographic technology. The user could then adjust the overall intensity of the effect, moving between a relatively subtle interpretation and a much stronger reproduction of the selected style. Of course, some characteristics are interconnected and cannot simply be adjusted independently without affecting the result, but that is part of the challenge of designing a flexible processing system rather than a collection of unrelated filters.
By this stage, I had started writing code, experimenting with different processing techniques, defining historical profiles and gradually expanding the number of supported styles. What had initially seemed like a reasonably simple weekend experiment was becoming a proper application, with all the architectural decisions, performance considerations and unexpected complications that inevitably accompany such projects. And, as usual, every time I thought I had reached a sensible point at which to stop adding things, another idea would come along…
Rethinking the Camera Itself
Around the same time, I started thinking about the possibilities offered by newer device form factors, particularly foldable devices such as the DUO concept, as well as conventional iPhones and iPads used in landscape orientation. Most camera applications still follow essentially the same interface conventions, regardless of the device on which they’re running: a large viewfinder, a shutter button, a few controls arranged around the edges and perhaps a selection of shooting modes or filters. This works reasonably well on a conventional smartphone, but I began wondering whether simply stretching the same interface across a larger display was really making the best use of the available space. When a foldable device is opened horizontally, or when an iPad is used in landscape orientation, the relationship between the user’s hands and the screen changes considerably, and that creates an opportunity to rethink how the camera is actually operated.
I started experimenting with the idea of giving the application the ergonomics of a traditional camcorder, using a dedicated control area positioned along one side of the display. Instead of placing the recording controls wherever there happened to be some available screen space, I wanted them grouped in a way that corresponded to how someone naturally holds the device. The control area would effectively become a virtual grip, with the essential recording functions positioned within comfortable reach of the fingers while the rest of the screen remained dedicated to the viewfinder. The grip could be moved to either side through the application’s settings, allowing users to choose the arrangement that felt most natural to them.
This last detail is particularly important to me because I’m left-handed, and I’ve lost count of the number of applications and devices that seem to assume everyone uses their right hand. Sometimes it’s merely an inconvenience, but in applications involving physical interaction, such as cameras, the position of a control can make a considerable difference to how comfortable the device is to use. I wanted the interface to accommodate both preferences without forcing users to adapt to an arbitrary layout. The same principle could also be applied to smaller devices, including regular iPhones and iPad minis, although naturally the available screen space and the position of the controls would need to adapt to the device.
The idea wasn’t to create a decorative interface that merely looked like an old camcorder. I wanted to borrow some of the practical aspects of dedicated recording equipment and adapt them to modern touchscreens. There is something quite satisfying about operating a camera through controls that feel deliberately positioned for the task, rather than interacting with yet another generic collection of buttons floating over a viewfinder. And because the application already deals with photographic and cinematographic styles from different periods, the camcorder-inspired interface seemed to fit the overall concept rather naturally. No external accessories, no additional controllers and no special equipment, just a different way of making use of the hardware already available.
The Time Travel Camera
Eventually, all these ideas came together under a name that seemed rather appropriate: The Time Travel Camera. What started as an attempt to avoid spending $400 on a retro camera has gradually evolved into an application exploring photographic and cinematographic styles from the 1890s to the present day, combining historical research, real-time image processing, adjustable visual characteristics and an interface designed to make the experience a little more engaging than simply pointing a phone at something and selecting a filter.
One of the things I find particularly interesting about the project is that it sits somewhere between historical research and software engineering. Recreating the appearance of an old photograph isn’t necessarily difficult if all you’re trying to achieve is a vaguely nostalgic result, but understanding why photographs from different periods look the way they do, identifying the technologies responsible and translating those characteristics into a flexible processing system is a considerably more interesting challenge. The same applies to motion pictures, where the way movement was captured and reproduced can be just as important as the colours or grain of the individual frames. I’m not claiming that a modern smartphone can perfectly reproduce every historical photographic process, nor that a digital simulation can replace the experience of working with the original equipment. But I do think there is something worthwhile in trying to understand those processes and making their visual characteristics accessible through software.
And perhaps that’s what I enjoy most about developing applications. You begin with a relatively ordinary idea, start investigating how something works and eventually discover an entire world of technical details that you hadn’t really considered before. Sometimes the result becomes a useful product, sometimes it remains an interesting experiment, and sometimes it turns into something quite different from what you originally intended. In this particular case, the journey has taken me through more than a century of photographic technology, the peculiarities of early cinema, real-time video processing and even the ergonomics of handheld recording devices… all because I was reluctant to spend $400 on a camera I would probably use twice a month.
Of course, if I were to calculate the value of the time I’ve spent researching, experimenting and developing the application, I’m fairly certain that buying the original camera would have been considerably cheaper. Probably several times over. But then again, that’s developer logic for you… we can spend hundreds of hours building something to avoid paying for a perfectly good product, and somehow convince ourselves that we’ve made an excellent financial decision. 🙂
And the funny thing is that I still like that original camera. I might even buy one eventually, although I suspect my wife would have a few questions about that, particularly after all the time I’ve spent developing an alternative.
For now, however, I’m rather enjoying the journey. What began as a simple exercise in recreating a few photographic effects has become an opportunity to explore how photography and cinema have evolved over more than a century, and how some of those technologies can be interpreted using the capabilities of modern devices. Whether someone wants to recreate the characteristics of a particular historical process or simply give their photographs and videos a little of that old-fashioned atmosphere, I like the idea of giving them the freedom to experiment rather than limiting them to a handful of predefined filters.
As for the $400 I was originally trying to save… well, I think we can safely consider that objective a complete failure. 😀