I fully accept that Keywords/Tagging are better and I am trying to use them much more, as I find PL5’s system usable with its ability to nest tags. But I still find it useful, if a folder is a specific location or subject, to add that to the filename as in “2022-03-28 - London Zoo”. The full date is as much to keep folders in a meaningful order as anything else.
Thanks to those who pointed to examples of third party options (I used to use Breezebrowser, possibly in pre-Lightroom days, and had no idea it still existed). However, I already have two third party apps that do the job - Lightroom (Library Module only as my subscription has expired) and Capture One. But I would rather not have to keep them up to date for this one feature. In general, If people want sophisticated features, using a third party app makes sense, but my thought was that a fairly basic download facility would be easy to provide, and it would make it possible for people who were satisfied with that to do everything in PL.
But if such a facility were more complicated to implement than I am assuming, then I can see the arguments against it. Other priorities are more important.
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…
… 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.
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.
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
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.
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?
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.
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.
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.
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.