In the first couple posts of this series I’ve talked about Lightroom’s UI, and I’m going to probably get back to that in the future, but I also want to look at some of the technology in and around Lightroom. I also want to do this in part so I can talk about a couple of core technical issues in more detail in future articles as well.

There are three core technologies that Adobe has leveraged in Lightroom that make it what it is. Surprisingly some of these are open source products, one of which is absolutely a critical core part of Lightroom. These core technologies are Adobe’s Proprietary Adobe Camera RAW engine, the Lua programming language, and the open source database engine SQLite.

Adobe Camera RAW

It should be well known that Lightroom leverages Adobe’s Camera RAW technology to do all the heavy lifting in Lightroom. And, really, why shouldn’t they. Camera RAW is the same rendering engine that Photoshop, and really all Adobe programs that support reading raw files, use to convert the raw file into a useable bitmap.

As far as raw engines go, camera raw isn’t horrible. It’s been a while since I’ve seen a good comparative between camera raw and the competition. However, the last major over haul, process version 2012, put camera raw on par with Phase One’s Capture One in terms of the ability to distinguish and render fine details, and pretty close with it’s peers in terms of noise reduction.

That said, ACR does lag behind more specialized tools in many respects. Dedicated noise reduction software, like Noise Ninja or Neat Image, can typically do much better noise reduction that ACR can.

Likewise, specialized raw engines from camera manufacturers can have more detailed profiles and capabilities. Canon’s Digital Photo Professional software, for example, can preform very specific lens corrections (axial chromatic aberrations, and field curvature removal for example) as well as diffraction correction for supported lenses.

That said, I don’t really fault Adobe and ACR for not being as capable as specialized software, after all ACR has to support virtually every camera and lens made, and honestly it does a very good job of that. Things like advanced lens aberration correct and diffraction correction require extensive profiling of various lenses to know exactly how they behave, and that’s just not something that I’d expect Adobe to be able to effectively compete with the manufacturer designing the lens in the first place.

That said, Adobe’s distortion and chromatic aberration correction does work really well, especially given how easy it is to generate your own profiles and test images.

Arguably the biggest problem with ACR and Lightroom is the fiefdom problem in digital photography. Adobe’s ACR engine is entirely closed proprietary technology. When a manufacturer releases a new camera, Lightroom users have to wait until Adobe can build the required updates into their rendering engine. In some cases, this can take several months, making it painful for some early adopters of new hardware.

It would be nice, if Adobe had designed the rendering engine in Lightroom around a more flexible approach. Something that allowed manufacturers to write and publish Lightroom rendering libraries for their cameras that offered users the best possible image quality from the manufacturer though the convenience of Lightroom’s cataloging engine and DAM. But of course, that’s just wishful thinking.

The Lua Programming Language

If the ACR rendering engine is the core of Lightroom’s image processing, the Lua programming language is the core of Lightroom’s extensibility and, if the number of binary Lua files in the Lightroom installation are any indicator, a major part of what Lightroom it self was written in.

Lua may not be my first choice in programming languages. However, in its role as the public scripting/extension language for Lightroom, it’s certainly reasonable — if not the best choice. Lua interpreters are small and easy to embed in an application. The language is relatively straight forward to learn for those who aren’t serious or professional programmers, yet it’s still powerful enough to allow sophisticated programming concepts to be applied. Moreover, Lua is very commonly used in this kind of situation.

In fact, this is one of those places where I think Adobe absolutely did the right thing in Lightroom. While the language itself doesn’t see the popularity that other languages see, even other open source languages. Lua as a language has been round for more than 2 decades. It’s extensively used as an in-program scripting language in various industries — the computer games industry being one of the bigger spaces where I see Lua used in this way a lot.

SQLite — Literally the Lightroom Catalog

The last bit of technology I want to touch on in Lightroom is the use of the open source relational database engine SQLite. To say that Lightroom uses SQLite is almost an understatement. The catalog file is literally an SQLite database with a custom file extension (lrcat).

This is another place where Adobe did the smart thing and leveraged existing stable well tested and supported code instead of trying to roll a half baked solution of their own. And given how fundamental the catalog is to Lightroom’s functionality this is not a place where Adobe could afford to have a half-baked half-reliable implementation.

At the same time, SQLite is extremely well tested and used on massive scales. A huge majority, if not all [1], Android apps use SQLite to store their settings; as do many iOS apps. As do many desktop and standalone apps on Windows and Mac OS. The sheer number of places where SQLite is used to provide core functionality is staggering. That breadth of use also means that it’s extremely well tested to insure it’s correctness and stability.

That said, while the catalog is build on a solid foundation with SQLite, that doesn’t necessarily mean that the actual design of the catalog’s database tables is all that great — and this is going to be focal point in the next couple of articles in this series.

With that said, I’m going to wrap up this part here. As far as the core technical stuff goes, Adobe did a pretty solid job when they designed Lightroom. By leveraging widely used open source tools that were designed to be robust to start with, Adobe potentially had more time and resources available to focus on the image specific aspects of the software; the ACR engine. Even with respect to the ACR engine, Adobe deserves some credit. Over the 8 years that Lightroom has been around they’ve evolved it into a very capable raw engine with a massive amount of supported cameras and lenses.