Historically, Adobe Lightroom (Lr) was undisputed leader for photo management. However, after Adobe introduced subscription model for Lr, the market for DAM (= Digital Asset Management) has become very competitive, especially after some new entrants in the market recently.
Lr used a philosophy of non-destructive editing. This means, your original photos are untouched and whatever edits you apply on them inside Lr, it is stored in Lr catalog as parameters. Whenever you open your image inside Lr, it dynamically applies the changes to your images.
This creates a problem if you want to access edited version of your photos outside Lr. The only option to do it, is to export all your edited photos our of Lr, so that changes done inside Lr are permanently applied to (same of new versions ) the images.
Lr also forces you to import all photos to its catalog first, before you can do anything with them. The import, the one off (for each image), is a time consuming process. During import process, Lr performs following tasks:
· Adds image parameters e.g. EXIF data into its catalog
· Creates a thumbnail (known as preview) image
You can dictate the quality of your thumbnail image. Whenever you view your photos in Library (usually in grid mode), Lr shows you the previews. If you want to view your image in 100% zoom mode, it then reads from disk file. This causes a lag (couple of seconds depending on your computer spec and image size) for each image to appear.
To improve the performance, you can ask Lr to create 1:1 (i.e. full size) previews (and you can set it to discard after X days) but it then creates duplicate copy of each photo inside its previews folder.
Lr has a concept called Smart Collection. This is where you define the criteria for your search (e.g. show me 2018 holiday photos with rating 3 and above etc.) and Lr will fetch you the images on the fly. This means, if you change rating of an image from 2* to 5*, it will be dynamically added to your smart collection.
So, while Lr is a very good DAM program, it is poor in browsing photos (unless you are happy to duplicate all your photos inside Lr previews catalog).
The Lr catalog is a single file, which is an Sqlite database. It is possible to run SQL statements to query the database outside of Lr. You can extract details like image name, rating, label, caption etc. out of this catalog. Note that, extracting data from Lr catalog by running SQL is not officially supported by Adobe.
But the good news is, if you ever want to move away from Lr, you can take your data with you (whether you can import that into your new DAM program that is an entirely different question).
So, in summary, if you use Lr, your typical workflow will be like below:
· Import images
· Edit them (rating, caption, post processing etc.)
· Export desired images (to browse quickly outside Lr)
Before I discuss alternatives, lets us understand the difference
between Lr and Photoshop [Ps]. Lr is a DAM program whereas Ps is an image
editing program. Lr is parametric editor and Ps is a pixel based editor. If you
edit image in Ps, you must save it on the file (or using a different file name)
else your edits will be lost.
Another popular freeware (and cross platform) pixel based editor is GIMP.
Now let us discuss what Lr alternatives are.
The first one is Digikam (DK), which is free and cross
platform. Its concept is very similar to Lr. You import images to
its catalog, you rate/edit them. DK will prompt you to save all your edits. So,
you are kind of exporting all your images as you edit them. DK also has dynamic
search capability.
If you have never used any DAM before, then Digikam is a good one to go for. DK also uses Sqlite database to store its catalog. Unlike Lr, where previews/thumbnails are stored in (cryptic) folders in disk, DK stores thumbnails in another Sqlite database. You can run SQL statements on DK catalog. DK catalog data model is simpler than Lr's.
The next free/cross-platform alternative is DarkTable (DT).
The difference between DK and DT is that, DT has better editing capability than
DK.
If you shoot raw and do plenty of post processing then DT is better. If you
shoot JPG and do minimal post processing (e.g. auto exposure, crop etc.) then
DK is easier. If you are trying to choose between DT and DK, I would suggest
that you download both and give them a try and then decide which one you like
more.
There is another free Lr type tool called Raw Therapee. But this is only for those who shoot raw. Hence, I did not test this one much.
Now we are coming to commercial software section.
The first one which caught my eye is ACDSee Ultimate. It
has few variations with different capabilities but overall mechanism is same
across all versions.
Unlike Lr, ACDSee does not require importing photos. You just open your image
folders and browse using ACDSee. In the background, it does populate its
catalog database with image metadata. So, its workflow is simplified like
below:
· Browse images
· Edit them (rating, caption, post processing etc.)
Export is optional as your edited photos are saved in disk (ACDSee
will prompt you to save edited photos). However, ratings/labels/captions are
saved to catalog only by default. You can choose to save this inside our JPG
images if you want. ACDSee has Develop module (where you do can
parametric edit like Lr) and Edit module (where you will be prompted to save
your modified photo).
ACDSee offers you to export basic metadata from its database as text file.
ACDSee uses DBase as its catalog. Running SQL on ACDSee catalog is more complex
compared to Lr catalog.
ACDSee also offers usual DAM features like saved search, smart collection etc.
As ACDSee reads images directly from disk, browsing images inside ACDSee is
faster than Lr. ACDSee can directly import some metadata from Lr catalog, which
makes migration from Lr easier.
The next program is Capture One (C1). I did not use it extensively as its interface seemed bit confusing to me. It has same concept of importing images to its catalog (just like Lr). However, on first start, C1 also offers you to choose between catalog vs session mode. Consider session mode like folder based workflow. C1 encourages using catalog based workflow.
The next product is Bridge (Br) is another Adobe product but free! Unlike Lr, it does not have catalog system but you can have collections in the form of XML files. Using Br you can assign rating, caption etc. to photos but not edit. You need a separate program for edits if you use Br.
One point worth noting you can use different program for image management and editing. For example, Digikam for DAM and GIMP for edits.
The drawback of catalog based DAM is that their makers intentionally make your life harder by refusing to allow export/import metadata to/from their programs. This is because they want to hold you hostage of their proprietary catalog format. You can manually export metadata from most catalogs by SQL hacks but those are not vendor supported documented methods. Even if you can export those metadata, it is very difficult to import such information inside a different catalog based DAM. So, if you go for a database based DAM, you are likely to stuck with same program for years! Simpler the program, easier is for you to get out. This is why most DAM programs are very complex, to captive you with plenty of proprietary tools so that your migration to a different DAM becomes as hard as possible.
If you do not need DAM but just want to browse photos then there are plenty of good programs. The free FastStone Image Viewer is a good for fast browsing (but no filter/rating etc.). There are some similar programs which allow you to assign ratings to images but you cannot query them (no catalog) and it also updates last modified time stamp of the image.
Most DAM applications focus on following workflow: start with thumbnails with images in selected folder. I think this is a flawed strategy at the moment. The Windows Explorer (or any OS specific file manager) can do the same - often faster than 3rd party DAM applications. There are 2 main drawbacks with creating thumbnails first. If user is trying to show several thousand photos, then thumbnail generation is time consuming process and application becomes very slow and/or unresponsive during this time. Also, as these thumbnails are saved in some kind of database within the application, the database grows big over time and requires some clean up later to optimize performance. Some apps try to populate thumbnails background but even then if you browser folders from various places (memory card, USB disk etc.) which you are less likely to access again later, the thumbnail generation for future use is somewhat wasted effort.
This is why when I developed Image Viewer Catalog, I focused on loading only one image at a time from the list file! I still offered thumbnail generation but it is on demand rather than by default. I took a conscious decision to avoid clutters (i.e. too many features) which often confuses the users and slow down overall workflow.
Note: This article does not cover all DAM applications. There are plenty of them and just choose one according your need and liking.