Post by BuckSkin on Nov 22, 2022 0:39:38 GMT
This situation is not specific to Elements, nor FastStone, nor any specific software, so I put it here.
A few years ago, I changed my file naming procedure from something like this, HP_08-Aug-2017_001_I, to something like this, 2022-10-07_101344_7DMkII_0084_DxO; these are just two random file names, not the same file.
Note that both name structures include the Date Taken, just in different forms.
Also, note that the second structure contains the Time Taken, right to the second.
The first example is much easier to see and read the Date Taken; however, it is not the best for aligning multiple files in order of capture; the 3rd of November will line up ahead of the fourteenth of February.
Also, the camera moniker being ahead of everything else prevents images taken with multiple cameras from mixing amongst each other and lining up according to Time Taken, regardless of camera used.
My second system eliminates all of these problems, so long as all camera clocks are synchronized.
I explained all that to get to this:
Last night, I found some photos someone had requested that were named in the first fashion.
Also, I decided I could improve on the editing/enhancing before I sent them along.
Then, in the wee lonely hours of the night, I got ambitious and decided to go ahead and implement the new naming system to that group of files, about 75 images times thirteen versions per file; if I renamed one, I would have to rename them all --- and did.
FastStone has an excellent file renamer that can accurately extract the Date/Time Taken and implement it within the file name; it does this better and more easily understandable than Advanced Renamer; but then, Advanced Renamer is capable of all sorts of tricks that FastStone cannot do; so, I use the strengths of both.
I ran each version of the files through both programs and thought all was well and finished.
Then, I loaded the files I wanted in Elements to see if I could improve on the enhancing, making certain to put the files that carried all my metadata on the bottom of each layer stack, so that any produce from that point on would also carry the entire load of metadata --- the bottom/background file governs what metadata the finished product will contain --- it matters not what files may be stacked above; their metadata will have no bearing whatsoever on the outcome.
When I got my images to the point that it was time to save them as PSD, I noticed with the very first one that it did not ask me if it was okay to overwrite the existing PSD ----- uh-oh.....
I investigated and discovered that the file names of my whole group of PSD were way off; some by several hours and some by several days.
A bit more investigating revealed that, instead of the original "Background" files Date/Time Taken, the PSD got named according to the date/time the PSD were created.
I found this curious, seeing as I can create a gazillion image files from a PSD and each and every file will have the Date Taken stamp of the original "Background" image, regardless of when the PSD may have been created.
So, I did a bit of experimenting, setting random groups of PSD files to display, when moused over, Date Taken instead of Date Modified and in every case, instead of Date Taken, they displayed Date Created when moused over.
So, obviously, automatically renaming PSD files to Date Taken is not going to fly.
I ended up having to put the Original jpeg files in the same folder as the PSD files and visually match them up, manually copying the jpeg name and pasting it as the PSD name; this was not nearly so straight forward as it would seem as the PSD file names were all over the place, making me have to hunt them out to match them up.
Of course, it is too late for my solution to help me with this batch; but, I have a solution that will make things much easier in the future.
Before changing any file names, I will put a three digit prefix and underscore to both the original jpegs and their matching PSD; I will rename the jpegs, leaving the three digit prefix intact; then, I can put the newly renamed jpegs in the same folder with the prefixed PSD files and they will line up side-by-side, making it a simple matter to copy/paste the new jpeg names onto the matching PSD --- manually.
Then, once all is said and done, I can use Advanced Renamer to remove the prefixes and mission accomplished.
FastStone's ability to Tag/Flag and Untag/unflag groups of files and then select the Tagged or the Untagged really helps in these situations where one must temporarily combine two separate groups of files; it makes separating them to be put back where they belong ever so much quicker/easier.
Now I am curious if these file renamers are going to be able to extract Date Taken from RAW files and TIFF files, or if they are going to behave like the PSD.
If I had not caught it when what I had done was fresh in my mind, this could have caused all manner of grief later on when I needed the PSD that was mate to another file; or worse, I had the wrongly named PSD and created something from it that would inherit the wrong name and throw both history and the future all out of whack for now and all time to come.
A few years ago, I changed my file naming procedure from something like this, HP_08-Aug-2017_001_I, to something like this, 2022-10-07_101344_7DMkII_0084_DxO; these are just two random file names, not the same file.
Note that both name structures include the Date Taken, just in different forms.
Also, note that the second structure contains the Time Taken, right to the second.
The first example is much easier to see and read the Date Taken; however, it is not the best for aligning multiple files in order of capture; the 3rd of November will line up ahead of the fourteenth of February.
Also, the camera moniker being ahead of everything else prevents images taken with multiple cameras from mixing amongst each other and lining up according to Time Taken, regardless of camera used.
My second system eliminates all of these problems, so long as all camera clocks are synchronized.
I explained all that to get to this:
Last night, I found some photos someone had requested that were named in the first fashion.
Also, I decided I could improve on the editing/enhancing before I sent them along.
Then, in the wee lonely hours of the night, I got ambitious and decided to go ahead and implement the new naming system to that group of files, about 75 images times thirteen versions per file; if I renamed one, I would have to rename them all --- and did.
FastStone has an excellent file renamer that can accurately extract the Date/Time Taken and implement it within the file name; it does this better and more easily understandable than Advanced Renamer; but then, Advanced Renamer is capable of all sorts of tricks that FastStone cannot do; so, I use the strengths of both.
I ran each version of the files through both programs and thought all was well and finished.
Then, I loaded the files I wanted in Elements to see if I could improve on the enhancing, making certain to put the files that carried all my metadata on the bottom of each layer stack, so that any produce from that point on would also carry the entire load of metadata --- the bottom/background file governs what metadata the finished product will contain --- it matters not what files may be stacked above; their metadata will have no bearing whatsoever on the outcome.
When I got my images to the point that it was time to save them as PSD, I noticed with the very first one that it did not ask me if it was okay to overwrite the existing PSD ----- uh-oh.....
I investigated and discovered that the file names of my whole group of PSD were way off; some by several hours and some by several days.
A bit more investigating revealed that, instead of the original "Background" files Date/Time Taken, the PSD got named according to the date/time the PSD were created.
I found this curious, seeing as I can create a gazillion image files from a PSD and each and every file will have the Date Taken stamp of the original "Background" image, regardless of when the PSD may have been created.
So, I did a bit of experimenting, setting random groups of PSD files to display, when moused over, Date Taken instead of Date Modified and in every case, instead of Date Taken, they displayed Date Created when moused over.
So, obviously, automatically renaming PSD files to Date Taken is not going to fly.
I ended up having to put the Original jpeg files in the same folder as the PSD files and visually match them up, manually copying the jpeg name and pasting it as the PSD name; this was not nearly so straight forward as it would seem as the PSD file names were all over the place, making me have to hunt them out to match them up.
Of course, it is too late for my solution to help me with this batch; but, I have a solution that will make things much easier in the future.
Before changing any file names, I will put a three digit prefix and underscore to both the original jpegs and their matching PSD; I will rename the jpegs, leaving the three digit prefix intact; then, I can put the newly renamed jpegs in the same folder with the prefixed PSD files and they will line up side-by-side, making it a simple matter to copy/paste the new jpeg names onto the matching PSD --- manually.
Then, once all is said and done, I can use Advanced Renamer to remove the prefixes and mission accomplished.
FastStone's ability to Tag/Flag and Untag/unflag groups of files and then select the Tagged or the Untagged really helps in these situations where one must temporarily combine two separate groups of files; it makes separating them to be put back where they belong ever so much quicker/easier.
Now I am curious if these file renamers are going to be able to extract Date Taken from RAW files and TIFF files, or if they are going to behave like the PSD.
If I had not caught it when what I had done was fresh in my mind, this could have caused all manner of grief later on when I needed the PSD that was mate to another file; or worse, I had the wrongly named PSD and created something from it that would inherit the wrong name and throw both history and the future all out of whack for now and all time to come.
