.... The only problem (bug? don't know....) I see now is that it insists on assigning a master category to one specific image that has no version. This image is one of a series of shots where I had my 20D firing at the maximum rate (5 frames per second) at a running stag. The 'adjacent' image from that series has a version. So we have the following situation:
image1 (having a master and a version) date_time_original 2006:02:03 13:34:51 image2 (having no version) date_time_original 2006:02:03 13:34:51
image2 nevertheless shows up in the master category when I run the script in the "fully automatic master / version check" or "all versions vs all mains" modes.
When I manually remove it from the master category and run the script in the "all versions vs all masters" mode this image gets not assigned to the master category.
Just hoping I am not goofing up this time
Herman, I don't think what you are seeing is a bug, and it is a problem I could foresee having in my own database, which is why I am starting to modify the script a bit for my own liking. When I version and set up my database, I have made it a point to utilize a naming scheme for versions. My plan is to utilize that naming scheme to identify version files rather than the date and time only or perhaps combine the visually similar search with the date and time search. I am in the "infant" stage of learning how to use the scripting language, but this would probably help my situation as I have a tendance to use the rapid fire features of my camera during action shots.
The only problem I foresee is that I often crop photos, which I consider a version that may not necessarily work with the visually similar image search.
I think some of these complications are good argument for why some type of version / stacking routine should be built into IMatch. It would give people a jumping off point to create more scripts to meet their needs. Of course, that might be easier said than done, but I will continue to wish.
Previous Topic
Index
