injest default folder name

[ron_hiner]

Every single time I ingest a new batch of images, I create a new folder named  "{todayyear4}-{todaymonth0}-{todayday0}-ToEdit"

Well, not really, I have to figure out the variables myself and create a new folder and type it out manually.

It would be great to have a way to automate (via defaults) the creation of a new folder name.

[Hayo Baan]

Do I understand you correctly that you (just) want to ingest into a folder of that name?
This is actually easily done 

On the Ingest screen, under "Copy Photos" (halfway on the left side of the ingest screen), simply specify "Into folder with name".  The in the the "Folder name" box that pops-up, type in "{todayyear4}-{todaymonth0}-{todayday0}-ToEdit" (without the quotes)

That should do the trick!

Hope this helps.

[ron_hiner]

Schweet!  That is exactly what I wanted!

Thank you!

[MikeA]

On the Ingest screen, under "Copy Photos" (halfway on the left side of the ingest screen), simply specify "Into folder with name".  The in the the "Folder name" box that pops-up, type in "{todayyear4}-{todaymonth0}-{todayday0}-ToEdit" (without the quotes)

That should do the trick!

Hope this helps.

Wow, does it ever! Thanks a million! After reading your message I realized that I can use a variation on the theme to get exactly the subdirectories I'm after:

{iptcyear4}-{iptcmonth0}-{iptcday0}

... which creates (during ingest) ISO-date-named subdirectories consistent with the creation dates and times of the source files -- no matter what their dates and times are.

This is great! Up to now I've been using a Perl script of my own devising to handle this kind of subdirectory creation based on dates. It worked, but of course it didn't provide a PM contact sheet along the way. (Interesting: though PM has to create thumbnails as it ingests the files, I didn't find using PM much slower than using the Perl script. Not sure why; I will hazard a guess that its file I/O is a bit more efficient than File::Copy.)

Presumably the PM developers are reading this thread and will at least hear this heartfelt plea:

When the above kind of solution is not used -- if all files are copied during "ingest" into a flat folder structure using a named folder rather than folders created dynamically by using the variables -- I find that PM "touches" the files' modification dates and times with the current date/time, not the capture date/time.

I sorely wish it would not do this. I had to write Yet Another Perl Script to run Exiftool, extract the capture dates/times from all files copied that way, and then run a "touch" program to re-write the date/time data on disk. If you have hundreds of images to deal with and for whatever reason you had to copy them into a "flat" folder structure, this kind of post-processing takes rather a long time.

So to the developers: please in the future add a user option to retain the original capture date/time for the image files on disk, no matter how they are ingested and even if IPTC data is being applied to them during ingest.

Obviously this would not work for everyone as a default setting! But please oh please, provide it some day as an option...

[MikeA]

It just now occurred to me: when I used variables to create subdirectory names dynamically during ingest, I used variables with "iptc" in their names. In the pop-up list of variables, I couldn't find anything that looks like capture date/time data in the "Camera" section. The likely-looking variables all appeared in the "IPTC fields" section.

But I had told PM not to apply IPTC data to these particular files during ingest ... so where did the IPTC date information come from, such that PM could read it into a variable?

Is it actually EXIF data, but just referred to in the list of variables as, say, "iptcyear" (and so forth)?

[Kirk Baker]

It just now occurred to me: when I used variables to create subdirectory names dynamically during ingest, I used variables with "iptc" in their names. In the pop-up list of variables, I couldn't find anything that looks like capture date/time data in the "Camera" section. The likely-looking variables all appeared in the "IPTC fields" section.

But I had told PM not to apply IPTC data to these particular files during ingest ... so where did the IPTC date information come from, such that PM could read it into a variable?

Is it actually EXIF data, but just referred to in the list of variables as, say, "iptcyear" (and so forth)?

The IPTC date if it exists is used, otherwise the capture date is used.

-Kirk

[MikeA]

Is it actually EXIF data, but just referred to in the list of variables as, say, "iptcyear" (and so forth)?

The IPTC date if it exists is used, otherwise the capture date is used.

Thanks, Kirk.

One thing I was wrong about in a previous message in the thread: the modification date/time of the files on disk, "post-ingest," are the current date/time whether or not the directory-creation-via-variable approach is used. For some reason I had thought that using the variables during ingest prevented the files from being "touched" to the current date.

This provided an incentive to improve performance of the script that "touches" the files with their original (capture) dates+times, resulting in a ~10X speedier script. A much happier, albeit not yet ecstatic, camper resulted from this change. :-)

The change in date/time from the original values would not normally happen in a copy operation via the o.s. without some change being made to the files along the way (that I know of). Even if by user choice IPTC data aren't being written initially, is there some change being made to the files during the ingest operation?

Thanks.

[Kirk Baker]

Is it actually EXIF data, but just referred to in the list of variables as, say, "iptcyear" (and so forth)?

The IPTC date if it exists is used, otherwise the capture date is used.

The change in date/time from the original values would not normally happen in a copy operation via the o.s. without some change being made to the files along the way (that I know of). Even if by user choice IPTC data aren't being written initially, is there some change being made to the files during the ingest operation?

Yes.  Our image preferences are appended to the end of the file during Ingest.

-Kirk

[MikeA]

Yes.  Our image preferences are appended to the end of the file during Ingest.

Aha. Makes perfect sense now. Thanks again.

[jarrowwx]

Kirk,

I would suggest that the OS date/time should still be set to the capture date/time on ingest.    At least, have the option to keep the file date/time the same. 

-- John

[MikeA]

I would suggest that the OS date/time should still be set to the capture date/time on ingest.    At least, have the option to keep the file date/time the same. 
-- John

That would certainly suit me. Pending the feature becoming available as an option, I finally rolled my own Perl script that launches Exiftool, snags the "-CreateDate" information, splits it out into date- and time-stamps, and passes that information to a "touch" program. It's a bit clumsy, but it works. Of course, the moment I find I've made a mistake in entering, say, IPTC data and must correct it, I've "touched" the files and have to do the deed all over again. :-)

Is anyone reading this message a user of ActivePerl 5.6 or 5.8? If so: are there any native Win32 routines that can "touch" files? Maybe I'm missing something obvious, but I have yet to find this in the included Win32 extensions...