Ben,

True a script would be able to select the printable version of your photos. My goal was to create a dynamic Album view in addition to my normal catalog hierarchy. It was really more of an exercise at this point. I just finished looking at idImager and thought I could do most of things it can do using iMatch and maybe even better.

Anyway, you would need to use the interactive category builder to find only originals or a filter as you suggested (I have been using the filter most of the time). Plus I use a colored category to identity originals (that’s something I just added). I am planning to manually tag my originals with Versions.Original in the future instead of using the Manage Versions script and then use the Manage Versions script to add a tag Verions.HasDerived (with a color code) to the original so that I know when an original has been processed.

You may work differently than me, but most of the time, I don’t want to see my originals. They are RAW files and are not very useful beyond running them through a converter. That is why I made the argument to categorize the derived photos as well. Otherwise, all searches with categories will only return the dull and sometimes very poor looking original. I want most of my searches to return an album or printable version (they really are the same right now). Now idImager allows you to create a version stack that will act as a single entity when you conduct a search. But when you print, it will use the print version and when you publish it will select the web version. This is a nice concept IMHO, but creating the version sets is too laborious when compared to iMatch and running the Manage Versions script.

In closing, there are any number of whys to work with iMatch, as David suggested, and I am just sharing so of my thoughts, which seem to work best for me but are always subject to change. Ben, keep your dialogs going I enjoy reading through your process as well.

Dave