ImageIngesterPro Beta 3 for Windows -- almost there!

[Marc Rochkind]

I've just uploaded Beta 3 for Windows (see link below), which now has metadata fully implemented. This means the Metadata and Database panels, along with Catalog Sets, Keywords, clients, projects, cards, and all IPTC tables. All the controls on the main window, except for some Tools-menu items, are now implemented.

The supplied metadata template, ImageIngester.xmp, is now fully functional.

As the Metadata and Database panels are new, I'd appreciate any feedback on any user-interface glitches you see.

Among the features that are left to do are including/excluding file types, muti-camera shoot, and worksheet.

Enjoy!

--Marc

[Vince Doss]

This is excellent work Marc!
Thank you for creating this tool. I will gather my thoughts after testing a bit.

Thank you very much indeed

Vince Doss

[danaltick]

Marc,

This is really good news.  I am out of town for the rest of the week, but will try to take a look at it when I get back.

Thanks a million!

Dan

[Dawnne Gee]

Marc:

I'm sorry I missed your post on this. I haven't checked back up here in a while, and have unfortunately ingested around 100Gb of data via 1.6.7 when I could have been testing for you. Very sorry about that.

That having been said, I will be testing this out today on downloading all our family holiday stuff from my P-5000, and from a large multi-camera shoot covering 14 hours yesterday. I'll be keeping notes on each ingestion (a dozen separate backup folders), and will have a report for you within the next day or so.

Thank you so much! I'm really looking forward to the improvements you've described.

{As a side-note: I've been using ImageIngester 1.6.7 to ingest old DVD/CD-ROM based archives onto our new server. My only complaint is that when placing files in subfolders as Year/Date, it derives the Date from each file's "Date Last Modified" instead of the EXIF "Date Picture Taken". Fixing that is relatively easy, but has required me to ingest to a staging folder to get sorted out before putting them in the buckets. Just FYI, and hopefully a moot point in the new Beta.}

[Dawnne Gee]

Marc: My initial testing walkthrough/report thingy is here.

I had failed to read your thread on reading the sqlite database, so please ignore those comments. I hope it's helpful.

~d~

[Marc Rochkind]

Dawnne--

Thanks for this terrific report... it will take me quite a while to go through it all, but I will certainly check out every item you've listed.

--Marc

[Marc Rochkind]

Dawnne--

Regarding the {@exif.datetime} macro, it erroneously uses the TIFF DateTime instead of the EXIF DateTimeOriginal or DateTimeDigitized. This matters only if the image was edited (e.g., in Photoshop). I plan a fix, of course.

--Marc

[Dawnne Gee]

Marc:

If I failed to make it clear, I am very impressed with Image Ingester Pro for Windows, and will be very pleased to add it to my workflow. Excepting the nit-noids I found yesterday, it does indeed work quite well already. My report thingy was looking for problems, and I don't think I did a very good job communicating that I'm very impressed with it.

Thank you also for posting the draft of the revised docs. I'm reading that now to see what I didn't understand before, as I imagine my misunderstanding your Ingestion Database versus true metadata templates is simply an error of operator headspace and timing.    I'm truly excited by your intended capabilities and of course by what's already there. Thank you especially for running two backup folders!

[Marc Rochkind]

Dawnne--

I've had a chance to read through your report... thanks again! I've extracted from it a list of things to work on. I have comments on a few of your items:

5.b. {workflow deficiency}: For those of us who don't ingest directly from storage cards, and/or who use backup devices such as the Epson P-series and prefer for ensuing download/backups to come from this device (because it's inherently faster), it would be nice if the main program interface held an editable reference instead of having to go through Tools/Preferences. We are always ingesting from a different directory, so the additional clicks to get to referencing the new "Card Folder" (especially since "Card Folder" always defaults to My Documents), is a bit slow. As well for us, this is a value that actually stands outside of the concept of a Preference Set.

Choosing Cancel from the Choose Card dialog will set the card folder to "[user choice]," and then you'll be prompted when you press Start to choose the "card." Does this do what you want?

5.e. {enhancement request}: Macro Lab reference for the currently-selected job identifier for use in filename prefix. I know some disagree with that approach, but it's an option i'd like to be able to exercise. I would actually like my multi-shooter events to have a prefix along the lines of shooter's initials plus the shoot ID -- especially when I and my assistant, for example, have multiple events on the same day.

Can you expand a bit on this? I'm not sure what the feature should be.

5.l. {expression of confusion}: I inferred from the provision of "Metadata" options within ImageIngester, that the selections I made for Metadata would be written out as XMP Metadata to accompany each file. However, this is obviously not the case, as none of the three folders contains any XMP files. Is the entire Ingestion Database and the related Metadata options only for in-program use? If so, this seems redundant, but I obviously must be missing something since you've spent so much time on it. Please inform me of what I'm missing!

If I understand this paragraph, you still need to choose a metadata template to get sidecars with metadata. A generic template packed with macros is supplied (it's called "ImageIngester"), and that should at least be a starting point.

Please let me know of any additional items you find once you've had a chance to read the draft manual and use the program some more. I expect to have a new Windows Beta early next week.

--Marc

[Dawnne Gee]

Yeah, now that I'm reading your draft manual, I'm hoping not too many people slap me upside the head....

RE: 5.b. First of all, yes, I didn't understand [user choice] when I wrote my report. However, it and any other browse-dialog IIP opens defaults to "My Documents", and that is the basis of my "gripe" (admittedly a relatively small one, but it does slow down workflow). Adobe does this to me all the time, too, and it has become a big pet peeve. One day, during the press beta for pShop CS2, I actually documented the amount of time I spent navigating to folders in browse dialogs -- folders that had valid references that could have been defaulted to those values when the browse dialogs were opened. In an eight-hour day, I spent nearly 30 minutes browsing up and down directory trees in those dialogs, quite often to get just one folder away from where I was to begin with. So pardon the soap-box, but I'm very aware how this slows down workflow! Starting these dialogs off at "My Documents" means: 1 click to open "My Computer", 1 click to open the drive, and however many clicks after that to get to where I want to be. If they started with their "default" values, getting to where I need can be as easy as 1 click (if where I'm wanting to be is the parent directory of where I was).

In the particular case of the "Card" browse dialog, I would want to set a default (which you basically allow on Tools/Preferences). But, as you note in the manual, the "card" directory is rarely the same, whether I'm in the Tools/Preferences panel or starting an ingestion with [user choice], so to get to the right place, I have to open the browse dialog, which you default to "My Documents" instead of the value for Card Folder -- hence the "gripe". In the cases of the other browse dialogs, again, if there is a valid folder already set for a particular field (Primary Root Folder, Destination, Pre-Conversion Backup, Post-Conversion Backup), it's a nonsequitor to have the resulting browse dialog open in "My Documents" instead of the folder already referenced. After all, I'm probably not going to change my backup drives, just a different folder on that drive. I hope that makes sense....

RE: 5.e. ignore. This is a combination of not having selected the "ImageIngester" metadata template, and not seeing {@qf.Job} in the Macro Lab. All I'm saying is that there are some instances, particularly works-for-hire, where it might be beneficial to add our internal Shoot ID to the naming scheme of a set of files, along with our initials as the file prefix. {@qf.Job} should do the trick.

RE: 5.l. (lol...."if I understand this paragraph"....dude, that is SO the story of my life, hah-hah....sorry about that!) Yeah, i didn't select the ImageIngester template. color me stupid, although perhaps my misunderstanding there is avoidable? just a thought: if dynamic metadata options are selected, but no metadata template is selected, could IIP prompt my stupid self before ingesting?

[Dawnne Gee]

just FYI: i dunno if this is a "bug" or not, but yesterday's test involved 532 images. i did not have sequential numbering applied, but when i opened IIPb3 today, i noted that the sequence number was at 533.

[Marc Rochkind]

Dawnne--

The sequence number gets incremented whether you actually use it or not. Since using it means using the {@sequence} macro, I didn't bother tracking whether that macro was actually being used, as it could appear in several possible places. And, if I did suppress incrementation when the macro wasn't used, I could imagine some people then wondering why the count of ingested images wasn't accurate. So, I would then need TWO numbers, sort of like the odometer in a car vs. the trip meter. I took the easy way out. Lots of other stuff to do, as you know! ;-)

(I need to process your earlier post before replying to that one.)

--Marc

--Marc

[Dawnne Gee]

Hey again, Marc.

Just ran another batch through, and here's what I found:

1. In the Metadata window, i could delete previous keyword entries, but i could not delete a catalog set. is that actually tied to iView in some way? because the "catalog set" i made in the Metadata window doesn't actually exist in iView.

2. I did this ingestion test with the same 532 photos as before. (for this run, I did not use a Post-Conversion Backup Root as I didn't run the DNG Converter). It was a good, quick download. The XMP files that were created from your dynamic data were not readable by Bridge CS2 or PhotoShop (that is, none of their values show in the Bridge previews or File Info). A sample is available for you here. On a cursory perusal I could not see the error. Your XMP files are fantastically clean and well laid-out. Thank you much for that!

Little things, I'm sure. I seriously like how IIP works, Marc. Great Job!

[Marc Rochkind]

Dawnne--

1. Not being able to delete a Catalog Set is a bug. I'll fix it.

2. The problem with the XMP file is the presence of a copyright symbol. We had a very similar problem on the Mac, but with XMPs coming out of RapidFixer, not ImageIngester. The actual problem (as explained to a few of us by no less than Thomas Knoll) is that the XMP has to be encoded in UTF-8, the lone copyright symbol isn't, and the Adobe apps reject the whole thing.

What I need to do is put some special coding into ImageIngester to handle the copyright symbol, and maybe various other Windows symbols. Meanwhile, try writing "Copyright" or "(c)" and see if it starts working for you. (I confirmed this on my end by copying your XMP to a folder with a NEF in it, renaming the NEF to match the XMP, opening the NEF in Photoshop and seeing no metadata, then deleting the copyright symbol and seeing the metadata then appear.)

--Marc

[danaltick]

Marc,

I just did some testing of my own and got the same two problems listed above.  I fixed problem 2 by using (c).

I created my own custom ImageIngester.xmp file called MyImageIngester.xmp.  I started with yours and did some tweaking.  It works fine; however, I'm trying to use the {@filename} macro in the IPTC Status:Title field, but instead of it putting a name like altick_YYMMDD_NNNN in the field for each file, it's putting ABCD0001 name for every file.  Am I trying to do something that's not allowed?  Thanks.

Other than that, I haven't come across any problems with what you've implemented so far.  The ACR settings are working fine.  I did notice that the backup across the network is still slow, but I think I'm just going to handle that manually anyway to keep my ingestions at top speed.

Great work and much appreciated!

Dan