Mark Hamburg Interview: Adobe Photoshop Lightroom Part 2 of 2 · 1691 words posted 02/15/2007 08:57 PM
Last month I spoke to Mark Hamburg, Adobe Fellow, former Photoshop architect, and founder of the Adobe Photoshop Lightroom project. In the first half of our interview we discussed Lightroom’s lengthy gestation and innovative UI. Here’s the second part of our talk.
since1968: Lightroom’s first beta was Mac only. Thanks for the Mac love—but why did you choose Mac first?
Mark Hamburg: I’m primarily a Mac user, and as it happens a lot of people on the initial team were primarily Mac people. We’ve now got some hardcore Windows users on the team for balance. We started out doing what was much more a research project, though, and it seemed sensible to only focus on doing one platform first.
We actually spent a while at one point starting to get things running cross-platform and that managed to sidetrack most of the project. The lesson there was that when you are still figuring out what to build, you don’t want to let yourself be distracted with coming up with cross-platform architectures too early. You want to keep cross-platform in the back of your mind, but the most wonderful cross-platform strategy without a product to build on it doesn’t really get one anywhere.
Another thing that influenced us in this regard is that Photoshop started its current code base in the early 90s. Though it has evolved over time there are certain assumptions built in very deeply that reflect the state of the art at that time and the Photoshop team is having to do a lot of work to move beyond them. When we started what would become the Lightroom project we wanted to focus on building for “modern” operating systems. Mac OS X by that point had been out for a while and was more or less settled. On the other hand Microsoft was busy still just talking about Longhorn, so Mac OS X was in a better position for us to start on when looking for a modern OS.
The irony here is that Lightroom 1.0 ended up being built for XP rather than Vista, and we’ve already felt some development pain from that.
Finally, we knew that in reaching photographers it was really important to get to the influencer market and that market was largely a Mac market. If you go through and look at how the market breaks down among photographers, the influencers tend to be heavily Mac—not entirely, but heavily. The mainstream working photographers frequently are on Windows. In the “prosumer” market Windows still dominates but there’s a mixture. Knowing that we wanted to start with the influencers, we needed to be on the platform they were going to be on.
since1968: Lightroom is 40% Lua. How did you select Lua? Which parts of the program are handled by Lua?
MH: I foisted Lua on the rest of the team which actually at that point was very small. But I had discovered it just in reading some of the mailing lists I was on—I think it was actually a garbage collection mailing list that led me to it.
I wanted to build an app that was heavily scriptable and was looking for a good scripting language to build in and got the pointer to Lua. I’d actually read one of the first papers on Lua several years earlier but hadn’t pursued it because it hadn’t been relevant to what I was doing. At that point Lua was also much more primitive than it was when we picked it up.
Lua has an appealing balance of simplicity and power. It’s small, fast, and easy to embed. It also has a very straightforward license associated with it. It’s very much like Scheme language I like—but without a syntax likely to make people go running for the hills. So there were a lot of things.
I looked at some other things. I looked at JavaScript: Adobe had an internal implementation of JavaScript but it wasn’t as easy to do drop-ins and all the things we wanted to do in the Lightroom project. I looked at Python, I looked at Ruby. Some things were going to be bigger, slower, and had licenses that were harder to figure out. Lua just happened to fit really well.
So what we do with Lua is essentially all of the application logic from running the UI to managing what we actually do in the database. Pretty much every piece of code in the app that could be described as making decisions or implementing features is in Lua until you get down to the raw processing, which is in C++. The database engine is in C; the interface to the OS is in C++ and Objective C as appropriate to platform. But most of the actually interesting material in the app beyond the core database code (which is SQLite) and the raw processing code (which is essentially Adobe Camera Raw) is all in Lua.
since1968: What development environment do you use to write Lua? LuaEclipse?
MH: We have our own development environment. On the Mac side we have a fairly sophisticated IDE that was developed internally as one engineer’s first project when he started on the team. We have a Windows IDE as well. It isn’t as sophisticated as the Mac IDE. I think the people who are doing their primary development on Windows are generally either using the Windows IDE or they’re editing the source code in Visual Studio.
since1968: Whoa—Adobe is known for building or acquiring some famous IDEs: HomeSite, Flex Builder, Dreamweaver. Did you look at your stable before building your own? Any change the Mac IDE will evolve into a future public project?
MH: Tim Gogolin, the engineer who built the IDE, gave a demo at the Lua Workshop in 2005 and had lots of people drooling. We’ve contemplated on occasion whether there was a good way to release it to the public, but it’s pretty tightly coupled to the rest of the Lightroom implementation. It will, however, definitely be included when we do a serious SDK for Lightroom.
since1968: Lua’s not such a common scripting language. Apart from a legion of World of Warcraft modders, do you have to grow your own Lua talent?
MH: Yes, we have to teach people Lua. The benefit is that it’s fairly easy to learn. One of the people who joined the team was an avid scripter anyway, but his comment coming in was that Lua was easier to learn than JavaScript.
since1968: On the Mac, did you use LuaObjCBridge or write your own bridge to Cocoa?
MH: We wrote our own bridge.
since1968: Let’s talk about extensibility. Adobe will release an SDK sometime after 1.0. Data from C is directly accessible in Lua’s userdata type, so presumably Adobe could really open up Lightroom to be extended as far as a developer can take it. Will developers be able to write extensions in Lua?
MH: [Laughing] Developers will have to write their extensions in Lua. At one point—and it probably complicates the app a little—there was probably some notion that we’d provide ways to let people write things in purely native code as well. But I think at this point you will have to write at least part of your logic in Lua for knitting into the rest of the system.
When people ask “What do I do for Lightroom development?” I tell them “Go out and learn Lua. Hack World of Warcraft until we’ve released an SDK.”
Any APIs we publish we’d like to commit to supporting long term. In getting a 1.0 out as we’re sorting through some of the feature set there’s a fair amount of churn on the APIs that we have. Putting out an SDK means we need to start freezing those a lot more, so that’s essentially the delaying factor. After version 1 we get to go through and sort through and say “Yes we can commit to this. We can publish it and put it in the SDK.”
since1968: What’s the coolest Lightroom feature that people haven’t noticed or hasn’t been mentioned in the blogs?
MH: One of the things people haven’t entirely gotten is some of Phil Clevenger’s working from the “inside out” behavior. It takes time to really grasp how to tune your workspace, but once you do, you can get a lot of stuff out of the way.
One of the really surprising features for me in Lightroom came out of the Print module. It starts with doing the basic grid work, but combining extreme grids with the “zoom to fill” options start to push you toward discovering new way of looking at your images and new layouts that wouldn’t have been expected on our part. The grid goes in as “OK we’re dealing with contact sheets and so forth” but what comes out of it is that it actually becomes a viable creative tool as well. That’s somewhat reflected in the 4 Wide templates, but I don’t know that people have really picked up on the fact that if you start pushing the settings in the Print module you can get fairly creative effects out of what otherwise people might have thought of as a contact sheet generator.
The Split Toning controls in Develop actually are fun to use on color images as well as gray scale. They were created for creating duotone-like effects but they actually can be used in interesting ways to enhance color images as well. They’re not particularly good for correcting images. I’ve had people try to push them to correct color casts in the shadows and they’re not really built for that. If you want to put a color cast into your shadow they’re a great tool for that. Not so good if you want to take one out.
Finally, something that applies only to 1.0 and not Beta 4. I’ve been doing more dust spotting work on my images lately, I have to point people to the benefits of zooming to 1:1 (or higher), starting at the top left corner, and then just repeatedly pressing page down. Watch what happens when you get to the bottom of the column.
since1968: Mark, thanks for your time.
MH: You’re welcome.
* * *
2. On Feb 21, 02:27 PM James Duncan Davidson said:
Nice interview! As well, I love the page down tip. That’s a great one.
#
1. On Feb 16, 04:24 PM Ellis Vener said:
Thanks for these interviews with Hamburg and congratulations on your baby. Get some sleep when you can.
#