May 2014

A Newfound Love of Kodak Portra

A few weeks ago I was heading for a week-long conference in Copenhagen and figured I’d only bring the Nikon FM as my only camera, and the practical 28-70mm lens as my only lens. And since this is a slow lens I went with a fast film: a Kodak Portra 400.

It had been a while since the last Portra, and even though I’d halfway declared it my general-purpose go-to film, I’d also kind of forgotten how good it is, perhaps thinking it a bit boring even after all the adventures into Lomography films and cross-processing. Fortunately the prints brought a very happy surprise! Perhaps it plays a part as well that I’ve switched back to my old (and more remote) printer after the inconsistent prints from the Precisa 100, but in the end I really like the result.

While the above film was shot within a week, I also recently finished a Kodak Portra 160 that’s been in my Olympus OM-1 since last autumn. And although it’s apparently against recommendation to let a film in a camera for that long due to light leaks, radiation, heat, and what not, this indicates that the advice should be balanced against the increased quality of the photos when you are more picky about releasing the shutter!

 

Book: Programming Pearls

Another book I came across when refreshing the more practical computer science skills was Jon Bentley’s Programming Pearls (second edition), composed of columns — blog posts, I suppose, by today’s terminology — written by him for the ACM back in the 1980s. And while it is somewhat outdated in terms of technology, the strength of this little book lies in something entirely more timeless.

The book covers several topic within software construction, including programme verification, testing, and code tuning, but most pages concern the construction of good algorithms to solve a given problem. Incidentally, one of my favourite problems from the book was posed to me at a job interview, supporting the claim that the book is well-known within the software community, at least by senior staff (as a side-note, I mentioned that I’d already encountered the problem from reading this book, and funnily enough that almost seemed as good an answer as an algorithm).

The problem was this (section 2.4 and 2.8):

Given a dictionary of words, find all sets of anagrams.

The good thing is that the book not only poses interesting questions, it also discusses several solutions, comparing them in terms of time and space efficiency. For the anagram problem above there’s the brute force approach as usual, yet as soon as you remember equivalence classes and their representatives you’re close to a much better algorithm.

Another favourite was presented in chapter 8:

Given a array of n integers (positive and negative), find a maximum sum contiguous subarray.

For instance, in [ 31, -41, 59, 26, -53, 58, 97, -93, -23, 84 ] one solution is [ 59, 26, -53, 58, 97 ] with sum 187, obtained by removing the first two and last three elements. Again there’s the obvious brute force approach — e.g. computing the sum for all C(n, 2) pairs of indices — but by a bit of dynamic programming it’s possible to reach an O(n) algorithm that only scans the array twice.

Now, as mentioned above, the book does not just talk about algorithms but through various topics aims to improve your overall programming skills. And for that I recommend it highly: it will probably not teach you a new technology but it might improve the quality of your code.

Which brings me to a pattern I’ve noticed over the years: my technology books usually end up somewhere in the basement, mostly kept for nostalgic reasons, whereas books like this one, focusing on the fundamentals, are much more likely to still sit high on my office bookshelf, and as such still attractive to buy in dead-wood format.

The Power of Pressure

The other day I was, relatively speaking, very close to landing a good job in the software industry. However, during the last 5% of the interview process pressure kicked in and my mental processes collapsed, leaving me starring at the white board unable it seemed, to even spell my name.

At this point it had already been a surprisingly long recruiting process, consisting of more than 8 hours of problem solving interviews. I’d had a break for the weekend, and was now called in for a final interview with the big boss. This was of course an indication that they were considering me seriously, however the recruiting agent had let me know that a few of the interviewers had expressed a wish that I’d been a bit faster at coming up with solutions.

The first half hour with the big boss went well, focusing more on me being a cultural fit than technical skill. But then, for the last half hour he suddenly asked me another problem solving question: implement method transposeMatrix(int[] matrix, int n) where the matrix is assumed to be of size n by n represented by a one-dimensional array, and with only a constant memory overhead (so no allocation of another array).

I quickly realised how the algorithm would work, using two pointers running respectively out of the rows and down the columns. However, when it came to writing the code I froze up — and not because it’s difficult code, but because I knew that me getting the job or not most likely came down to these particular 30 minutes. As a result, I got self-conscious and my focus started drifting away from the white board towards the big boss looking over my shoulder.

The outcome was that I turned completely blank, fighting to bring back focus where it was desperately needed. But it didn’t happen until after 20 minutes of nonsense, when I got a 5 minute break while he left to pick up a new whiteboard marker. When he came back my focus was there already and the solution came quickly:

void transposeMatrix(int[] matrix, int n) {
    for (int row = 0; row < n-1; row++) {
        for (int col = row+1; col < n; col++) {
            int i = row * n + col;
            int j = col * n + row;
            // swap matrix[i] and matrix[j]
        }
    }
}

yet it was too late; given the performance I illustrated that day I wouldn’t have hired myself, so in full understanding of their decision.

The frustrating part instead, is that this can still happen to me when I want something badly (it never happens when I don’t care). But what’s to learn from this? Well, I’m better at problem solving with a piece of paper in front of me and 5 minutes of “quite time”; I’ve been hesitating to take this at interviews for a fear of disrupting the flow, but it seems it can come to a point where it’s worth it. Also, I’ve started on ways of controlling nerves by basically caring less about the surroundings; since this is rooted in a current insecurity (from being unemployed?) it is easy to practise in everyday life.

First AgfaPhoto CT Precisa 100 (in C41)

In my on-going hunt for a Lomography X-Pro Chrome substitute I’ve heard the AgfaPhoto CT Precisa 100 mentioned on a few occasions, and it finally became time to try it. It has done a decent job, and moreover illustrated that a step might have been missing in my process so far.

As you never really know which film is actually inside the Lomography canisters (rumour has it they were using old Kodak film in the beginning and has since gone through several manufactures, including unknown Chinese brands) it is also non-trivial to tell if it’s actually a negative or a positive film — and apparently it isn’t just me who’s confused: for the first time my developer charged a special cross-processing feed, even though I’ve given her Lomography films before that were supposedly also meant to be cross-processed. But this time I’m absolutely certain that I have in my hands a bona fide cross-processed film!

As mentioned, I think the film has done a decent job. Scholastique (from Above) for example is exactly what I was hoping for, and also like the toning in House.

However, most prints are quite a bit off in terms of colour balance, as for example Behind the Park, In Time, and Cornershop. For some it works out nicely, e.g. Scholastique (In the Rain) and Goth Metro, while for others I felt the need to cheat and colour correct in Photoshop afterwards: Pearl of the Quartier, for instance, was shot seconds after Scholastique (from Above) using exactly the same exposure yet completely green.

I’ll be asking my developer the next time if it’s really a question of exposure or not, but at this point my suspicion goes in direction of the printing process simply not being as standardised as I believed it was. More specifically, that asking the developer to either scan the film or make prints is still not enough to achieve the “real” colours of the film.