10 min read
In the first couple of articles in this series I’ve looked at some of the more broad user interface points about Lightroom. Now I want to start getting into some more technical aspects, starting with virtual copies.
As I’ve said over and over, one of the biggest features of Lightroom is that it doesn’t directly manipulate the pixel values of the images in the catalog. Every image you see in the interface is made up of two “parts”. First, there’s the original image file, be it raw, jpeg, tiff, psd, or what not, on the disk. Second is the set of instructions that tell Lightroom how to process and display an image; these are stored in the catalog.
One of the advantages of having these two separate parts to an image (the raw file and the recipe) is that it enables a very space efficient way to address multiple alternative versions of an image. You don’t need to store completely separate files on disk, you just need the bookkeeping in the database for two images that point to the single file on disk.
It’s not like the space savings of virtual copies is something to sneeze at. The develop recipe can be as little as a few KB. Even big develop recipes — and I’ll be going into much more depth about the storage of Lightroom’s develop settings in a future article — will almost always be under a few hundred KB. Compare that to the 3–6 MB needed for a 10 MP JPEG, never mind a 50MP raw at 60–70 MB, or the even larger file sizes needed for fully converted RGB tiffs or PSDs.
Make no mistake, Adobe unquestionably got the overall concept of virtual copies right. However, there is one major detail that just drives me up a wall.
Read the rest of the story »
10 min read
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.
Read the rest of the story »
I’ve long been thinking about posting on some concepts that I’ve been thinking about for features for cameras. Things that I’ve yet to see actually implemented but I think would be useful to have, why, and maybe look at how they could be implemented.
This time, I want to talk about an idea that’s been floating around in my head for a couple of months now. Especially with Canon and Nikon announcing their latest flagship cameras that have blazing fast frame rates. The idea, as called out in the title is an adaptive continuous drive mode.
In my experience, the vast majority of times that I’ve used continuos drive the high frame rate wasn’t the ends, it was just a means to an end. More specifically, a means to overcoming a limitation of my own. For example, when I’m shooting a bird in flight, or a whale breaching, what I almost always want is a single photo at the optimal point of action, not the whole sequence.
At the same time, I’ve found that there are real, though not real significant, drawbacks to continuous drive modes. Namely, using them creates a lot of images. That in turn uses a lot of storage space, and has an impact of the difficulty of editing them. By far the two hardest sets of images I’ve had to edit were days that made extensive use of continuous release at 10 FPS either with similar subject matter or just from the sheer number of images.
Either there were just a massive amount of images to sort through, or the differences between images become quite small (say a feather position or the position of the nictitating membrane) and the sorting process becomes much more mentally taxing.
There are also the cases where you known that continuous release isn’t needed now, but will be needed at the spur of a moment. For example, if you’re photographing a leopard sitting in a tree waiting for it to jump down. You can’t afford the delay of trying to change the drive mode when the action happens, yet for the most part anything you shoot while it’s sitting still doesn’t need more than a single frame. (Of course, maybe you’re better than I am, and can consistently squeeze off one frame form a 10–14 FPS camera.)
At least that’s my thinking, very rarely do I need all of the FPS my camera can deliver, and when I do, often it’s interspersed between not needing very many FPS at all.
So suppose instead of having to always run the camera at say 10 FPS, the camera will adjust the FPS based on the scene and camera motion.
Read the rest of the story »
20 min read
The Library module is easily the core of Lightroom’s asset management functionality, and as a side effect of that very much the core of Lightroom as a whole. In this part of Lightroom 8 Years Later, I’m going to look at the Library module in mode detail.
The big picture aspect of the Library module is that it’s a thumbnail and image viewer with supporting aspects for importing, exporting (though it’s not limited to the library alone), and managing the images that are in your collection. Over Lightroom’s history, the Library module has remained mostly unchanged. There certainly have been some refinements and improvements, but the organization and features hasn’t radically changed.
Back in part two I wrote about Lightroom’s user interface, specifically the penalized organization and structure. The Library module, like all Lightroom modules, uses that system at least as best as it reasonably can.
Read the rest of the story »
20 min read
So today I want to talk about the software that runs our cameras. More specifically than that, I want to talk about why I think that the camera companies should stop sitting on that software and either make it more open and accessible or better yet, make the source code for it available to interested photographers and developers to extend and mess with.
I would argue that there are a whole slew of reasons that this is a good thing for us photographers and the camera companies. Probably more than I can reasonably cover in this post while keeping its length reasonable. But that’s not going to stop me from trying.
Security
Let me start with the big scary fear-mongering headline grabbing keyword; security.
No wait, stop laughing. I’m serious.
Cameras are increasingly becoming connected, network enabled, devices. And with that comes dealing with a whole myriad of security issues that none of the camera makers have really had to consider or think about in the past.
While cameras can stand alone without the connectivity, and hopefully that will remain the case for a long time to come, that connectivity is increasingly becoming a selling point; even for pro level cameras.
Read the rest of the story »
So far this year has been a great year for new gear from Canon and Nikon. I’ve written about the two Canon announcements, but I’ve been awfully quiet on the Nikon ones, the D5 and D500.
Since the D3, Nikon’s been turning out absolutely solid pro cameras that offer amazing image quality, functionality and features. The D5 carries on that tradition in virtual all respects. The chassis is the same solid all magnesium weather sealed construction, and the sensor is almost certainly going to be par for Nikon’s course in terms of excellent dynamic range and noise performance. In fact, so far as I can tell, in virtually every aspect the D5 builds on the D4s in every respect.
That said, I don’t write these things to just sing praises of cameras — even the ones that I really like. I write these things because there’s almost always stuff that’s been done really well and stuff that can be done a lot better.
UI Improvements
Nikon has made two major improvements to the UI that I really think are good moves.
First, they’ve added an ISO button to the top plate right behind the shutter release. In my opinion, they should have followed Canon’s lead and done this soon after the conversion to digital, but better late than never.
Second, they’ve added two more user programmable buttons to the camera (one more to the front and one to the rear). I like user customizability in a camera. Sure I may have my camera set up different enough that someone else can’t just pick it up and shoot with it, but I don’t really care if it makes me more efficient and productive.
The only real shortcoming to Nikon’s functions buttons is that they don’t duplicate them across the bottom of the lens mount, like Canon has been doing with the 1DXes. I would have loved to see Nikon again follow Canon’s lead here and duplicate the front function buttons along the bottom of the lens mount so they were equally usable from the portrait and landscape grips.
Read the rest of the story »
Just when I get done looking at Canon’s new flagship camera, they go and release a new enthusiast class camera; the 80D, successor to the 70D. And much like the 1DX mark II Canon has made a number of interesting and not so interesting improvements to the 80D. Moreover, they’ve released an enthusiast focused lens to go with the 80D that really looks quite decent for video work as well as stills.
Like my thoughts on the 1DX mark II, I’m not going to go into every detail of the new camera, there are just to many. Instead I’m going to focus on a handful of points that I think are the biggest points.
I Like: Autofocus at F/8
AF at f/8 has been a thing for Canon’s higher end cameras for a while. The EOS–1 series could focus with the center point only going back to the mid 2000’s. On the other hand, the enthusiast tier hasn’t been so lucky, until now.
I’m a huge proponent of having an AF grid that’s active at f/8. It’s immensely useful to me as it lets me carry lighter lenses and get more reach out of them. And this is a position that I still am strongly behind even in the enthusiast tier and with enthusiast like use cases.
The way I see it, enthusiasts are even less likely to be buying fast telephoto lenses. Instead of 70–200mm f/2.8L or even f/4L they’re much more likely to buy a 70–300, and maybe not even the L version. And when they find that the 300mm isn’t enough zoom for them, they go out and buy a cheap 3rd party teleconverter to put on it.
I know this, because I did this back when I was first starting out and didn’t have a lot of money to drop on gear.
Read the rest of the story »
A couple of weeks ago, Canon announced their latest flagship camera, the EOS–1DX mark II. At the time, I tired to post something, anything, about it, if only to get my thoughts together on the matter. Like the vast majority of photographers, Canon doesn’t send me hardware to test, trial, or use. And like the vast majority of photographers, the EOS–1 series cameras are at the upper edge of my budgetary bounds.
At the same time, Canon has shown with the 5D mark III and EOS–1DX, that they’re willing to put 1-series features in at least 5-series bodies, even if there are some limitations. With that in mind, when I look at an EOS–1 that I probably won’t be buying — even though I’d love to have one — I’m looking in part for the things that I really want to see become more pervasive.
So without further ado, these are by far the top features that I see in the EOS–1DX mark II that I think change the game in a big way.
Read the rest of the story »
10 min read
Eight years ago, Adobe released Photoshop Lightroom, a unified digital asset manager and non-destructive raw image processor. Since then, Adobe has released 5 major versions of Lightroom, each making small revisions, tweaks, and sometimes adding new functionality. This is part 2 of my series looking at Lightroom in depth, inside and out, and what I think Adobe needs to do to continue to build on Lightroom as a tool for both professional and amateur photographers alike.
In this article I’m going to look at the overall Lightroom user interface at a high level. Many of the nuances and issues in many parts of Lightroom’s user interface (UI) stem from decisions made early on about the way Lightroom would work and act.
One of the problems that I run up against in talking about software UIs and how they were designed, is that there’s a great deal of interdependency in the decision process. A design decision can have ramifications that impact other decisions that in turn either reinforce or work against the initial design goal.
The other major problem I have with trying to look at Lightroom’s UI is that I’m not at all clear, even to this day, what market space Adobe is really trying to target. On one hand, as a pro photographer, Lightroom dramatically improved my workflow in terms of managing, searching, and processing images. In fact, I can say that same sentiment is generally true with most of the other pro photographers I know or work with. On the other hand, Lightroom makes this kind of workflow accessible to more inexperienced and less technically savvy photographers as well.
The trouble is that pro/serious user oriented interfaces are almost always an in scrutable nightmare for novices, and the converse are underwhelming for pros. However, without really having a handle on what market segment the software is actually targeting.
With that said, lets get started.
Read the rest of the story »
5 min read
It’s been just almost a decade since Adobe released Lightroom, their digital asset manager (DAM) and non-destructive raw image editor. In that time, Adobe has made a number of improvements in many respects, from improving the raw engine to adding new processing features, to finally adding GPU rendering support. However in many ways Lightroom hasn’t changed much at all, and there are all kinds of interesting quirks and issues from it’s nearly decade old heritage.
Truthfully, age hasn’t been kind to Lightroom. The user interface (UI) is dated and clunky. There are a whole host of quirks, pit falls, and short comings. A lot of the internals and back end processes make interesting trade offs that sometimes are woefully inefficient. Finally, based on the few fits and starts we’ve seen from Adobe, it’s not clear at all whether they ever plan to address any of the deficiencies going forward.
When the first public release of Lightroom hit the market in February 2007, it wasn’t the first commercially available raw processor and digital asset manager (DAM). Apple beat Adobe to market by more than a year with Aperture. However, Lightroom was the first cross platform non-destructive raw editor and DAM, which was largely a first for us Windows users.
I switched from using Bridge and Photoshop to using Lightroom with version 2 back in mid 2008. At the time, for me at least, Lightroom was a breath of fresh air and quite revolutionary. The develop/process as a recipe style of editing made it significantly more space efficient than doing a similar kinds of edits in Photoshop, and the ability to make tweaks and easily sync them across many images made working with large numbers of similar images, very efficient.
Read the rest of the story »
