If I had a dollar for every Lightroom user who doesn’t understand where Lightroom put their photos, for every user who has deleted the photos they found in Pictures because they thought Lightroom had its own copy in a database somewhere, and for every user who has question marks on their folders and “missing file” warnings in the Develop module because they thought that the only way to reorganize was to go out to Finder or Explorer, I would be retired and just writing this blog for fun. And yet it didn’t have to be this way – I think there would be far fewer tears (albeit still some) if Adobe had made one small change to default behavior in the Folders panel.
(Don’t get me wrong by the title of this post though – I love the Lightroom team and for the most part I love what they have developed for us.)
That said, who would guess that the Lightroom Folders panel that by default looks something like this:
A Sample Folders Panel with the Default Behavior
can be quickly set up to show you where your photos reside on your hard drive(s)? Who would guess from this default view that you can use the Folders panel to reorganize your files and folders (on your hard drive) without getting the dreaded question marks and missing files warnings that plague new and experienced users? Here’s an example of a much more useful Folders panel:
A Folders Panel with the Folder Hierarchy Revealed (and Folders Renamed to Include Descriptions)
By default the Folders panel only shows you the specific folders that you imported, not where they reside on your hard drive. I consider this decision by Adobe to be one of the biggest mistakes they have made with Lightroom. Nevertheless, I haven’t convinced them to change this default behavior, so I’m writing this article to make sure you know how you can fix it. (Of course if you’ve watched my Fundamentals & Beyond video series, you already know this.)
Setting the Folders panel up to show folder locations (i.e. the folder hierarchy):
- Right-click (Ctl-click with a one-button mouse) on any folder that doesn’t appear to reside inside another and choose Show Parent Folder to reveal what folder it resides in. Right-click on this revealed folder to show its parent, and so on, until you can see exactly where all your folders reside.
- If you reveal a folder that you decide later that you don’t want to see, right-click on it again and choose Hide Parent. For example, if you reveal that Pictures lives within your name folder within Users within C:, and later decide that seeing folders up to the Pictures level is sufficient, right-click and hide C:, then hide Users, then your name folder. Note that you can’t hide a folder that has photos sitting directly in it (rather than just in subfolders) – if you don’t see a Hide option when you right-click, this is why.
- That’s it!
Now that you can see your hierarchy you can use the Folders panel to:
- Finally understand where your photos reside on your hard drive. Now that you do, be sure that your hard-drive backup program backs up this location since Lightroom does not back up your photos.
- Create subfolders. For example, to create 2016 within Pictures, right-click on Pictures and choose Create Folder Inside “Pictures”, and type 2016.
- Move folders by dragging and dropping. For example, move your 2016-05-15 folder into 2016 by dragging it and dropping it on top of 2016. This moves the folder on your hard drive, not just in Lightroom. Doing it from within Lightroom keeps Lightroom (and therefore you) happy. Doing this reorganization outside of Lightroom – out in Mac Finder / Windows Explorer (My Computer) – is what causes the question marks and missing file messages – Lightroom can’t see you do this, so it no longer knows where your files are and is pretty upset with you – this sentiment is usually mutual!
- Watch my video tutorial from an old version of my Fundamentals & Beyond series for more on how to use the Folders panel to reorganize your folders and photos.
Once your folders are all nicely organized, take the next step to making the Folders panel truly useful – click on each of your date folders, look at what photos it contains, and then rename the folder to include a description of the shoot: right-click on your folder, choose Rename, and click after the date to add the description (or delete the date if you don’t want it – just keep in mind that this will change the order that your folders appear in the list from chronological to alphabetical).
Finally let me say that I wouldn’t have the default behavior be to reveal parent folders all the way up to C: or Mac HD – it would just be to reveal the folder structure up to the folder selected in the Destination panel in the Import dialog. Most people organize by date, with Pictures selected. The Folders panel in this scenario would therefore automatically show Pictures, and the date folders within it.
PS: I’m ultimately in favor of an optional managed-database solution, where management of files would be taken out of the hands of users so that new users are better protected. In this scheme, more experienced users or computer-savvy users would continue to be able to choose the current referenced-file solution. In the meantime though, as someone who works with beginners, I do not understand the decision, stuck to for years, to hide from users where their files are and to not make clearly accessible the option to reorganize folders using the Folders panel.
Agree completely. Adobe assumes erroneously that serious LR users are also so well-behaved and tidy that they will never break the law and use the Explorer/Finder to sin around with their pictures.
This kind of assumptions just breed confusion and keep new users away, not to say generate countless rants. Old time photographers and even newbies that still use outdated software will navigate in difficult waters with these rules that LT imposes. Consider that they are used to organize the folder structure first, and that this whole new concept of database organization/editing is a rough terrain to cross.
A transparent way and quite easy to Adobe address this would be to offer an opt-in feature that would monitor (a background process/deamon in nerdspeak) the pictures folders – even if LR were not in use -, so that when the user changes **anything** in these folders by way of the Explorer/Finder, the LR database would be synchronized accordingly. A sub-feature to this opt-in would be to consider new additions as imports, so that they would be shown in the New Imports collection – using the default import presets.
I have been using Lightroom (on OSX) since it’s official birth (close to 90 000 pictures now ), and find this behaviour quite natural and ver effective. It leaves the user to use the flexible hierarchy of its OS file system. It is correct that you never should move folders using the finder (or Windows equivalent), but if you do that it is imperative that you go into LR to correct the pointers immediately. LR documentation tells you this.
I have tried out the archive systems, but found me enclosed in the restrictions of the organisation structure, like Apples Photo.
What i really miss is the display of a common description file for each folder.
I am in love with Lightroom!
Without the fear of being repetitive, LR is so intelligently conceived that is too easy for beginners to assume that LR will take care by itself of this so-dreamed-of reflectivity between actions done with explorer/finder and its catalog.
Everyone can remember some small soon-forgotten renaming/deletion/addition/copy/move made outside LR that had to be tediously synchronized afterwards.
Moreover, folder restructuring is always best done with two from-to explorer/finder windows open side-by-side. Having to replicate this effort inside LR is unnecessary madness.
Adobe, where is our transparent folder monitor???
I completely agree and this issue has really, really frustrated me. Not to mention that I got a new laptop that has Microsoft 10 and their default is to have everything upload to their cloud-base storage location, OneDrive.
Is there any way to have the most recent dated folder at the top, and not at the bottom, of the dated list of folders? It is a lot of scrolling to get down to today’s folder.
Move your date folders into year folders, Carol, and keep all the old years collapsed so that you don’t have to scroll very far. Otherwise you’d have to change the names of your folders so that the more recent ones have lower numbers – “00 2016-05-01”, “01 2015-xx-xx”, etc.
You can create a short cut to a folder. I have my folders organised by year and project. Every year I create a short cut to the current year. The shortcut dialogue appears when you click on th band above the bottom panel of thumbs in library mode.
The default of digital asset management based on dated folders/subfolders is a major stumbling block and creates access and understanding problems for many using lightroom. If one is curious as to the date of a photo it can be accessed anytime from the metadata. Surely, there are many of us who have little, if any, interest in attempting to access photos based on categorization by date and find this approach arcane———even when we understand where the folders containing the photo files are separate from the catalogue. Another expert lighroom guru, Tim Grey, also finds the organization by date a significant problem. I realize there is no perfect categorization system to suit all in this context, but I find the current default system of folder/subfolders based on date more of an issue than where the actual digital photo data is located. The lighroom library needs fixing at several levels.
The Lr app ( with the exception of the Book module) is very well designed.
Unfortunately, Adobe only gives lip service to usability. As far as I can see, Adobe engineers prefer to work on the cutting edge of image manipulation, but mostly ignore the user perspective and the massive improvement that could be made by putting a modest level of resource into fine tuning usability. Lots of good ideas in their suggestion forum which have been ignored for years.
The poor presentation of the Catalog as a concept and from a GUI perspective has seriously hampered the adoption of Lightroom by a massive audience and is just one example of how Adobe ignore the end user perspective.
I r gularly give one to one sessions with photographers, who have serious challenges grasping the catalog concept and understanding where their images actually live ( eg still on the card, in MyPictures, inside the Catalog, in the Cloud …….. or somewhere else…?..
I totally agree with the substance of this article.
I agree that native file-organization structure is befuddling and bedeviling. Because I did not start out doing what Laura advises, I have a gazillion photos heaped willy-nilly into one huge mountain. Hence this question: How does one undo the mess?
It depends on how messed up it is, Thomas. The first option is to reveal your folder structure and then move things around manually using the Folders panel, as I show in this tutorial. Another option is to start over, having Lightroom slot everything into new date folders. This has its downsides though, as explained in the article.
Thanks for reply. Have rec’d conflicting advice on “remedy.” Fifteen-thousand files involved, so ain’t about to start over. Falling on one’s sword preferable to that. Look fwd to Sat. webinar.
The “optional managed-database solution, where management of files would be taken out of the hands of users so that new users are better protected. In this scheme, more experienced users or computer-savvy users would continue to be able to choose the current referenced-file solution.” is exactly what Apple Aperture uses. It is incredibly intuitive for beginners yet permits more sophisticated folks to have the freedom to reference their files. I was a happy Aperture user for years and have come into the LightRoom fold due to Apple’s lack of support. Aperture pioneered so many wonderful features in its day. I can’t understand why LR isn’t copying this process.
Can you move single or sets of photos into different folders in your hard drive within Lightroom in the manner you described?
Yes, Harriet. I have updated this post with a link to a video tutorial – it’s in the last bullet point. (If you have my Lightroom CC/6 and 5: The Fundamentals & Beyond video series, watch the video on File and Folder Management.)
Laura, thanks for your excellent content!
FWIW, here are some reasons to store photos as files rather than databases, and why I don’t think it’d be a great idea for LR to do the latter:
* Performance: databases are good for lots of mostly small but related bits of information (eg develop settings and metadata) that need to be updated or queried (especially joining data in the DB), but files are always faster to access if you know where to look (ie, the filename) because the OS maintains an index of where files and file fragments are on disc. Databases do this, too, but aren’t as efficient as an OS because DBs can store any sort of data, where a filesystem is database fine-tuned for the needs of storing files. The OS is also tuned to make file access as fast as possible and the combination together will always outperform a DB that itself is stored in files in the filesystem.
Perhaps more importantly, the OS seemlessly manages fragmentation. If LR were to store image data in a DB and even though LR never modifies image files themselves, the DB would soon become fragmented as images are deleted and added. If it just appended to the database rather than reusing space once occupied by a deleted image, then deleting an image would never recover space. Reusing space is what leads to fragmentation (amongst other things).
The advent of SSDs make this an even bigger deal than used to be the case because SSD cells wear out with every write. SSDs combat this by wear levelling so that when a logical block is read and rewritten, the SSD can reallocate the new data to a different, less-used physical block. But that only works if the OS knows the space is free and tells the disc when a block has been deleted, which isn’t possible with a long-lived DB file because the OS doesn’t know which blocks are unallocated.
The OS makes all that pain go away and since filesystem design is a pretty nontrivial subject, the OS almost certainly will do a better job than Adobe can ever hope to do. IOW, Adobe are graphics not OS experts, and time spent on OS functions is time not spent on developing the Adobe suite.
* Backups: You can’t do incremental backups on a database, you can only back up the whole DB, even if the DB stores across multiple files which takes a lot longer. Relatedly for disaster recovery and repair if things get desperate enough: it’s much easier to find individual files than figure out which sector/cluster/block belongs to a proprietary DB structure (and where!). Depending on the internal architecture of the DB, corruption in one place might affect the integrity of everything, where corruption of one file can only affect that file.
* Portability: most storage formats other than hard discs and SSDs have fairly small file size limits, usually 2 GB. DVDs can only store ~4.5 GB anyway, BluRays ~25 GB and although larger USB sticks are available, the default filesystem (FAT32) is still limited to 2GB per file. That makes it harder to make backups and copy catalogues around.
* Vendor lock in: how much do you trust Adobe, either in terms of continued access to the software or to handle image data without bugs that cause loss/corruption? Bridge, for example, is (or was) notoriously buggy and I would never entrust decades of photos to a third party that exists principally to make money out of me. Yes, you can still export even after a Cloud licence has expired (I gather), but you still must trust Adobe that they won’t change their policy on that.
* Other applications: images stored in a database can’t be accessed by other programmes without being exported, including by other members of the Adobe suite. Yeah, you could add support for LR DB access to Photoshop, but that’s needless work, the flow would probably be different from disc files and there would likely be other subtle restrictions that would prove a nuisance. If you’re going to have to export data (possibly with XMP) anyway, you may as well stick with files.
(Source: I’m a computer scientist by profession.)
Good information, David, but I’m not sure what this is in response to. Lightroom doesn’t have an option to store photos in its catalog / database. Only edits and metadata are stored in the catalog, and their is an option to optimize it, which is basically a defrag.
Laura, it was a response to your postscript concerning a managed database solution in favour of file references as a means of protecting new users from moving folders outside of LR and messing up the LR catalogue.
The catalogue database is (or should be, I haven’t looked because I’ve only just begun using LR myself and only shots taken since I upgraded my DSLR have been imported into it) very small compared with the collective associated photo data, especially if one works primarily in raw format.
That is a good example of what should be in a DB: each object is small (most << one disc sector or filesystem block) and there are multiple objects associated with each other which, in turn, are associated with one primary image (plus maybe one or two sidecar files). Rapid access to these data is critical for LR's UI performance which is where DBs excel. If the DB is relatively small and given how desperately inconvenient it would be to lose the data stored in it, one can do incremental backups on the source images and full backups of the catalogue(s) each time without trouble.
Backup strategy is, of course, a separate matter — which I can write about if you like ;)
Ah, I see – I didn’t remember that I wrote about that. ;-)