Beta 8 of ImageIngesterPro Preview - UI improvements, inclusion/exclusion, EXIF

[Marc Rochkind]

I've just uploaded Beta 8 (Mac only), with a bunch of new features:

• A new Partition feature on the Preferences Naming tab allows you to break up the images inserted into a number-range folder into partitions of any size you set, to prevent a single folder from getting too large.
  
• If Auto Eject is set, the card is ejected as soon as the images are copied to the backup folder, without waiting for the ingestion to finish. The card may be immediately replaced by a new card, ingestion of which will start as soon as the first ingestion is complete.
  
• There's now an option to skip creation of the backup, which is otherwise created prior to copying the images to the primary folder. That is, if the backup is skipped, images are copied directly from the card to the primary folder.
  
• A list of extensions to include or exclude can be entered on the Preferences Ingestion tab. By default, the option is set to exclude nothing.
  
• There's a new macro, {@exif.datetime}, which provides the datetime from EXIF data. (I said I wasn't going to do this, but I came across some code that made it easy.)
  
• There's a new option to skip verification of JPEGs.
  
• The user interface for file and folder naming has been improved, as I described in another post here yesterday.
  

It's now practical to reingest an entire tree of images: You skip the backup, set up file naming to use the new {@exif.datetime} macro, include image-file extensions only, and select the root of the tree as the "card" folder. I'm very interested in feedback from anyone who cares to try this on really large trees (10,000 - 100,000 images). Also, the code that reads the EXIF datetime is new to me, and I'm not sure how well it will work in practice, although it's performed flawlessly for me.

I've written a detailed guide to all the new (and old) features that you can read at http://basepath.com/ImageIngester/pro-preview.php. There's a link to download the beta there, too.

As always, please post feedback here or just email me directly.

--Marc

[David Anderson]

[/li][li]There's a new macro, {@exif.datetime}, which provides the datetime from EXIF data. (I said I wasn't going to do this, but I came across some code that made it easy.)

Marc,
Thanks for finding a way to include this feature, which I consider a vital requirement. I will have another look at ImageIngester after you get round to updating the Windows version.

David

[Mike Guilbault]

Marc... I'm just curious... but why do you have the images download to the backup folder first, and then copy to the destination folder?  To me, wouldn't it be the other way around?  I guess there's not really much difference since the action is performed right away, but as I said, I'm just curious.
I'll download the new Beta this morning to try on the wedding I shot yesterday.  Looks good!

[Marc Rochkind]

Mike--

The problem is that "backup" is a misnomer... it should have been called "pre-conversion." It's purposes are (1) provide a place from which DNG Converter can convert raws, and (2) provide a place in which to preserve original raws. I don't want to run DNG Converter directly from the card, since its error checking is not documented, and I know and trust the copy loop that I wrote myself.

Going back to my original design for ImageIngester, it's based on the observation that, since DNG Converter makes a copy, and since you want two copies before you erase the card, the backup is free.

I expected that the real backup of the primary folder and all other working files would be done outside of ImageIngester, according to the user's normal operating setup.

OK, so all that is by way of background. The reality is that I'm making changes so that the backup as I originally designed it will be optional, and I'm planning a 2nd, post-conversion backup of the primary folder, which is what most people think of as backup.

Then the process will be: pre-conversion copy --> primary --> primary backup, with the 1st and the 3rd being optional. I like the present scheme because it gives me a temporary backup, in case there's a disaster with the card; it preserves original raws; and it takes no extra processing time. However, as I said, it will be entirely under the user's control.

--Marc

[Mike Guilbault]

Thanks Marc - that makes sense.

I tried the Beta8 to download my wedding - worked great, except I got an error: Image Count Discrepency.  I couldn't find any discrepancies - the count on the CF card was the same downloaded and it doesn't appear that I'm missing anything.  Any ideas of what that might be?

I like the ability to choose a destination folder  in the Folder Arrangement section.  For weddings, I usually have all their folders pre-determined so this makes it easy to find.  The Prefix option (leave blank if you don't want it) works great too - thanks!

[Mike Guilbault]

Marc, when I got that error (above), I looked at the ingestion log and it was rather confusing.  For some of my downloads, I don't use the Client or Project names, but the last names I did use are showing up in the log even if it had nothing to do with those - like the wedding I just downloaded with the Image Count error.   Is there a way that if Client/Project isn't used, that it could display the folder path instead?

[Marc Rochkind]

Mike--

When you say "log," I take that to mean the ingestion database table?

I'll check out the client and project problem. What was showing in the Client and Project menus on the main screen?

I've been doing some work on the image-count discrepency checking, so I'll look into that. Any way you could email me a copy of the main-window log?

Thanks!

--Marc

[ScottBuckel]

Marc - when do you think you will have time to work on a windows version?  Some of the new features look interesting.

Scott

[Photo_op]

OK, so all that is by way of background. The reality is that I'm making changes so that the backup as I originally designed it will be optional, and I'm planning a 2nd, post-conversion backup of the primary folder, which is what most people think of as backup.

Then the process will be: pre-conversion copy --> primary --> primary backup, with the 1st and the 3rd being optional. I like the present scheme because it gives me a temporary backup, in case there's a disaster with the card; it preserves original raws; and it takes no extra processing time. However, as I said, it will be entirely under the user's control.

Marc-

You beat me to the punch. This would be perfect for my work flow. Being a belt AND suspenders kind of guy, this was exactly what I was going to suggest as a feature. In my terminology (and file sub directory structure) it would be RAW-->Working (apply ACR, any additional metadata, keywords, etc.) --> Primary Backup (external hard drive original RAW files).

DaveB

[Marc Rochkind]

Scott--

The Mac version is nearly feature complete, the biggest feature not-yet-in being renaming/refoldering for multi-camera shoots. A few glitches to track down too, such as compatibility between Camera Raw settings and other apps, such as RapidFixer. Then I can start the Windows version.

The two apps have completely different user-interface code, but they share the ingestion code and a lot of supporting code. I think to get the Windows version into beta will take about a month of work. However... the question I think you're asking is, how long would it take me to have 25 or so days available for the Windows version? I think it would take about 3 - 4 months, given my present day job, so maybe I could have a Windows beta out at the end of this year or 1Q2007. If my day job disappears, it would be sooner, so I'm sure you'll be rooting for me to get canned. That's OK! ImageIngester is way more fun, although the pay is a little lower than I'm used to. ;-)

--Marc

[ScottBuckel]

Marc - If I wished for you to loose your day job, it may not help me out.  I would assume that you would put more energy in getting another day job than writing code.  Thanks for the information - I was kind of hoping it would not be that difficult and time consuming.  Anyway, I'll be waiting.

Thanks,

Scott

[Mike Guilbault]

Mike--

When you say "log," I take that to mean the ingestion database table?

I'll check out the client and project problem. What was showing in the Client and Project menus on the main screen?

I've been doing some work on the image-count discrepency checking, so I'll look into that. Any way you could email me a copy of the main-window log?

Thanks!

--Marc

The Client and Project names that were in the main window are the ones showing up in the database - even though this option wasn't used. 
I'm not sure what you mean when you say "main-window log"?  Do you want a screen shot of the main window?

[Mike Guilbault]

Marc... I also noticed with my last ingestion that most (only missed one or two) of my vertical images showed up in Bridge rotated to vertical.  This wasn't happening before.  Did you do something to make this happen? 

[Marc Rochkind]

Marc... I also noticed with my last ingestion that most (only missed one or two) of my vertical images showed up in Bridge rotated to vertical.  This wasn't happening before.  Did you do something to make this happen?

Maybe. Starting I think with Beta 7, I remove from the metadata template parts that shouldn't be in a template that were left over from processing an image. These were always present if the template was created in Bridge, as opposed to creating it from a fresh image in Photoshop. So, perhaps before I made this change Bridge was being prevented from rotating.

However, I don't think Beta 8 is doing anything different from Beta 7 as far as sidecars are concerned.

--Marc

[Mike Guilbault]

Well I'm not sure what it was.. but I like it!  As I said, out of about 350 images downloaded, only about half a dozen of the verticals weren't rotated.  It's great.