I generally find that I can do most of the processing I want to do in PL5/Nik, with some use of plugins. However there is just one feature for which I regularly use LR or C1: I like to copy files from SD cards into folders on my hard drive according to the date on which the photo was taken. I do this in LR (just needs library module, so subscription not needed) or C1 before closing that app and then opening up PL5. Surely such an “Import” option would be very straightforward to implement, and a lot of people would use it, because doing it manually using Finder (Mac) or the Windows equivalent is fiddly if the memory card contains photos taken on different dates.
Hi Roger, could you show an excerpt of your folder structure, so it’s a bit clearer how you (exactly) organize your pics?
Very simple: I use a hierarchy /Digital photos/Year/Month/Date
So photos taken today would go into “/Digital Photos/2022/03/2022-03-22”
Afterwards I sometimes edit the folder name manually to add information about where the photos were taken that day, as in
“/Digital Photos/2022/03/2022-03-22 - Birmingham”
but I am increasingly using PL5’s tagging to label them.
The reason for the nesting Year/Month is to avoid having folders with extremely large numbers of sub-folders that take ages to scroll through. I used to do it with just Year/Date, but the year folders had too many subfolders for convenience, so I added the extra layer of nesting. I think I started doing it this way, because it was one of the options in Lightroom. Capture One has a particularly versatile system that can be configured to file photos in the same way as LR.
A copy feature could be nice to have…if it included renaming features that are based on metadata and allowed custom text, renumbering etc. Examples:
- add a shot date prefix like e.g. 20220321 or 2022-03-21 or 2022/03/21 etc.
- add e.g. camera model or serial number
- remove name parts like IMG_, DSC_ etc.
- and more
Addendum: I rename files on import with Lightroom or use Graphic Converter (Mac only) to rename files in those cases, where I’ve not used Lightroom at all.
PS: Copy function not limited to SD cards 
1 Like
I have done the same thing (except I just use “DD”) from the very beginning of digital, somewhere around 2002. It was one of the options I selected in the Canon software I was using then. I selected it because of the computer practice I learned from Unix of keeping folder structure/file names relevant so that things can be ported to different systems and still mean the same thing.
However, that can lead to an endless rabbit hole of photo ingesting. For a long time, I used a simple, small program called image ingester by Marc Rochkind who based his work on the seminal “DAM” book by Keogh. I did this because I changed camera brands and decided I needed a neutral software approach. However, in 2017 Marc stopped supporting the program because keeping up with the ever changing OS’s of Apple and Microsoft (and the ensuing obscure bugs) was not sustainable for him.
1 Like
This is part of the rabbit hole I mentioned in my other comment. Everyone has their own idea of how to organize their files and folders and how to name their images. Thanks to exiftool, most metadata can be used in naming schemes. However, keeping this running as various OS’s evolve can be an intensive project. As of right now, the two generic solutions I know of are Photo Mechanic which costs about the same that PL does. Another solution that I know of and use (though it’s a little nerdy) is Advanced Renamer which only exists for Windows. Along with renaming based on exiftool and file metadata, it can also move or copy files to metadata derived folder structures. It costs $30 for a commercial license, so it’s relatively affordable compared to PL.
I offer the guess that the cost of engineering and supporting a truly flexible ingesting/copy/move option would raise PL’s cost.
P.S. Adding to the complexity is when you want to ingest directly from the USB or wirelessly connected cameras. For example, Photo Mechanic won’t do that. Advanced renamer can get to my Canon attached cameras and read metadata just fine, but on my iPhone it can see the folders and files but can’t get the metadata. I copy those to local disk, and it can read them just fine! These are some of the issues an engineer faces.
had been looking for → Time stamp expansion for image --DXO PL4 Elite - #2 by Wolfgang
which shows, how I organize & rename (manually)
Big Mean Folder Machine 2 from PublicSpace does exactly what you want on Mac. You might want Better Finder Rename and Better Finder Attributes if you pick up BMFM. The cheapest way to get them all in forever upgrades is to buy a single €19.95 version license and then upgrade to a forever upgrade license of the Big File Management Bundle for €59.
Though I own PhotoMechanic I still prefer the file renaming in Better Finder Rename and use it every week. Reason: I’m in Europe and Better Finder Rename lets me deal with accents and spaces in file names better than PhotoMechanic. Otherwise the functionality is very similar.
I support this.
At first I wanted to ask why you use redundant information in this file path. Then I realized I might do the same, just with the file-number out of camera. And a folder for each camera as otherwise sorting of images, DOP and XMP is only possible within PL (so much for non-proprietary file fiddling), but not in finder. Which I use to rename the files before I start PL.
In C1 it’s possible to use tokens (as variables) to rename files and also to mix them with any kind of texts. Makes it a bit easier to not care about the proper date in the file-name as it’s inserted by the software.
All of the above is totally redundant to me.
The memory card in my Nikon D810 was CF format, the one in my D850 is XQD/CFexpress and I don’t want to have yet more adapters hanging around or getting lost. So, for years now, I simply use a USB lead to connect my camera to my Mac and use the Image Capture app that comes with macOS to drag/drop the files into a suitable folder hierarchy in Finder.
As to needing to sort images into those folders, I have a simple approach. Under my Pictures folder, I create one folder per location or specialist subject. Under those, I create one folder per year, then, within those, I put one folder per month. After I’ve done a shoot, I simply create a folder for the day of the shoot and drag the files from that day’s shoot into it.
I don’t rename my files because they are guaranteed to be unique within the day/shoot folder.
I use my own software to keyword files and create smart folders (projects) based on searches for certain keywords.
So, in Finder I get…
… and in my software, I get…
One of the most complicated systems I saw so far. In your software you have an overview over the days of shooting at least (why not split it into more folders with hours and minutes? 
) And what you never get this way is an overview of a week or month - you always have to create an intelligent folder first.
Sorry, my main concern is editing the images, not building a supercomplex folder>folder>folder>folder>image structure. Plus keywords. I simply can’t see any advantage, but a ton of disadvantages, speaking just for me. But cool, if you’re happy with that. I just tried to imagine the orgy of scrolling within PL and went 
I don’t think you’ve quite got the idea.
I can display every single image in any folder, including from its sub-folders, or I can drill down if I want to.
Here’s what you get when you select a location…
… with dividers for each year sub-folder, but no need to select each one in the tree.
Then you can either double-click on the year divider or select a year in the tree to give you…
… with dividers for each month sub-folder.
Next, you can either double-click on the month divider or select a month in the tree to give you…
… with dividers for each day sub-folder.
Finally, you can either double-click on the day divider or select a day in the tree to give you…
When it comes to smart folders, you create one from a search for keywords, tags or ratings and it appears in the tree. When you select it, you get a view of all the images that match the search, divided by the place, year, month and day they were taken on…
Of course, there is no requirement to organise your images in the same hierarchy - that is purely my preference. The key to the utility of my app is that it flattens any hierarchies for browsing purposes and, thus, allows you to browse every single image in your collection without having to keep on changing the selected folder in the tree.
And the smart folders transcend any folder hierarchy to give you all the images for a given search, but allowing you to see where the search results have come from within your main hierarchy, if you have one.
But that is exactly why I wrote my app - to avoid all that unnecessary scrolling in the tree view. The flattened hierarchy is the key. I can browse all images for a selected location (or whatever top-level folder) if I want, irrespective of the date taken and then I can drill down as and when I want without touching the tree view.
…some redundancy can be helpful, depending on what you want to achieve.
Example: If you want to be able to search for all the photos that you’ve shot in March over the years, a YYYY/MM/…structure is helpful…but search results will not readily tell you which March it was, therefore you might want to change to a redundant naming like YYYY/YYYY-MM…/
We can also be flexible and use something like
- YYYY/YYYY-MM-DD for specific day folders
- YYYY/YYYY-MM-00 for a folder that covers several days, e.g. for trips
I’m aware that this thread is evolving into something different than the thread opener wants. And I’m not criticizing your system of folders, @Joanna . You made me look into Aperture’s structures and except your concept of place names, you came up with something similar of what is in an Aperture library.
No, actually not, as you first need to specify each place you took a picture. Onboard of a ship or an airplane, I just leave aside. I try to get why I find your system upside down.
This map I got out of Aperture from one walk on one day. As you can see, not each picture was done at the same place. Okay, I could use the river Orbe as a place=folder, but that “place” is 63.5 km long. Which makes me think that you see your projects bound to places?
Anyway, looking into old Aperture commands more and more respect from me for what it’s creators thought of and how they “did it”. Magnificent. And very sad as I see it until today the best way to manage my images. Much better than any “manual DAM” concept I’ve seen until today.
2 Likes
As the original poster, I have no problem with the way the thread has developed. It is interesting, if developing faster than I can follow it.
One question was why I include redundant information. The answer is that, suppose I take photos every day, when it gets to December, do I really want to have to scroll down 360 odd folders to find the one with today’s photos. Hence dividing them up into months. I just left the folders of individual days as they were, because I saw no need to remove the info. Platypus’s reason is a good one too.
I use Downloader Pro from Breeze Systems (not free) to create file folders and image file names that are meaningful to me. I could also do the same using Nikon Transfer that is free and part of Nikon NX Studio. DP uses sidecar files that DXO PL5 can read and use.
My File Folders are based on Dates, subject and Camera model–example 2022_03_27_Backyard Birds_D500. My image file for an image in that folder would be: 220327_BackyardBirds_01.NEF.
Downloader Pro allows me to structure just about anything I might want or need as they have numerous tokens to choose from and Job Codes for subjects that may vary. Go here for more info.
http://breezesys.com/Downloader/help/index.html
For Nikon Transfer:
I do not see a need for DXO to develop any of these functions as third party programs already exist to perform them.
2 Likes
My organisation isn’t limited to having to specify a place. I also have top level folders like Still Life, Macro or Scanned - the last of which isn’t date based at all.
It’s just that most of the time, my work is either place or project based and, if a place or project is likely to be visited or take place over multiple dates, then that is the structure I use.
Possibly this is one of the reasons I wouldn’t use an automated tool - because it would impose unnecessary rules.
So, you have a mixture of places, dates, themes and projects. And that all in an inflexible, made-of-concrete folder structure. I hope it’s comprehensible for you, but I’m put of with all these hand knitted, woven, sewed exceptions of exceptions folder “structure”. You had to write a tool to remain sort of in charge in this maze, I’m sorry @Joanna, it’s beyond my horizon of understanding. You call it organisation and for me it’s a bunch of question marks to which I desire not to find answers. To each his/her own way. Each workshop also has it’s own structures and there’s no “best way” for all of us.
I’m also dividing my structures in year/month but within the month I simply see no reason to create more folders because in PL, these reduce a possible overview and I’m not willing to run a secondary tool just for organisation reasons. Sorry, after I revisited Aperture’s way of dealing with a lot of images in an easy, flexible and safe way. I miss that app even more than before. There’s no successor worth talking about.
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.
1 Like