Lightroom totally dominates the realm of digital asset management (DAM) — a solution for everything, it fits the mold of most photographic workflows, however the bitter pill to swallow can be the treacle-like performance and that monthly subscription. Is it time for Adobe to start again?
Digital asset management is something we all do as photographers — whether its as simple as copying image JPEGs straight off your SD card and dumping them in to a “Pictures” folder, or ingesting the raw files pre-tagged into date named folders that are cloud synced for anywhere access. The care you take will depend upon what you want to achieve and who you are delivering the images to.
Of course it’s not always been this way. The product that eventually became Lightroom — Shadowland — started out in 1999 with the first public beta in 2006 before version 1.0 arrived in 2007. Rolled into that first product was Pixmantec’s Rawshooter which enabled Lightroom to de-mosaic raw files, in addition to more traditional JPEGs and TIFFs. In one stroke it nestled up to Photoshop, leaving the heavy lifting for layer based editing, whilst specifically targeting the photographic workflow of ingesting images, raw conversion, and non-destructive edits.
The paradigm was to offer the digital equivalent of the darkroom, allowing you to develop your images to a final product. Perhaps this is where Lightroom really shines and highlights Adobe’s true focus: the creative process and ultimately the output. Lightroom was intended to deliver print and digital media which is why the book, slideshow, print, and web modules have such prominence. The crowning glory is arguably the image catalog which is incredibly important for maintaining a coherent digital archive and — again using the analog metaphor — as part of the creative culling process. It’s laid out as a contact sheet for a reason, to allow you to tag the photos you want to develop. Of course, the catalog remains the big buy-in: if you have your library of 100,000 photos then that is a big disincentive to move to another product.
This process has served film photographers for decades and fits the mold of the digital realm. Lightroom has hit the sweet spot when it comes to workflow and with each iteration adds increasingly sophisticated levels of photo development. All of this is non-destructive leaving the original digital negative untouched. So what’s the problem with this?
So What Is the Problem?
The dramatic expansion in digital photography from the 1988 Fuji DS-1P through to the rise of the burgeoning DSLR market fitted the niche that Lightroom was intended to fill. The DS-1P could shoot up to ten 0.4MP images on its 2MB memory card, whilst Nikon’s D1 shot 2.5MP images on to a 2GB CF card. Early on images were predominantly JPEGs, but DSLRs made the raw format more commonplace. More problematic was the vendor specific file so if you shot with different brands you needed a range of manufacturer software products to import them. Photojournalists exemplified the problem where multiple photographers, potentially with different cameras, needed to go from digital file to broadsheet.
What has changed since the birth of digital asset management is our shift as photographers to shooting more images than ever, using higher resolution sensors that create larger files. This “wealth of the visual” is creating a data headache that affects all aspects of the photographic workflow, foremost amongst these is the size of the data archive being created. When shooting film there was always an upfront cost associated with image processing: you paid for the film, the development, and then the printing. There was a cost at every stage, before you carefully indexed and filed your negatives. Digital was heralded as an almost “no cost” solution; you already had a computer and just dumped those tiny JPEGs in to a spare directory. However with cameras such as Fuji’s GFX100 creating 100MB+ size files you need large media cards, an ultra-fast connection to your PC, manifold storage, and a large back up solution. If you are a wedding photographer, shooting 2000 images for a single event is common, which creates a significant data processing headache. That’s 200GB of data for one wedding which needs to be ingested, culled, processed, delivered, and backed up. That entire processing chain costs a considerable amount to set up.
The problem still remains asset management, but added to this task is one of data management. It’s not so much that Lightroom can’t manage your photos — it can — but rather how quickly can it do it.
Rapid Asset Management
As a result of the much greater number of larger image files, we are now seeing pressure on the software that manages those photographic assets; when files were small there wasn’t an imperative to seek high performance processing, but this has become an obvious bottleneck. This is even more important in time critical photography such as sports and news, where you can be required to upload your imagery literally seconds after having captured it. There is an acute need for Rapid Asset Management in these domains, but all areas of photography would benefit from being able to rapidly cull and catalog imagery. I would then separate processing in to two areas: those that require simple batch driven edits and those that require more refined manual processing. The former benefits significantly from being integrated in to the culling process, whilst the latter can more readily be performed externally (for example, in Photoshop). Tethered capture is perhaps a special case.
Rapid Asset Management is relatively new as Lightroom has largely sat on its own, with bespoke products (such as BatchPhoto and PhotoMechanic) targeting the rapid processing of images outside of an image catalog. Competition has come in the form of image processing on its own (e.g. Photoshop, Affinity Photo) or photo based ingestion and de-mosaicing products. These tend to operate in the same vein as Lightroom, focused upon photo editing and broad global edits, rather than the layer based model of Photoshop. This has changed over the years with adjustment brushes, control points, and more recently adjustment layers. That said, integrated cataloguing has been late coming to many products (e.g. Luminar, PhotoLab, CaptureOne), yet this can be one of the most important tools for a photographer that can lock you in to a product.
I know one of the tasks I dread after a wedding is ingestion and culling. It can be a soul destroying monotonous task but in terms of delivering the final product, everything builds from this. It is critical to cull out the images you don’t want, tag the keepers, and flag anything else that is worth returning to. I then also want to color code them depending which media stream they will be delivered on. Lightroom is satisfactory for this process, but the import routine isn’t flexible enough to let me cull, tag, and keyword at the same. I find myself either importing everything and then culling/tagging, or culling only then returning to tagging later on. This either wastes time importing all the images I don’t want or repeating everything twice and then struggling with Lightroom’s more pedestrian pace. Added to this is the “Adobe Subscription Tax” when I would rather own the software outright. However other products are starting to gain traction in the market with ACDSee PhotoStudio, DxO PhotoLab, Skylum Luminar, and CaptureOne — to name a few — all offering alternatives.
It’s been 20 years since Lightroom first hit the drawing board and whilst it has huge market share, photography has changed in that period. Not least the sheer volume of imagery and the need for software performance to be top and center. Lightroom isn’t known for it’s speedy interface. However it runs deeper: I want to speed up my workflow and adding more developing tools to the interface isn’t top of the list. I want to see the greatest efforts put in to culling and tagging at the earliest opportunity, along with lightning fast performance. Does Adobe need to start again with Lightroom?
Lead image composite courtesy of hamiltonjch via Pixabay, used under Creative Commons.