Tryign to import and create subfolders (conditionally) using EXIF/IPTC dates?

[sanphotgn]

If it is only happening with a small portion of the files, you should review the files' metadata.

In regards to 1899 ... there are several posts here regarding 1899.

Here is one: http://forum.idimager.com/viewtopic.php?f=57&t=24255

If you used software that touched (or hardware that created) the metadata and didn't follow the standards, the metadata could be missing, garbled, ....

[gaikokujinkyofusho]

Thanks for the reply. I should perhaps have been more clear. the 1899 photos aren't really the problem in this case but in the second screenshot I posted you will notice that the 2001, 2004, and 2013 are not folders but files that PS created. So my question is more about why the script/rule I posted created some folders and subfolders correctly (I count the 1899 as more or less correct creating 1899/1899-12 subfolders, or it went by the EXIF metadata it saw) and why for some other images it turned them into these 2001, 2004, and 2013 files and not 2001, 2004, and 2013 folders and subfolders.

Thx!

[sanphotgn]

you will notice that the 2001, 2004, and 2013 are not folders but files that PS created. So my question is more about why the script/rule I posted created some folders and subfolders correctly ... why for some other images it turned them into these 2001, 2004, and 2013 files and not 2001, 2004, and 2013 folders and subfolders.

I don't know. This is where I would start reviewing the metadata of the "original" files and the resulting "2001", "2004", and "2013" files.

What I am trying now is a regular name but folder and sub folders based on either the EXIF/IPTC/GPS dates

Is "regular name" - the name of the original file that isn't based on a time stamp field? For example: _DSC9213.NEF. Did you clear out your EXIF/IPTC/GPS dates script for file name?

During your tests you were using this: -set date/time qual to the moment the picture was taken. Are you still using that? This might be causing "confusion" with your script because it may be processing its own if-then with date fields.

See this: http://forum.idimager.com/viewtopic.php?f=57&t=23654

You may have a number of files with corrupted metadata and the only way to fix them is to import them into PSU and work on them or try to correct the bad metadata outside of PSU before import.

[gaikokujinkyofusho]

I am pretty sure the either the EXIF or IPTC or GPS data of 800+ files is ok as when I use only the file rename rule it imports and properly renames over 800 of the 900 test files I have so for the majority I think the metadata is ok.

I actually tried both, importing using the renamed files with the previous file rename script that now works (thanks again for that!) and with the default origonal file name. I tried both with this renaming folder/subfolder script and while the file renaming worked when I used it, and stayed the same when I used the origonal file name the folder/subfolder creation did not work.

During my test I guess I was using the date/time equal to the time it was taken, the %exif:DateTimeDigitized is what I used

As for the folder/subfolder creation this is what I have been trying to use:
%EXIFExists%/EXIFExists%exif:DateTimeDigitized{dateformat=yyyy}\%NotEXIFExists%/NotEXIFExists
%IPTCExists%/IPTCExists%iptc:DateCreated{dateformat=yyyy}\%NotIPTCExists%/NotIPTCExists
%GPSExists%/GPSExists%gps:GPSDateStamp{dateformat=yyyy}\%/NotGPSExists
%EXIFExists%/EXIFExists%exif:DateTimeDigitized{dateformat=yyyy-mm}\%NotEXIFExists%/NotEXIFExists
%IPTCExists%/IPTCExists%iptc:DateCreated{dateformat=yyyy-mm}\%NotIPTCExists%/NotIPTCExists
%GPSExists%/GPSExists%gps:GPSDateStamp{dateformat=yyyy-mm}\%/NotGPSExists

I reviewed the link and wasn't quite able to follow the relevance (it may be, I just didn't see it), I am ok with the 1899 photos (2 out of 900) and the way I have the script I had hoped that if the image didn't have at least one of the 3 metadata dates that it would not import the file (which seems to work with the filerename script you helped on) but the folder creation/categorization script its turning images into non-descript files?

[Hert]

Have you tried it with the latest version? There were so many updates released since 2.2

http://whatsnew.idimager.com

[gaikokujinkyofusho]

I just installed the trial then tried the script and got the same result, the interface is indeed nicer in 3.x but the end result seems to be the same when trying to do the renaming I was hoping to do?

[sanphotgn]

I copied and pasted your folder building script into a brand new PSU database. It didn't work. Specifically, no folders were built and it created files without extensions. The files without extensions are actually the photo files I tried to import. Add ".jpg" or whatever extension they should be and they turn into photo files.

One thing I noticed after pasting the script: At the top of the subfolder flyout containing the script, you should see the results of the script for the photo highlighted. Here, it only shows the year (for one of my files, I see 2016\). It doesn't show the year-month after the year. Compare with the built-in Date folder structure for image script. When I enable that script, I see 2016\04\2016-04-13.

One guess why it isn't working building folder structures is the "\" and "/" throughout the script. Somewhere something needs to be added or escaped out.

[sanphotgn]

If you get a match for %exif:DateTimeDigitized why not build the yyyy-mm folder immediately?

This way the code is not heading into a separate "if-then" loop.

Code: Select all

%EXIFExists%/EXIFExists%exif:DateTimeDigitized{dateformat=yyyy}\%exif:DateTimeDigitized{dateformat=yyyy-mm}%NotEXIFExists%/NotEXIFExists%IPTCExists%/IPTCExists%iptc:DateCreated{dateformat=yyyy}\%iptc:DateCreated{dateformat=yyyy-mm}%NotIPTCExists%/NotIPTCExists%GPSExists%/GPSExists%gps:GPSDateStamp{dateformat=yyyy}\%gps:GPSDateStamp{dateformat=yyyy-mm}%/GPSExists

The result on the Sub folder fly out screen is correctly displayed: 2015\2015-05.

It worked for several .jpg files and I got an 1899. It didn't rename any files "yyyy" and leave them without an extension.

File name: Original Filename.

Set date/time equal was disabled.

I tried it on my production database with .jpg, NEF, CR2, TIF ... and it worked.

[gaikokujinkyofusho]

Thanks!!!!!!! That is working in so far as no images being turned into zombie files

I tried running it on a larger, different test batch, and there still seems to be a problem.

I know that some of my images don't have the %exif:DateTimeDigitized feild (some seem to have a DateTimeTaken feild?) and some don't have the %gps:GPSDateStamp feild and so on, this is why I was so hung up on the if no exif date then try iptc or gps dates. Well the script doesn't seem to be reading all the fields. The 1899-12-30 folder filled up with quite a few files that had valid IPTC and GPS dates (or looked to me like they did) yet they weren't sorted/filed away accordingly. I have linked to an example file (got an error when I tried to attach it) that doesn't have the correct exif field but I think does have the right iptcdate field (none of the incorrectly sorted files have GPS data so either those are being sorted when GPSdate needs to be used or all files that have GPSdate also have exifdatedigitized?)... perhaps there is something that I am missing?

EDIT: As I kept letting it run it did start spitting out some files that were renamed images, but it doesn't make sense, I renamed one of the files, and took a look at the metadata and it has what looks to be a normal exif:DateTimeDigitized feild, as do some of the others. They were put in folders with the correct year\year-month but then left there and renamed into things like 2015-01-25 and 2015-01-25(001) (I enabled the rename duplicates option).

[gaikokujinkyofusho]

EDIT: As I kept letting it run it did start spitting out some files that were renamed images, but it doesn't make sense, I renamed one of the files, and took a look at the metadata and it has what looks to be a normal exif:DateTimeDigitized feild, as do some of the others. Also I was thinking that they way the script was written that if it didn't find one of the three metadata fields that it would not copy the file? Anyway, they were put in folders with the correct year\year-month but then left there and renamed into things like 2015-01-25 and 2015-01-25(001) (I enabled the rename duplicates option). I have linked to one of these new seemingly ok but apparently not files?

[sanphotgn]

The 1899-12-30 folder filled up with quite a few files that had valid IPTC and GPS dates (or looked to me like they did) yet they weren't sorted/filed away accordingly.

The forum is filled with "I see the date with x-program, but PSU has created, sees, ... 1899".

The fix: Get the photos into PSU and then run Convert Metadata to XMP.

I downloaded your sample file. The subfolder script saw 1899. It made the correct folder structure and didn't mangle the file name. I ran Convert Metadata to XMP. I then deleted it from the database and re-imported it. PSU saw the correct date and created the folder structure based on the date.

If you think one of the other date fields will be better picked up by PSU, then rearrange the order of the date fields in the script. Maybe start with GPS?

The script is building subfolders. If it doesn't find a date field ... no subfolders to build. And in some cases that is occurring. The very odd thing: the subfolders script renames the file. I would expect the file to be named per the current File Name rule and imported into the root folder specified.

Something to think about: create an "other" folder as the last option in the subfolder script. PSU can import them into that. Thus, they won't get renamed by the subfolder script. Fix them. Then delete them. Then re-import them.

Or skip the scripts for now. Import them. Fix them. Then re-import them using the script.

[sanphotgn]

A few more thoughts ...

The Conditions (%EXIFExists) are not available in the fly-out menu in either the Sub folder or File naming windows. At least, I can't locate them. They are available in other areas of PSU. Since they are not available in the Sub folder or File naming windows, it is very possible they are not supported.

If they are supported, I am not convinced my latest attempt at the script is written correctly. Found an example in an IDI Manual.

The example:

Code: Select all

%EXIFExists
<u>This photo contains Exif information</u>: <br>
Short Exif info: %ImageEXIF<br>
F-Number: %exif:Fnumber<br>
Exposure Mode: %exif:ExposureMode<br>
%/EXIFExists
%NotEXIFExists
<i>no EXIF information available for this photo.</i>
%/NotEXIFExists