Read this for other ideas of how to build a folder structure.
But itâs not a fixed structure. I only use dated sub-folders if there are multiple shoots for the same location/subject. Otherwise, one simple folder will suffice.
So, to start with, you are saying that my structure is rigid and now you are saying it is full of exceptions. You canât have both.
I have never said that my structure is the only way to do it - simply that it is how I do it.
I do wonder why people feel the need to rename files with dates included in the file name, as I find it easier to put a bunch of files taken on the same date in a folder with that date.
The file system, whether that be macOS or Windows, provides a direct way for uniquely indexing files, by providing a means of organising âstuffâ into a hierarchy of folders, which can be as complex or as simple as folks want.
The simplest of organisational methods is to put all files in one folder, but with each file uniquely named. Then you can simply search for files whose names contain certain characters, like a date or place or subject. Or you can organise your files into hierarchies of folders, created to best suit your particular methodology.
From the perspective of the file system, a fileâs name is not just something like DSC0001.NEF
- its full name is going to be something like ~/Pictures/France/Lannion/2022-01-23/DSC0001.NEF
. So there is no need to add in something like the place and/or date to the fileâs name as it is already implicit in the file systemâs path to that file. You only really need to rename a file with stuff like date and/or place if you donât use folders so named.
As you pointed out, Aperture uses a nested date folder structure internally but allows you to see the contents of a whole year or month at a time without having to keep switching which sub-folder you are viewing.
The big difference between Aperture and PL is that Aperture manages this nested folder structure internally, whereas PL only shows the folder structure that you create on disk. The problem being that PL doesnât coalesce sub-folders into a unified view by year or month, it can only show the files from one folder at a time, without showing those from its sub-folders.
The initial idea for my app was simple - provide a means of viewing all the images in a given folder, regardless of which sub-folder they were in, in one scrolling view - point, period, nothing else.
This then allowed me to organise my images how I personally wanted (Location|Subject/Year/Month/Day) and be able to instantly see all images for any of those levels and all of its sub-levels in one view without having to continually select sub-folders in a tree view.
At that point in the development of my app, I could now pick images from any of the presented sub-folders and compare them, regardless of which folder they are found in.
Here, I select two similar images - one from April 2021 and another from June 2021âŠ
⊠then, by pressing the spacebar, I get to see both of them, side by side, in a Quicklook preview panelâŠ
⊠and you will note that the Quicklook panel also shows the path to the currently highlighted image, allowing me to know which image came from where.
Then, after having created this ability to browse images in this simple non-hierarchical way, regardless of the folder structure on disk, I went on to add in keywording, searching; and smart folders, to emulate Apple Photosâ idea of albums or PLâs idea of projects.
As to having to use my app externally to PL, I find it no different than having to switch to and from the Library view to the editing view. After all, all I have to do when I find an image in my app is to double-click on the thumbnail and it opens in PL - exactly the same as it does when double-clicking on a thumbnail in the Library view. But there is also an added bonus - if I select images from multiple folders in my app and double-click, PL opens them by automatically creating a project for them.
Unfortunately, as with all features that seem simple to one user, it is very difficult to please all of the people all of the time. So, your usage might be easy but someone else will want to do it another way - witness the discussion on how to organise folder hierarchies, let alone renaming files.
Then you get the problem of overlapping or conflicting hierarchies. Take your example of Date - Place
. This might be convenient if you mentally organise by date and want to search for all places visited on a certain date, but if you mentally organise by place and want to search on images for a certain place, regardless of date, you now end up with having to look through all the files for several dates in order to find what you are looking for.
It is for this reason that many third party âorganisersâ use a database, which allows multiple âviewsâ of images, based on different criteria. And then you end up with an app like Aperture or Apple Photos, which maintains its own hierarchical structure, invisible to the user, but which presents the images sorted to suit the userâs requirements.
But even these apps are limited in the number of permutations of sorting that can be allowed and usually resort to keywords, tags or albums to allow the user to group various images together.
To my mind, an image editing app like PL would stick to what it is good at - editing images and producing the superb results that PL does.
Importing, organising, tagging and searching images is a very, equally, specialised domain, which needs a lot more thought and effort. Especially when PL allows a user to organise their images on disk, however they want.
⊠and then never move your pic around.
Thatâs a bit like saying never change where you live in case you canât find your way back to your new house
What Iâm getting at is the âfullâ file name is always unique, as long as it includes the path to the folder where it is stored. So, no need for unique naming of files.
Thatâs why Iâm putting date and something descriptive to folder and file name
â Time stamp expansion for image --DXO PL4 Elite - #2 by Wolfgang
The new folderâs name is used to mass rename those files â allowing a totally flat hierarchy.
If it wouldnât be so easy, I wouldnât have even dropped LRâs renaming capabilities some time ago.
But for sure, itâs not everybodyâs cup of tea.
â note
Iâm no professional, no âspare time wedding photographerâ â no regular high volume âprofileâ.
With concert or festival photography, I might return with 400 to 600 pics (2 cams), which I then have to sort out / put in order. And with some long holidays there use(d) to be plenty more pics.
Remember to have used keywords, when I got familiar with LR, but too much work â also never collected GPS data and such.
My files only get renamed with an addendum to show what is the Colour or B&W version, what is to print, what is for a book project and what to send out â very simple.
â I donât rely on LR, PL & Cie â and also not on a DAM.
What I need in PL are easy to understand & use star ratings and colour labels.
Iâm definitely in the camp of âeach to their ownâ, so whatever works best for someone is what they should use. Having said that, one way to improve at anything is to consider how others do things and whether they offer possibilities for improving your own methods.
I store my images in a folder hierarchy of decade\year.
Within year there is a sub-folder for each âsetâ of images, where âsetâ could be place, event, person etc. The âsetâ sub-folders are all named mm (mmm) #n - description,where
- mm is 01-12 (so they sort in time order)
- mmm is the first three characters of the month - I know this repeats the mm info but I want the folders in date order (hence mm) but find it quicker to read the mmm month name if Iâm looking for a particular time of year
- #n is a count to keep each folder name unique even if the description is the same for two on the same month
- description briefly says what images the folder contains
For example:
Pictures\2010s\2015\10 (Oct) - #2 - Munich
The image files are renamed, prior to any processing, from the âout of the cameraâ names to, for example
2015 10 #2 - Digital RAW-001
where
- yyyy mm #n reflects the sub-folder in which the image will be / is stored
- Digital RAW reflects the original source of the image (and could be JPEG for earlier digital camera JPEGs, Slide for scans of transparencies, Negative for scans of film negatives and Scan for scans of prints
For me, the value in the filename reflecting the location folder is that if I have shared an image (e.g. via a Google Photos album, email, WhatsApp or whatever) then the image filename lets me quickly locate it and its related images in my storage structure.
I know there are other ways of arranging my images but Iâd assembled a large collection before I even considered keywords. Iâve followed the threads on DAMs with interest but so far wouldnât feel sure about which product to base my keywording on, and canât really face tackling the large backlog of un-keyworded images, and so I follow these discussions with interest.
My observation over many years is that people seem to gravitate to either a storage structure way of organising things (images, emails, documents etc.) or donât worry too much about storage structure and rely on being able to search quickly for what the want based on the items metadata (keywords, dates etc.). Iâve spent so long in the former camp I think Iâd find it very hard to move towards the latter.
And this maybe explains why so many people rename their files on import.
But let me suggest that, if you could systematically and meaningfully name exported files when they are exported, you would not need to rename the originals.
e.g.
I have an image in my folder hierarchy ~/Pictures/France/Lannion/2022-01-23/DSC0001.NEF
The default export name would be simply DSC0001_DxO.jpg
, which is obviously ambiguous as it could come from any folder.
However, if PL could export using a user-formatted name, for example %d_%f.jpg
, where %d
is the directory and %f
is the filename minus the extension, wouldnât this better solve the problem than having to systematically rename all your files on import?
âŠI rename files on import with Lightroom and it mostly provides unique filenames - unless different cameras happen to use the same four digits, which is rare because I mostly use one camera only.
Renaming files on import would be helpful imo, as would be the renaming on export.
The problem being that PL never truly âimportsâ files, it just reads them from the folders where they live.
I âimportâ my images from my camera by simply connecting the camera via a USB cable and using Image Capture. Now, that kind of functionality is difficult to integrate into an app like PL because it requires special camera manufacturers APIs to talk to each different camera. Otherwise, for me, it would mean me having to buy an XQD card adapter and removing the card from the camera after every shoot.
With no renaming you will get double names after a while.
I rename them GW_yyyymmdd-xxx. And the folders by day, yyyy-mm-dd and eventual with a topic after it.
For me simple enough to remember the names and smart enough to find images back.
George
I agree. With export one can at least create subfolders. But ocassionally it was very helpful to rename exported files with EXIF tokens such as aperture, ISO, camera type etc. Possible with Capture One.
Then how come the file informations into PLâs database? I believe in standard setup PL is also applying presets depending on RAW-type, so some actions happen when PL âjust readsâ. And as soon as PL is reading images, one can also rename them within PL - so why not make takt easier and more versatile?
Not if you never import into the same folder more than once.
But that is not importing the image files, it is importing the metadata.
I donât see the point of importing all that metadata into PLâs database when you havenât even sorted the files from the camera and thrown out all the useless ones. Most of the time a lot of files can be trashed from Finder.
Not only XQD reader but also CFE. Although the cards have the same size, the readers need to have a firmware capable to read both sides (Nikon Z uses both types, D850 less so).
On the other hand, each time you connect your D850 to the Mac yourâre wearing out the USB port which is expensive to replace, especially the USB-3.0 Micro-B flat type in the D850. That port I reserved for tethered or remote-controlled shooting.
So, removing and inserting a card doesnât wear out the contacts there?
Copying an image outside your structure might result in double names. Beside that your way makes it difficult to find the place in your structure once the file has been moved/copied to another place.
I rename the pictures based on the date shot. ViewNx2 reads that date from the exif. I thought other programs take the file or system date.
George
Much more massive.
George
Why would I want to do that? I only ever keep one (original) of an image. The only âcopiesâ I make are by exporting them from PL and those are deleted as soon as I have used them. If I need another copy, I just re-export.
I can see that if PL could rename files on export to include elements that you suggest, such as the folder name, then some would find it useful. However, Iâd then be faced with an exported file, e.g. the .JPG, whose filename didnât match that of the original RAW file or sidecar .DOP (and .XMP). Renaming the files prior to any processing, by whatever method suits, means that the filename is the same across input, PL created sidecars, and output(s).
[My initial workflow is to transfer the images from my Nikon DLSR to my Windows PC by plugging my camera in via USB and then using Nikonâs Transfer 2 product. I then create the required sub-folder(s) and rename the RAW .NEF files using a quite powerful Windows âfreewareâ product, FileRenamer.]
I retain the RAW originals and exported JPEGs. If I want to browse through my images I use something quicker than PL and I prefer to be looking at the exported results rather than the initial RAW images.
So, how does that work out if you create and export more than one virtual copy, where the exported file files have the same name but different endings?
So, are you saying that you export every image that you process? Hmmm. Something I find so useful about PL is that I donât have to fill my disk with duplicates like that, but each to their own.
I use referenced files in C1 as in PL and I call both âfirst acquaintancesâ import as files or part of files are transferred to another place.
In a well made database all deleted files and their metadata are wiped out after deleting the master file, they donât remain. True, some images I can sort out using finder, but why bother with slow quickview? I prefer the view in PL or C1, this way I already can try some kind of edits. Also, you say youâre using Image Capture to download your images. Whatâs the difference between download and import? The âimportâ word is also used in various image editors to insert one image into another.