We Used To Know

    The other day I was musing about tributes to lost friends and heroes I've embedded in various bits of software and show-control scripts, to run unseen and unbeknownst to the users/observers of said stuff. There is another side to this: yesterday, I came across the source code to a thing we were working on twenty-three or so years ago. I won't claim to have had any direct input in this code - I just initiated and supervised the project, putting in suggestions as to what direction a programmer might take; what libraries/API's etc. might be good to look at - kind of meta-coding rather than actual programming. But before I get into the meat of this, a bit of background is in order.
    After our Audiovisual business started to dry up, we decided to turn our hands to software. With the company having been latterly about image and sound, and with my photographic history, imaging software was the logical place to head. Initially, we got involved with the local Film Commission to work on a visual database of their location image library, which was a poorly curated labyrinth of nested folders of images hosted on desktop PC's of uncertain heritage. The upshot was that accessing these resources was protracted, painful and about as professional as throwing a shoebox of old photos at the Hollywood location scout over here to spend millions in pursuit of the right places to film the next blockbuster. Something was needed to convince them that there was a better way to do this stuff. If this seems trivial now, with all the current tech to hand, believe me, in 1996 it most definitely wasn't.
    Digital imaging was still pretty much in it's toddler stage, and there were almost no digital cameras out there. Those that were available, at great expense, produced images which could be bested by even the cheapest film cameras - by an order of magnitude. Coupled with the crude image-compression techniques and the by-modern-standards excruciatingly slow hardware and software extant, it was far, far preferable to stick with film and print.
    Needless to say, in our inimitable style, we said we had a technical solution that would solve their dilemma and present them in a modern light to the emissaries from the glittering world of the movies. Except that we hadn't. I knew that there were ways around the issues, but a solution there was not. Yet.
    The problem was principly that the current hardware was too slow to process the data. A typical [by today's standards, not very] high resolution image would be unmanageable in real-time: even compressed images like jpegs, took an inordinate amount of time to open. So I took a sideways look at it, as usual - a way of seeing the world taken not from Edward de Bono, but Geoff Harvey: the old man could always find some way of getting around an apparently intractable problem, just like his oldest brother, Sam.
    What I knew about the issue was that JPEG (Joint Photographic Expert Group) standard compression - still is the standard today - was symmetrical; it took the same amount of time and processing power to unpack as to pack the data. There lay the problem: the hardware couldn't cope. I was also aware of another image compression algorithm/standard, which was proprietry to Apple Computers (we were only dealing in the Mac world at that time, anyway,) called Cinepak. This was a compression system designed for video, where obviously the de-compression side of things needed to work at video rates, i.e: 30 frames per second. Lightbulb moment. Instead of using Cinepak to compress video, we could use it to compress a large number of still frames for individual access. The compression times using Cinepak were huge, but that didn't matter - it was a more than acceptable trade-off for practically instantaneous rendering of the still frames we needed to display at the output end. I put together a crude demo, and after a lot of politicking, the job was ours. The eventual outcome of all this is a subject for another post, but we got the gig.
    At the same time as this we welcomed the first of our French students on placement with us. It was thought a good idea to expand the work I had started using Macromedia Director to build the Film Commission visual database (christened Location Hunter, and initially installed in both Pinewood and Shepperton studios,) and build our own proprietary software.
    The first tentative steps were taken by our first student, Christophe and the work later taken up by our late friend Jean-Charles Boude. We then moved to try and work up a quick revenue-earner with a Photoshop plug-in to fund the main project. This proved to be both extremely rewarding and a poisoned chalice. We chose to sell exclusively online for cost and ecological reasons, but neither the internet infrastructure nor the market (this was well pre-Amazon/eBay/etc.) was mature enough to support the venture. We were too early. Having said that, we sold worldwide and had a loyal following with pro photographers - our intended audience - we also had an agreement that our software was officially accepted for copyright protection for photographers in the USA. Water under the bridge.
    Back to the source - I have, as I've said, used software to hide my tributes to people, but rediscovering the source code for Pictread - the working title for that original project - I discovered a tribute to a lost friend and colleague: his own work.