# Choosing a file-rename option when importing



## process (Jan 19, 2016)

I want to start renaming my files upon import based on the file creation date (there's a bug in the Mac version of LR which updates the "Creation date" of some files to the current date and time whenever keywords are added, removed or edited, so apart from the EXIF info I lose the ability to determine when the photo was taken outside of LR or other photo librarian type software). So far I've just left the filename as is.

I see there are several renaming methods to choose from when importing, so I'm wondering some options are more benefitial compared to others? I'd prefer not to change a method later on, but stick to one from the start. I believe I should at least use something like YEAR-MONTH-DAY -- HOUR-MINUTE-SECOND.CR2 but would it be useful to also include the original filename as part of it? I'm thinking it'll be a lot easier to remember a photo's number than the rather longish date/time sequence, instead having a name like:  20160119 -- 135432  0198.CR2


----------



## Johan Elzenga (Jan 19, 2016)

In Lightroom, you find photos by keywords, not by file name. The file name is irrelevant as far as finding particular photos is concerned (if you use Lightroom properly). That means you can use any name you think is useful for your purpose.


----------



## process (Jan 19, 2016)

Sorry, I failed to mention that the intended use for this is to have a secondary filing system. If I was to be without LR for some reason all won't be lost and I could even find photos using just the OSX Finder or Windows Explorer. 
I'd like to hear which naming conventions involving the Creation date would be best to go for.


----------



## Tony Jay (Jan 19, 2016)

Johan is correct; however, trying to decide exactly what is useful for a purpose is not necessarily that easy.

So, a bit more detail:

If, as Johan correctly suggests, that filenames are not the way to search for an image what is the point of renaming a file?
There are several fair reasons:

*Unique filenames* - although a filename is more than just MyDogSpot.JPG, it actually includes the entire root, like this C:\My Pictures/2015/Birthday/MyDogSpot.JPEG, so having another image file of the same name but in a different folder means that the operating system and other applications will realise the two files are different. However, what happens if that file accidentally ends up in the same folder as the first MyDogSpot.JPEG? Hopefully both the OS and whatever application realise that they are actually two unique files but they may not - in which case unless you happen to have your wits about you, you may, in fact, allow one file to be overwritten by the other. If you have a renaming strategy that guarantees that each filename is, in fact, unique, then the situation outlined above just cannot occur.

*Meaningful names*: A filename like 47qR45.JPEG may be unique, and prevent duplicates, but it is meaningless to a human being. If one is going to go to the trouble of renaming then at least make sure the result is meaningful to you. Some people get very excited about preserving the original, camera-generated filename, but unless there is some forensic auditing that is required then there really is not a good reason to preserve the camera-generated filename. In fact, a camera-generated filename is just a randomly-generated name consisting of digits and letters, and is neither meaningful, for a human, nor unique and so, duplication is possible.

*Suggestions for renaming files*: 
Start with the date in this format YYYYMMDD. Doing this will guarantee that that files will list chronologically. Almost all photographers do not need to include the time as well. Including the time I regard as a rare edge case.
End with a four-digit sequence number. Combined with the date information above this gives 10 000 images per day  (0001 to 9999). If you really shoot more than this on a daily basis then make it a five-digit sequence.
In the  middle put a custom text. What to enter is probably the biggest decision. I do a lot of outdoor photography so the custom text I enter happens to be the location of the shoot.
So a file renamed by myself looks something like this: 20160118-great_sandy_np-0001.CR2.
The date is the first eight characters, the sequence number the last four digits, and the location sits in the middle.
This system of file renaming is simple, repeatable, and scalable. It also guarantees every filename is unique but easily understood by a human.

Using location for the custom text may make no sense for your genre of photography. Whatever you decide to use make sure that is sensible and meaningful.

Rules for renaming include using only digits, letter, dashes, underscores, and fullstops. there is no place for any other special characters in filenames, since how different operating systems handle these characters in filenames is not uniform. There should never be any spaces in filenames either. Strange things can happen to filenames if there are spaces in the filename.
Try to keep the entire filename to 31 characters including the suffix (.JPEg or .CR2, or whatever). I still make this recommendation because, although neither OS X nor current Windows environments are limited in this way the situation is much more varied in the internet world where most of the servers are running Unix or variants thereof. Hopefully, over time, these servers will start running systems software that support less onerous file naming conventions.
Even if you do not currently anticipate sending images over the internet I would suggest you  strongly consider sticking to the conventions mentioned above.

File renaming is a small but important part of what is called digital asset management. A key, but often misunderstood, precept of digital asset management is redundancy. An obvious application of redundancy is to have several back-ups of ones images. In renaming one images it is very likely that all the information (if it is to useful of course) is probably duplicated elsewhere. The date is obviously part of the EXIF metadata of any digital image. In my renaming template the location will also be found in IPTC metadata fields and probably also reflected in keywords (keywords are also part of IPTC metadata). Many people scoff at this sort of duplication of information but it is a fundamental principle of digital asset management.

Other principles of digital asset management that pertain to file renaming are as follows:
Whatever scheme of renaming that one decides on it must be simple to do, easy to repeat, and scalable. Unless all the boxes are ticked then any possible advantages of file renaming will be lost. If it is complicated it is hard to do and not really repeatable. Unless the process is scalable then the system will fall apart with a large image collection (a lot of us will end up with image collections in the hundreds of thousands to millions in the next ten years).

The folder systems that contain these image files also need to be simple and repeatable, and scalable. My suggestion is to to with simple date-based folders 20160118. These folders can reside in another folder for that year 2016. Most of us do not shoot with enough frequency to make monthly folders worthwhile.
This folder system ticket all the boxes.
I make one small addition - I add the same location information that will be included in the file renames to the date-based folders.
So, if I shot in Great Sandy National Park today renamed images would look like this 20160119-great_sandy_np-0001.CR2, and the folder in which it resides looks like this: 20160119-great_sandy_np.
Doing things this way makes it very easy to see if an image file has been inadvertently misplaced because it will stick out like a sore thumb if it ends up in the wrong folder.
If I delete images from a shoot after the original rename then I will rename again to keep the sequence numbers contiguous. If there are gaps in the sequence it means that images are missing and that is a problem.

Although I use tools in Lightroom to achieve all the things I have mentioned, once these things are done (images renamed and correctly placed in a simple folder system), when I work with images in Lightroom as a routine I want to find these images using metadata and keywords not search through folders and try to locate images by filename. I put a lot of effort into metadata acquisition and keywording so that, hopefully I never have to go through the painful process of trying to find images by digging around in folders (who wants to do this with an image collection of 100 000 images - not I!).
However, when things go wrong (and they do) then having files and folders annotated as described greatly assists in reconstructing things when there are problems.

This is the point of digital asset management and the bigger topic deserves some thought and research since although file renaming is useful (as outlined above), in isolation, the benefits are limited unless incorporated into a larger co-ordinated digital asset management plan.

Tony Jay

EDIT: on posting I saw the OP second post. Whatever you end up doing do not have different collections of images that have different names. I trust that I have not misread your intent but I would strongly suggest making sure that any secondary file systems are exact duplicates of the working file system.


----------



## Hal P Anderson (Jan 19, 2016)

Being without LR would entail more problems than just being unable to find your images. All your edits are there, so you'd be forced to re-post-process in some other editor. The real solution is to take all the steps necessary to be able to keep running Lightroom. Backups. Backups. Backup your catalogue, your images, and if your livelihood depends on access, you need to have backup hardware.

I don't see how any file naming convention, other than ones that would be impossible to maintain, would help you find an image using the file system, anyway.

That said, there are published guidelines for best practices in file naming: 
http://www.dpbestflow.org/file-management/file-naming


----------



## DGStinner (Jan 19, 2016)

process said:


> I want to start renaming my files upon import based on the file creation date (there's a bug in the Mac version of LR which updates the "Creation date" of some files to the current date and time whenever keywords are added, removed or edited, so apart from the EXIF info I lose the ability to determine when the photo was taken outside of LR or other photo librarian type software).


I believe it only does this with JPGs since the safest way to write to the file is to make a copy of it, write the info to the copy, delete the original and then rename the copy to the filename of the original.  If it wrote to the original JPG and you had a power failure or drive hiccup, the file would become corrupt and then you'd lose the file entirely.  The EXIF, when viewed with Inspector inside Preview, still shows the original capture date.


----------



## Victoria Bampton (Jan 19, 2016)

Hal P Anderson said:


> Backups. Backups.



I have to emphasize this.

Recovery is a major factor to consider.  For example, I spoke to someone last week whose backups had all been destroyed and he had to use file recovery software to recover the files.  Of course they recovered with some goofy names (REC000000039485.cr2) which had nothing to do with the filenames in Lightroom.  If he'd used a fully metadata-based filename like YYYYMMDD-HHMMSS, he could have easily batch renamed the files back to the right names, making it much easier to relink them in Lightroom.  That theory doesn't work if you include original file numbers or text in the filename.  So if you decide to do that, make sure your backups are really really good.


----------



## rob211 (Jan 19, 2016)

process, I think I mentioned it in your other thread about dates, but Victoria's caution bears emphasis. Filenames are a filesystem thing; they aren't in the files per se. I think using metadata designed for storing such information is more permanent, safe and manageable than a kludge with filenames. So I'd back up whatever filenaming scheme with writing the same info into the image metadata.

I also say that because you have to consider searching. You mention losing files; both Windows and Mac's Spotlight index keywords and other exif and IPTC metadata. I could lose the filename, where it is in the filesystem, and Lightroom itself and still find all my images by keyword, caption, event, etc etc. Even if I had to move them from say a backup external to a Linux box.

And the context of your searching for the info matters. Most anything can search for filenames, but the "field" of filename expects text. So when you search on 20150101 as a date your search engine doesn't know that; it's just searching for a string of numbers, so it finds any numbers like that. And you have to use more sophisticated GREP searches to get at say all the images shot in say the year 2015, and searching for Feb 1 as "201" obviously gets problematic. But if you just use the scheme for sorting in the filesystem, it may not matter.

A caution about seconds though. I have seen posts by folks who ran into trouble when sequence of images mattered, since I guess software sometimes rounds seconds, so that the sequence might be different than as shot. So test to make sure it works, or preserve the image sequence via the original filenames. Using the date first makes it easy to sort by date-min-sec and then the number sequence could take over, like 2016011923093212345 (2016 01 19 23hr 09' 32" 12345).


And finally, make sure you distinguish which creation date you're memorializing: creation of the image (the original photo's capture time), creation of the digital image (say when it was scanned, or when digital photo taken), or creation of the file (since it could be a photo taken in 1912, scanned in 2008, but exported or edited as a separate file in 2015). Since you'll be saving panoramas, exported TIFFs from plugins, jpegs from RAWS, and so on, you need to know how you'll deal with those filenames too.


----------



## process (Jan 20, 2016)

Tony Jay said:


> Using location for the custom text may make no sense for your genre of photography. Whatever you decide to use make sure that is sensible and meaningful.
> 
> Rules for renaming include using only digits, letter, dashes, underscores, and fullstops. there is no place for any other special characters in filenames, since how different operating systems handle these characters in filenames is not uniform. There should never be any spaces in filenames either. Strange things can happen to filenames if there are spaces in the filename.



Thanks for your thorough explanation and suggestions, Tony Jay. You make some good and valid points.
I  don't see the need for location info in my case as my photos are all  organized within sub-folder named with a short description of the subject or event  (actually, since I already had lots of photos organized that way before  starting to use LR I used a script to simply copy the folder name to use  as LR keywords for photos within that folder). Photos are organized by  year-month-event folders. And since I also keep other (non-image) files  related to the event/subject in those folders for my "family" catalog,  such as scans, PDF files, audio files etc. which are not viewable in LR I  have sub folders named appropriately (e.g. "PDF", "Audio" etc.) which  (for the sake of finding them within LR) all contain a small image with  an icon/description showing what's inside. If I want to view what's  inside I simply do a "Show in Finder" within LR and view them outside of  LR.

Anyway, I think this filename format might work:   YYYYMMDD-HHMMSS original_filename.extension (e.g. "20160105-174532  IMG_2197.CR2"). I'm thinking that by keeping the original filename at  the end it'll be easier to remember and distinguish files when in the  Finder or even in LR. I didn't know spaces were a problem as I've always  been using that in OSX, but perhaps it could be if I transfer the  images over to another computer system -was that what you meant?
Besides  being able to see when a picture was taken regardless of the "Creation  date bug" in LR another side affect of this kind of renaming would be  that I'll only get a chance of a billion to find two files with a naming  conflict! I've seen for a fact the same filename (e.g. "IMG_2197.CR2")  on several images which have completely different content, but I'd be  lucky to experience that again with the shoot date/time preceeding it.


----------



## process (Jan 20, 2016)

Victoria Bampton said:


> I have to emphasize this.
> 
> Recovery is a major factor to consider.  For example, I spoke to someone last week whose backups had all been destroyed and he had to use file recovery software to recover the files.  Of course they recovered with some goofy names (REC000000039485.cr2) which had nothing to do with the filenames in Lightroom.  If he'd used a fully metadata-based filename like YYYYMMDD-HHMMSS, he could have easily batch renamed the files back to the right names, making it much easier to relink them in Lightroom.  That theory doesn't work if you include original file numbers or text in the filename.  So if you decide to do that, make sure your backups are really really good.



I'm not sure what you mean -are you thinking about situations where someone has a backup, but in the meantime the user has renamed all his/her files in LR, then a disaster occurs with some files and he/she has to locate and restore those same files from the backup drive only now it's near impossible to know which files to look for?
I still don't understand why including the original file numbers wouldn't help.

Yes, I do keep backups: Time Machine hourly backups on a separate drive for the past year's photos. Hourly backups using Chronosync on another hard drive for the same photos. External, removable hard drives for earlier years and they all have two different backup drives. I use Chronosync for this as well.
My problem now is ever after discovering that thousands of files have had their OSX Creation dates changed to something else than their original shot/scanned dates I've refrained from doing any more new backups on them, or else the old (correctly dated) files would be overwritten with the newer dated (incorrect dates) files and be lost forever. This is all due to that bug in LR which updates all JPG, PNG etc. files to the current date whenever keywords are added or updated (apparenly only on the Mac version of LR).
I believe I'm finally trying to understand when this is happening, how to fix my existing files and not least: how to restore all of them in some sort of automated way when they're spread across hundreds of different folders/subfolder, but until then I should probably get hold of yet another set of drives to back up my original drives before renaming them.


----------



## process (Jan 20, 2016)

DGStinner said:


> I believe it only does this with JPGs since the safest way to write to the file is to make a copy of it, write the info to the copy, delete the original and then rename the copy to the filename of the original.  If it wrote to the original JPG and you had a power failure or drive hiccup, the file would become corrupt and then you'd lose the file entirely.  The EXIF, when viewed with Inspector inside Preview, still shows the original capture date.



Yes, but with scanned images the date EXIF tag is apparently missing, so when LR does that you lose the date it was scanned forever!
I get what you're saying and agree that it's important to have a temporary file in case the computer crashes, a power outage or whatever, but Adobe could easily have instructed LR to write the original file's _Creation date_ back to the new file before deleting the temporary file. Updating the _Modification date_ should be the way to go (so as make backup software aware that this file has changed and needs to be backed up).


----------



## Victoria Bampton (Jan 20, 2016)

process said:


> I'm not sure what you mean -are you thinking about situations where someone has a backup, but in the meantime the user has renamed all his/her files in LR, then a disaster occurs with some files and he/she has to locate and restore those same files from the backup drive only now it's near impossible to know which files to look for?
> I still don't understand why including the original file numbers wouldn't help.



I was thinking more of a situation where the backup drives were connected and wiped at the same time as the working files, for example, a virus wiped all of the drives of the guy I spoke to last week. 

If he'd had a fully metadata-based filename, he could have imported the photos into an empty temporary catalog, renaming them from REC000000039485.cr2 back to 20160120-124800.cr2 very easily, and then easily linked them back to his main working catalog.  If he'd had a 20160105-174532 IMG_2197.CR2 filename, he couldn't have done that, because the original filename isn't stored in the file's metadata. 

It's rare - it's just one to consider.  (And I speak from experience, having accidentally wiped out my backups some years ago!)


----------



## process (Jan 20, 2016)

Ah, I understand. Yes, something to consider.
With burst mode shots however you could also end up with several files with the exact same date/time, or the renaming software I guess would add a suffix to each file in order to distinguish them. Still, I understand what you mean and most people don't have a majority of photos taken within the same second -and these could be manually relinked.

For backups I don't have them all connected to the computer at once. But with a virus you could be affected anyway, so that was a very unfortunate situation. Was that a Mac or Windows system? Us Mac users like to believe we're safe, but there are different views on that. Personally I've never been affected by any viri.


----------



## Victoria Bampton (Jan 21, 2016)

I think it was a Windows system, although my user-error wiping everything was when I'd just moved to Mac.


----------



## process (Jan 27, 2016)

About the renaming procedure: would you suggest I use LR's own renaming feature (select photos, then go to *Library-Rename Photos...*) or would renaming them externally (using tools such as A Better Finder Rename) outside of LR work just as well, then do a "synchronize folder" to have them included in the library again?

The date/time renaming in LR is based on the EXIF date/time, and not on the OSX Creation date, isn't it? If so, how would it handle adding the date/time to say a scanned image (which, as far as I know and in my own personal experience, usually doesn't contain any EXIF tags with the date/time)?


----------



## rob211 (Jan 27, 2016)

process said:


> About the renaming procedure: would you suggest I use LR's own renaming feature (select photos, then go to *Library-Rename Photos...*) or would renaming them externally (using tools such as A Better Finder Rename) outside of LR work just as well, then do a "synchronize folder" to have them included in the library again?
> 
> The date/time renaming in LR is based on the EXIF date/time, and not on the OSX Creation date, isn't it? If so, how would it handle adding the date/time to say a scanned image (which, as far as I know and in my own personal experience, usually doesn't contain any EXIF tags with the date/time)?


I'm not sure what you mean by "date/time renaming"; do you mean changing one or more of the different dates associated with an image, or the name of the file?

If you rename in the Finder, generally it doesn't change anything, but then Lr can't find the file. You can relocate it with a synchronization, and Lr will figure out it's the one you renamed. But things could go wrong; on occasion I've found Lr had difficulty with that process and thought was a completely new file. That was probably due to some other metadata changes that may have wiped out what Lr uses to match up the images, but why risk it? Use Lr to rename instead.

As we've noted before, Lr may on occasion change filesystem creation dates. I have had it do that recently on some old iPhone images; the file creation date changed when I added keywords. Probably due to rewriting the entire jpg to make space or a tag for that. In any case, in the jpg the image capture time in exif remained unchanged.

What metadata may exist in your scans, and how Lr will deal with that in terms of exif dates, IPTC dates, XMP dates and filesystem dates depends in part on what scanning software you used and what it wrote in the file, which can also depend on the file format I think. Experiment with one first. See what happens to whatever dates you are interested in pre and post Lr import, renaming, and metadata editing.

If by "date/time renaming" you're referring to the file renaming template in Lr, and the "date" listed under additional, here's what that is per Lr help:



> *Additional*
> Specifies a text string option using the creation (capture) date and time, or Exchangeable Image Format (EXIF) data. This element is available in the Filename Template Editor only when importing or auto-importing photos.



So yeah, that needs to exist. If not (my Vuescan scan's don't have it), use exiftool to write such an exif tag, or John Beardsworth's Capture Time to Exif plugin to do it. Super easy. http://www.beardsworth.co.uk/lightroom/capture-time-to-exif/ But I think you have to remember to READ metadata changes from the file since it uses exiftool externally; not sure if that's true if you just add the date in the sidepanel.


----------



## process (Jan 28, 2016)

rob211 said:


> I'm not sure what you mean by "date/time renaming"; do you mean changing one or more of the different dates associated with an image, or the name of the file?


Renaming the actual filename (i.e. changing _IMG_2412.CR2_ to _20151209-172937_IMG_2412.CR2_), basing the filename on the date it was shot.



> If you rename in the Finder, generally it doesn't change anything, but then Lr can't find the file. You can relocate it with a synchronization, and Lr will figure out it's the one you renamed. But things could go wrong; on occasion I've found Lr had difficulty with that process and thought was a completely new file. That was probably due to some other metadata changes that may have wiped out what Lr uses to match up the images, but why risk it? Use Lr to rename instead.



I understand. So in theory synchronizing externally renamed files _should_ do the same thing as renaming them internally in LR, but in practice it's not as reliable?





> As we've noted before, Lr may on occasion change filesystem creation dates. I have had it do that recently on some old iPhone images; the file creation date changed when I added keywords. Probably due to rewriting the entire jpg to make space or a tag for that. In any case, in the jpg the image capture time in exif remained unchanged.


Yes, fortunately that's true, and not just on occasion in my experience -but every time keywords are added/edited and the file is saved. 
But as long as the EXIF date tag is intact, software such as "A Better Finder Attributes" can copy the date information and write it back to the OSX file "Creation date", essentially salvaging it so the file will appear as before in the OSX Finder. It's worse with those images which don't already have any EXIF date tags and have been altered by LR. It seems their OSX Creation dates are lost forever if you don't have a backup of the file in question. I wish Adobe would fix this! 




> What metadata may exist in your scans, and how Lr will deal with that in terms of exif dates, IPTC dates, XMP dates and filesystem dates depends in part on what scanning software you used and what it wrote in the file, which can also depend on the file format I think. Experiment with one first. See what happens to whatever dates you are interested in pre and post Lr import, renaming, and metadata editing.



Yes, it appears my scanning software (a Brother multi-function printer) is pretty basic and doesn't add any EXIF tags. Perhaps there's some kind of universal scanning software out there more advanced which will work for many different printers... 




> So yeah, that needs to exist. If not (my Vuescan scan's don't have it), use exiftool to write such an exif tag, or John Beardsworth's Capture Time to Exif plugin to do it. Super easy. http://www.beardsworth.co.uk/lightroom/capture-time-to-exif/ But I think you have to remember to READ metadata changes from the file since it uses exiftool externally; not sure if that's true if you just add the date in the sidepanel.



I don't think it matters what Creation date the file has as LR appears to ignore it, as it looks in the EXIF tags instead based on my tests and experience. Except for those instances when there's no EXIF tag available it appears to look for the OSX Creation date in order to date the file. But of course, when a keyword is added all that will go to waste and the actual scanning date will be wrong!
I'm looking into Exiftool (can't get it to work at the moment though) as it appears to be a very powerful tool (but a bit complicated and "geeky" compared to most Mac apps). Still, I want to try to make some sort of drag & drop script out of it which can be placed in the OSX dock for fixing (creating an EXIF tag, then copying the Creation date over to the EXIF tag and finally renaming the filename with the scanning date) those scanned images before LR messes them up. It's important that I can do this outside of LR since I'm searching for them outside of LR and will do those file operations there. That'll probably mean I have to do a number of "synchronize folder" operations afterwards, but if I take one folder (i.e. a month worth of photos) at a time then at least it shouldn't affect all the photos in my collection should LR mess things up.


----------



## rob211 (Jan 28, 2016)

> So in theory synchronizing externally renamed files _should do the same thing as renaming them internally in LR, but in practice it's not as reliable?_



I've had issues. But it should work fine as long as the filename is the only thing changed. Remember, you are forcing Lr to match a "new" file to one it had in its database.



> Yes, it appears my scanning software (a Brother multi-function printer) is pretty basic and doesn't add any EXIF tags. Perhaps there's some kind of universal scanning software out there more advanced which will work for many different printers...



There is: Vuescan. It creates a JPG or TIFF with some exif info, like camera make and model (eg Canon 8800f), and exif "create date" for when you scanned it.



> I don't think it matters what Creation date the file has as LR appears to ignore it, as it looks in the EXIF tags instead based on my tests and experience. Except for those instances when there's no EXIF tag available it appears to look for the OSX Creation date in order to date the file. But of course, when a keyword is added all that will go to waste and the actual scanning date will be wrong!



Yes, Lr looks at the filesystem creation date if it has no exif dates to look at. There is no such thing as a "scanning date" per se. That's just the date you created a file; a filesystem date. Just like creating a Word file. Note that they are usually the same, but not always.

Since "actual scanning date" is just a bit of info, and not an exif, IPTC, or XMP thing, it can be stored anywhere. The filesystem "date created" may not be the date it was scanned. So it doesn't matter if Lr changes the filesystem date created, if the "actual scanning date" is stored somewhere more appropriate. Vuescan, for example, stores that in the exif tag "create date." I can add keywords over and over and over, and Lr changes the filesystem creation date over and over and over, but it doesn't matter, because the unchanging exif create date remains the same. And that what it shows in my grid view, metadata panel, sorts, etc.

Since Lr might change the filesystem creation date, obviously that's a poor place to store "actual scanning date." We've mentioned other strategies, but since I mentioned Vuescan, why not use that? Eventually your Brother won't get a new driver, and Vuescan is what everyone uses after that happens anyway. It names scans in a date format by default, adds the scanner as a "camera" in exif, adds the date of the scan to exif permanently, just as if it were a camera, and does tons of other cool stuff.

So without doing anything I can find all my scans by just searching in Lr in text for "vuescan" since it's in the exif tag for software, or find all my Canon 8800F scans by filtering on camera. And the date digitized stored in exif is always the date I digitized, but I can always add a date when the original image was taken by the film camera.

Sorta the right tool for the right job.


----------



## gpsmikey (Jan 29, 2016)

Another vote for Vuescan!  And, he updates it fairly regularly too.  In the windows world, that is typically the only 64 bit utility that can talk to most scanners as Nikon and the others quit updating drivers (or never created them) for the 64 bit version of windows (really appreciated after I paid good $$ for my Nikon Coolscan 5000).


----------



## process (Jan 30, 2016)

Yes, Vuescan is indeed nice (I just tried the demo and indeed it does create a "Date time digitized" EXIF tag which I can see in the "Metadata" section of LR). So that would solve the problem right away except my Brother multi-function printer has scan buttons on the scanner itself which I find very useful for scanning everyday things. I can't see anything like this in Vuescan, not surprisingly since my scanner software is made specifically for this printer.

Anyway, I have an idea which I'm hoping will work!
Despite the LR bug (overwriting OSX file "Creation date" with the current date), all files which already have the date/time in its EXIF header can be salvaged easily (using _A Better Finder Attributes_ as mentioned earlier), so the biggest problem is with files NOT already containing the date/time info in its EXIF header, which as far as I know applies only to scanned images or OSX PNG screenshots. So here's my (theoretical so far) suggestion which I hope can be turned into a script for an automated process:

1) create a specific folder (e.g. ~/Pictures/Scans/) and define this (in the scanner software) as where it will always put scanned images
2) make the Mac "watch" this folder meaning it'll look for any new files and run a script whenever new files are created. I believe this can be done using OSX's Automator though I'm still look into exactly how
3) write the script which will run whenever a new file is detected in the "Scans" folder. It should tell Exiftool to read the OSX file Creation date, then create the (so far missing in the file) "Date Time Digitized" EXIF tag into the file and write the Creation date time/date there. This should ensure that the correct date/time can be salvaged whenever LR messes up the date to "now" again
4) as an optional (IMHO essential) step we will want to rename the file with the correct time/date. My preference would be using the format YYYYMMDD-HHMMSS_existingfilename.extension though others might want it differently. I suppose this can be done with Exiftool as well, as the next step in the script

As far as I see, once created and running, this script should be a "set and forget" type of thing. To handle screenshots as well (are there other types of image files missing EXIF date/time tags which I've missed?), those could be defined to be saved inside the same "Scans" folder in order to be handled by the script as well (I know Onyx can be used to redefine the screenshot path)

To complete the LR bug-fixing (since Adobe won't be bothered) a separate script could be created to do the following:
1) look inside the image folder(s) belonging to LR
2) read the EXIF date/time tag of each filetype affected, and if it differs from the OSX file Creation date it should write that same date to the OSX file Creation date. As far as I understand, Exiftool doesn't write to the Creation date, but A Better Finder Attributes does (but isn't scriptable unfortunately). There's probably a solution to the problem though....


----------



## rob211 (Jan 30, 2016)

process said:


> Yes, Vuescan is indeed nice (I just tried the demo and indeed it does create a "Date time digitized" EXIF tag which I can see in the "Metadata" section of LR). So that would solve the problem right away except my Brother multi-function printer has scan buttons on the scanner itself which I find very useful for scanning everyday things. I can't see anything like this in Vuescan, not surprisingly since my scanner software is made specifically for this printer.
> 
> Anyway, I have an idea which I'm hoping will work!
> Despite the LR bug (overwriting OSX file "Creation date" with the current date), all files which already have the date/time in its EXIF header can be salvaged easily (using _A Better Finder Attributes_ as mentioned earlier), so the biggest problem is with files NOT already containing the date/time info in its EXIF header, which as far as I know applies only to scanned images or OSX PNG screenshots. So here's my (theoretical so far) suggestion which I hope can be turned into a script for an automated process:
> ...


That sounds a lot more complicated than Vuescan, but to each his own. I had a Brother multi function, and it scanned to designated folder, with a filename by default that included the scan date. Most scanners do this by default. I guess their software has gotten even worse in the interim.

If you just wanna rename, use Automator to create a folder action on that scanning destination folder. Add actions to get folder contents, and then rename Finder Items: add date and time.

Or do this. Create an auto import folder in Lr that you scan into. Then use Lr's settings in auto import to provide an appropriate name containing the current date (dunno if it does time, but it does sequence).

Note that if BEFORE you add any metadata (which would change the creation datestamp of the file itself) you use Lr's Metadata>Edit Capture time... and select "creation date" as the option, Lr will create that EXIF creation date. So then when you add keywords the file creation will change, but not the exif date or the date in the filename. Seems simpler than what you're suggesting. If that messes up, just read the file name date and use the plugin I mentioned above to change the date.


----------



## process (Jan 31, 2016)

rob211 said:


> That sounds a lot more complicated than Vuescan, but to each his own. I had a Brother multi function, and it scanned to designated folder, with a filename by default that included the scan date. Most scanners do this by default. I guess their software has gotten even worse in the interim.



Yes, it does have an option for dating the filename, but only in a specific format, not the one I've now started using with my LR imports (YYYYMMDD-HHMMSS_originalname.extension).

The LR auto import feature is cool -I just tried it and it even allows me to select the rename preset I made for my regular memory card imports with the above date format, but of course giving the filename the shot date is only half of what I want, so it won't do. Also the procedure has to be independant of LR as this is more an OSX file issue. 



> Note that if BEFORE you add any metadata (which would change the creation datestamp of the file itself) you use Lr's Metadata>Edit Capture time... and select "creation date" as the option, Lr will create that EXIF creation date. So then when you add keywords the file creation will change, but not the exif date or the date in the filename. Seems simpler than what you're suggesting. If that messes up, just read the file name date and use the plugin I mentioned above to change the date.



Yes, but again these are solutions within LR. 
I prefer solutions that when configured properly, means that I can forget all about the "remember to do this before that, and not this in that situation etc...." which I might remember now, but not a year or two from now. 
So what I want is the scanned images to be the way they should (contain EXIF date/time tags and have the date/time in the filename itself) ideally right from the scanning software (like with Vuescan), but next best to have it automated as I suggested, so that the files get fixed one by one as soon as they are created. I assume this will only take a second or less, so unless I'm super quick to move the files to somewhere else on my hard drive I should have "corrected" scanned files instead of what comes straight out of the scanner software.


----------



## rob211 (Feb 1, 2016)

process said:


> Yes, it does have an option for dating the filename, but only in a specific format, not the one I've now started using with my LR imports (YYYYMMDD-HHMMSS_originalname.extension).
> 
> The LR auto import feature is cool -I just tried it and it even allows me to select the rename preset I made for my regular memory card imports with the above date format, but of course giving the filename the shot date is only half of what I want, so it won't do. Also the procedure has to be independant of LR as this is more an OSX file issue.
> 
> ...


I gave you an Automator workflow; that's not an Lr thing.

And using Lr gets you to the same place as using any other software to name the file.

So use Vuescan. Using software that doesn't do what you want and then adding more and more software and contingent workarounds isn't going to work. And the only user intervention in the Lr auto import sequence I mentioned is to add the capture time. Two button clicks.


----------



## OogieM (Feb 21, 2016)

process said:


> My problem now is ever after discovering that thousands of files have had their OSX Creation dates changed to something else than their original shot/scanned dates I've refrained from doing any more new backups on them, or else the old (correctly dated) files would be overwritten with the newer dated (incorrect dates) files and be lost forever. This is all due to that bug in LR which updates all JPG, PNG etc. files to the current date whenever keywords are added or updated (apparenly only on the Mac version of LR).


Can you share what version of LR does this? I just did a quick test and I'm not seeing the bug on my machine btu I'm running LR 4. Just considering doing an upgrade and back looking at everything right now.


----------



## process (Feb 21, 2016)

I should have added that it happens when you actually _save_ those keywords.

If the _Catalog settings_ ("_Metadata_" section) has "*Automatically write changes into XMP*" _enabled_ then the changes are saved right away without any user-intervention, and you'll notice the files' creation date has changed to the current date/time.
If this feature is _disabled_ the file creation date stays untouched until you press CMD-S, which (as far as I remember) saves the keywords to the actual files where it otherwise keep that information in the LR catalog data.

My LR version is 5.7.2, but I'm told it even happens with the very latest upgrade.
Having discussed the subject many places I've learnt a lot and am currently working on a couple of easy to use workarounds regardless of Adobe's opinion on the subject.

*UPDATE*: I just experienced that having "Automatically write changes into XMP" turned OFF was a very good idea, because I imported ("File"-"Import photos and video") lots of images ("Add") and all of a sudden all those images had my own Metadata attached as I didn't pay attention to that import option! Fortunately I had the above XMP feature turn OFF (and I could just remove them all from the catalog and start importing again, now with Metadata selected to "None") or else those images' original Metadata would all have been permanently overwritten with my own.
So I'm going to stick with that and instead press CMD-S/CTRL-S on a PC I assume) whenever I need to save it to the actual file.


----------



## process (Jan 19, 2016)

I want to start renaming my files upon import based on the file creation date (there's a bug in the Mac version of LR which updates the "Creation date" of some files to the current date and time whenever keywords are added, removed or edited, so apart from the EXIF info I lose the ability to determine when the photo was taken outside of LR or other photo librarian type software). So far I've just left the filename as is.

I see there are several renaming methods to choose from when importing, so I'm wondering some options are more benefitial compared to others? I'd prefer not to change a method later on, but stick to one from the start. I believe I should at least use something like YEAR-MONTH-DAY -- HOUR-MINUTE-SECOND.CR2 but would it be useful to also include the original filename as part of it? I'm thinking it'll be a lot easier to remember a photo's number than the rather longish date/time sequence, instead having a name like:  20160119 -- 135432  0198.CR2


----------



## jonathan987 (Sep 25, 2017)

Best way to rename folders, files and other similary thing is using BatchRenameFiles Tool. You can found hier BanchRenameFiles.org.


----------



## Paul_DS256 (Sep 25, 2017)

I started using ExifTool a number of years ago when I was using Nikon's CX-2. While ExifTool is more for those comfortable with PC technology, it does 2 things for me that I really like independant of the workflow tool being used. 

Renames my files into my standard of YYYYMMDD-HHMMSS-x.* where -x is a occurence number if more than one picture in the same second.
Sets the metadata of the picture(s) with my information, where the picture was taken and a description.
Once this is done using a couple of Windows BAT files, I then load them into LR. If in the future, I move to a different tool other, I have the basic information about the picture in it's original raw format.


----------



## PhilBurton (Sep 26, 2017)

Sounds good.  Can you post these BAT files.


----------



## Paul_DS256 (Sep 26, 2017)

Phil, I will when I get home later this week.

One aspect I'm still sorting out is the multiple meta-data definitions schemes and what is shown by different utilities. The tagging I currently use shows differently in Windows Explorer, LR metadata and other tools.


----------



## PhilBurton (Sep 26, 2017)

DS256 said:


> Phil, I will when I get home later this week.
> 
> One aspect I'm still sorting out is the multiple meta-data definitions schemes and what is shown by different utilities. The tagging I currently use shows differently in Windows Explorer, LR metadata and other tools.


DS256.  No real hurry.  I know what you mean by, "When I get home..."  I'm about to travel from the western US to London, then NY, then Frankfurt, then home.  But as long as I can get a WiFi signal, I can connect with this forum.


----------



## Paul_DS256 (Sep 28, 2017)

Here you go. See the ExifTool page for more details. I had to rename the files from .BAT to .TXT in order to allow them to be uploaded.


----------



## PhilBurton (Sep 28, 2017)

DS256 said:


> Here you go. See the ExifTool page for more details. I had to rename the files from .BAT to .TXT in order to allow them to be uploaded.



Thanks for saving me some coding time.

Phil


----------



## Umberto Cocca (Oct 4, 2017)

process said:


> Personally I've never been affected by any viri.



<Pedantic mode = ON > "Viri" as a word does not exist. Latin plural of Virus is... Virus! Uncountable name, so does not change. "Viruses" would be the right use in current english language


----------

