Return to Digital Photography Articles
IMatch is a highly-featured photo catalog program popular amongst many serious photographers and hobbiests. It may be less popular with those new to cataloging and digital photography since the learning curve is reasonably steep, in part due to a user interface that is not as intuitive as other competing products. That said, it does offer a strong feature-set, particularly in the area of IPTC and scripting. The scripting interface (Visual Basic) enables more advanced users the ability to add additional features or workaround some limitations.
In a landscape of Digital Asset Management (DAM) products backed by large corporations, IMatch is developed solely by Mario Westphal. In that regard, it is admirable that the resulting product is still very competitive for a user demographic that has high demands on the feature set. He also provides considerable personal support in the forums. While some people may be concerned about investing their time in an organizer application written by a small developer, the open scripting model facilitates easy migration should that ever be necessary. The product release schedule is occasionally slower than some would like, but this is likely due to the developer's decision to favor stable robust releases over frequent updates.
Strengths of IMatch
Open database format
When IMatch was first released, one of the most significant features it had going for it was the open database model. This means that if, someday, one should ever decide to change over to another software package, you will have no problem transfering your hard work. Mario is very open and forthcoming in helping users transfer their metadata / tagging out of IMatch if they like -- and most users will be more apt to invest their time in a tool if they know that their efforts can be trasferred later. Over the past couple years, the notion of an open database is more common, with the archaic locked-in behavior no longer appealing to savvy consumers.
Powerful Scripting
IMatch has very extensive scripting support, based on the WinWrap Basic IDE (originally SAX Basic), resulting in a powerful Visual Basic environment complete with custom Dialog Box instantiations. The language has direct access to most of the IMatch database metadata and some image editing functions. This integration enables the development of a wide range of user-contributed scripts and features.
The active user support forums provide a wealth of scripts, so there is a good chance that you one is able to find a pre-existing script for most common needs.
With the help of the IMatch scripting environment, I have created a number of scripts that accomplish tasks such as version control, naming strategy verification and finding files that have not been tagged correctly. One feature that has been promised (for years) but not yet natively implemented is the the ability to manage multiple versions / derivations of the same file, without having to copy tags over manually. I have created a script that accomplishes this automatically, and have documented it below.
Rich feature set
Focusing primarily on cataloging features, the feature set is quite rich. There are very few things one can't do from within IMatch, and those that are missing can often be scripted easily. Some limited image editing has been provided, but this is clearly not the intended direction of the application (which many prefer to use a dedicated app for). It does mean, however, that the user interface can be overwhelming at first, along with the 300 page manual. With this feature set, the user is sometimes confronted with a range of menus and options that are not always intuitive. A freshened up user interface would especially help those who are new to the application.
Performance
With a unique database implementation, IMatch does in fact provide very fast performance with relatively large databases (in the 100s or thousands of photos). Some other competing products don't have a database backend that scales well to larger collections, and end up slowing down noticeably with 10,000 to 20,0000 photos. As databases only grow over time, this is a key issue.
Stability
Over several years of running IMatch on a large collection, I have rarely ever encountered any instability issues. A general feeling from the user forums seems to imply that bugs tend to be functional in nature and often minor. I have rarely ever experienced a crash. Similarly, I have never corrupted my working database. Furthermore, IMatch enforces regular backups of the database, which is clearly a well-considered feature.
Support
IMatch has surprisingly good support, in both the user community and from the developer himself. The user forums have enough critical mass that other contributors frequently post helpful workarounds or solutions in a relatively short period of time. Similarly, Mario himself answers emails regularly and has created a generous level of support.
Weaknesses of IMatch
User Interface complexity
With the broad feature-set, IMatch does have an interface that is less intuitive than other applications. If Adobe Photoshop Album were on one end of the intuitive scale, IMatch would be approaching the other. While this may be expected from an application geared more towards professionals, a rework would certainly be welcomed. A new user interface has been promised for a couple years but so far has not appeared. Some common operations (such as boolean category selections) are a little awkward.
Lack of Native Versioning
Versioning support (in particular, multi-file versions) has been promised by the developer for a few years, but unfortunately it has not been implemented. From a workflow point of view, the omission of this feature makes the maintenance of metadata and tagging between edited versions of ones photos cumbersome. For now, my ManageVersions script has proven useful for hundreds of IMatch users as a stop-gap measure.
Importing from Adobe Photoshop Album 1 / 2
Please see the article: Converting from Photoshop Album to IMatch
Missing THM Files
Have you ever tried opening up the IPTC Editor window in IMatch, only to be presented with an error message that reads:
The THM file for the selected image is missing! IMatch needs an THM file with the same name as the CRW to display or edit IPTC information
What this indicates is that you must have deleted the .THM file that was originally paired up (buddy) with the RAW image file. IMatch can't write metadata (such as IPTC) into the proprietary RAW image formats, so it uses a JPEG-like placeholder, called a THM file to accomplish this.
If you've accidentally deleted the THM files, please read my article on how you can regenerate the THM files.
How to add Multi-Version support: Manage Versions Script
Please see the IMatch Versioning page for the latest ManageVersions script!
Other IMatch Scripts
Mario's online forum has a number of scripts available for download at the IMatch Scripting Corner.
Selecting a thumbnail size in IMatch
When one first creates a database in IMatch, a dialog box will ask the user to select the thumbnail dimensions (between 40x40 and 300x300 pixels). Unfortunately, deciding on an appropriate thumbnail size, when you are first starting with a catalog program, can be difficult. The trade-off is between the ratio of database-size to image-size and the need for adequately large previews. I am currently using a thumbnail size of 160x160 pixels, and on my 19" monitor, this is just about right in terms of sizing.
Nowadays, drive space is relatively cheap, and so unless you have hundreds of thousands of photos, it probably makes more sense to go with larger (eg. 160 - 240 pixel) thumbnails. If I were to create my database again, I would have probably stuck with 200 pixel thumbnails or possible as large as 240 pixels. There is an option in the preview pane, "Thumb Lens Settings" that lets you pick the view percentage, so it is an easy matter to view at, say, 50% or 75% but still have a large thumbnail in the database. This has the added benefit of allowing you to view at 100% (larger thumbnails) if you need to differentiate images without opening each one up. You will need a lot of screen real-estate for the larger thumbnail sizes. To give you an idea, I have a 19" CRT monitor configured for 1600x1200 resolution. A comfortable window size for IMatch is around 1200 pixels wide (giving me some space for other windows and icons to the side). With such a window width, you can just barely squeeze four thumbnails across at 200x200 pixel thumbnails. I feel that this is not enough images for quick scrolling through your collection window. With 160x160 pixel thumbnails, I can comfortably fit around 5 thumbs wide by 3 high.
As of IMatch version 3.5, one can adjust the thumbnail size at a later stage, if desired.
Miscellaneous Workflow Details with IMatch
Imported Read-Only images and digital camears without orientation sensors
My default setting on import (with DownloaderPro) is to set all imported files to read-only. This has the advantage in that it is less likely that I will accidentally modify an original file. Most editing programs should honor the read-only flag and will warn you if you attempt to resave the original instead of saving a copy.
The only annoyance with using such a protection scheme is that images imported from an older / cheaper digital camera (without a built-in orientation sensor) will often need manual rotating. Real rotation (not virtual rotation) involves modifying the photo and so write-protection must be removed first.
In IMatch, this means that after importing the photos and discarding the obvious bad shots, I select all photos that are rotated clockwise (by CTRL-clicking) then right-click to select the option Read-Only Toggle, select to Make files writable, rotate counter-clockwise (by CTRL-LEFT ARROW) and then Read-Only Toggle back to Make files read-only. Then I repeat the process again with the photos that need to be rotated clockwise.
How to get multiple image ratings
As described in the page on keyword categories, I have five dynamic categories that allow me to view photos with various ratings levels. I rate many of my photos in the range of 1 to 5 (1 being excellent and 5 being bad). I assign tags using these rating levels. In IMatch, I then created five dynamic categories that use formulae to show a particular rating level or higher.
Doing this, I can simply click on Rating3+ to see all photos that have been classified as "Good" or better. All images that I haven't rated default to being assigned to ToRate category. Over time, I try to move most of my good images from ToRate into a particular rating category.
Rating1+ = "Tags.Ratings.Rating1-Excellent"
Rating2+ = "Tags.Ratings.Rating2-Great" OR
"Tags.Ratings.Rating1-Excellent"
Rating3+ = "Tags.Ratings.Rating3-Good" OR
"Tags.Ratings.Rating2-Great" OR
"Tags.Ratings.Rating1-Excellent"
Rating4+ = "Tags.Ratings.Rating4-OK" OR
"Tags.Ratings.Rating3-Good" OR
"Tags.Ratings.Rating2-Great" OR
"Tags.Ratings.Rating1-Excellent"
Rating5+ = "Tags.Ratings.Rating5-Bad" OR
"Tags.Ratings.Rating4-OK" OR
"Tags.Ratings.Rating3-Good" OR
"Tags.Ratings.Rating2-Great" OR
"Tags.Ratings.Rating1-Excellent"
|
| Formulae for Multiple Ratings |
How to recover your 1-Unassigned images category
If you've accidentally deleted one of the default categories, such as the 1-Unassigned Images category, you can recreate it by adding a category with the following formula: "@Unassigned".
IMatch 3.5 - The Next Generation - When?
One area that some users have griped about in the forums is the somewhat lengthy delay in the release of certain key features that were advertised several years ago. In particular, the user interface redesign and versioning functionality have been items of much discussion. The following was posted by Mario in February 2005. This text is also informative in giving an idea of other planned features on the table.
|
Which features will the new version have? I generally do not ( after learning my lesson the hard way ) comment on details of the next major version anymore. To many of my ideas have been "re-invented" in competing products, and I need to be the first to have a feature to claim my rights via prior art - just in case. But sometimes I comment here on the forum or in a support email on certain features, to prevent users from making wrong decisions based on features which will work differently in the next major release, or which will be replaced or removed. Here are most of these hints
And when will the new release be finished? I have no definite answer for this question. There are still some technological borders I need to cross. I have designed and invented some really cool new technologies in order to being able to implement all that what I have in mind. Since I still have my day-time job (which gives me financial security and allows me to make IMatch as good as possible even if I don't make money for a living from it) my current priority list looks as follows.
Progress on the next major release is good. Not as fast as I had hoped, but not as slow as I had feared. All I can say is that I too want to have and use the next major IMatch version. I do what I can, I promise! What we should not forget: We all have one of the most advanced image management systems installed on our computers. A working version, with a superior feature set, stability, performance. The name? IMatch
3.4 |
Reader's Comments:
Please leave your comments or suggestions below!Can you also transfer the relationship Photo, assigned Categories to SQLite from IMatch? Those are the things I put most of my time in so I would want to be able to make use of this information by exporting them to other databases. SQLite would be the handiest format.
Do you know what database format IMatch uses?. Is it MS Access or SQLite or paradox? How open the database is is determined by how easy it is to move any data you want to another database.
Could you move any information from IMatch Database to another database like for instance SQLite? How would you do it?
For example, you can select the menu option Database -> Import and Export... -> Export to Text Format. There, you can select what features of your database you'd like to export (such as the Categories, Full File Name, etc.). After creating this text file, it is a simple matter to import this into just about any other program.
This is something that has been promises for "the next version" for at least the past 6 years. Yes, I've been an IMatch user for that long, ever hopeful. "Hope springs eternal," but to say my patience hasn't been tested...
Boy, I'm bummed, but your script has saved my bacon and kept me using IMatch, rather than jumping ship to another DAM.
Thanks again!
- Arved
Developers need to take care in making public "promises". With features that may involve uncertain deployment timeframes / prioritization, it may be safer to avoid publicizing it altogether.
Thankfully, the scripting environment is excellent, so customers are usually able to implement some creative workarounds to keep the workflow going.
Actually BreezeBrowser does not. It will allow you rotate images even if they have been set as Read-Only from within Windows.
I have a few discussion points wrt IMatch and this article:
I saw it is available since two days - unfortunately not yet as trial version. Have you already got some experiences in this short timeframe?
I consider this definitely a valuable feature. So far I used PixVue to provide IPTC metadata to all my images - so image metadata only. Another advantage of this approach is that I can use other tools leveraging this info. eg. I use JAlbum with my own developed skin extracting IPTC metadata and adding it to the web album.
this is possible with the so-called XMP sidecars - files with the same name as the image and an .xmp extension. PixVue and Kalimages support it and seems that IMatch 3.5 does too?
I see two disadvantages of everybody defining their own categories:
Okay, enough writing. I appreciate your view on these topics.
Cheers, Michael
With regards to categorization and keywording, you have a great point. It is really difficult to come up with a globally-appropriate categorization scheme, but in publicly-shared environments, it becomes important. I suppose the other alternative would be to have an intelligent synonym system that tries to collect matches or else a centralized synonym database / thesaurus that people take the time to use. Your refernce to TCM sounds great -- I haven't seen it yet and will have a look. Thanks for your great input!
Rave reviews make IMatch seemed like the perfect choice, with its speed and flexibility. Then I noticed the popularity of IPTC, and I wanted to use those standards with an app that just indexed IPTC data. Then I read your thoughts that maintaining IPTC headers is much slower than maintaining a standard database. So just exporting to IPTC may be better.
Not being a professional, I only need a few pieces of metadata, like date/time, heading, caption, and keywords/categories.
A Portfolio vs. imatch question: I see portfolio describes ability for 'round trip' writing of metadata back to original photo file, so that photo can contain info independently of any database, so:
1. does imatch support something like this?
2. is this 'round trip' feature a really useful one to someone managing several thousand images?
Thanks- keep up great work- Bill
Speaking from a preservation of work point of view, I think this round-trip functionality sounds very useful in that it makes your cataloging efforts more portable and redundant. One thing to consider: how does it write your hierarchical tag assignments? A bigger issue: I don't see how it could work with undocumented file formats such as many of the RAW files in existence today. One can't write back into the metadata of these without potentially corrupting undocumented sections within (this is where the RAW sidecar functionality comes in handy).
I have never used IMatch, is it much beeter than Photoshop Elements 3.0? It seems too complicated. I have problems using Elements, but it does what I need it to. With RAW support, easy tagging, and I can use it for my video clips too.
In all honesty, if you are worried about IMatch being too complicated, it might be best to stick with PSE3 for now. The newer version of IMatch 3.5 might help improve the ease of use, but until then Photoshop Elements 3 has a lot of capability and a more intuitive interface. More importantly, PSE3 has integrated decent versioning support and tight integration with the editor.
That being said, I would much prefer IMatch. One of the main reasons being that I use some of the advanced features quite a bit -- especially the scripting, which allows me to have my photo collection automatically integrated with my website, for example. More importantly, IMatch is incredibly fast and doesn't seem to be bogged down with larger databases like some other catalog programs. There have been a number of reports of PSE3 getting pretty slow with bigger catalogs. Once you have more than 10 or 20 thousand photos online, the differences in the way that the programs are designed come to light. For those advantages, I have come to accept what I think is a difficult user interface. Good luck!
Hi Calvin, Wow, thanks for your extremelly quick answer! Yeah, I should have been more clear. My question was more along the lines of the "former". I am aware of your versioning script. In fact I have adopted your recommended naming scheme with view of eventually using the script. It looks excellent but I haven't used it yet though. (in fact, I have basically set up _everything_ according to your advice on this website and thus my question here!). Anyway, my question was more along the lines of how to maintain the hierarchy during the batch process itself. Although you are right that it may not matter that much, as the information has already been abstracted by IMatch, I feel a little unconfortable about breaking the hierarchy of physical locations - I have the feeling that I might eventually regret not keeping everything together. So, anyway, yeah a different script would accomplish that I guess. I just posted a specific question on the IMatch forum on the workflow that I am targetting and we'll see how it turns out. This might all turn out irrelevant in the end once Mario gets around to implementing versioning in IMatch, but who knows when that's going to be. Can't wait for him to get it done. Thanks again for your advice and enjoy your trip!
-Alex
I'll try to respond in the next day or two
Hey Calvin. I'm not sure if you've left for Africa yet, but I'll give it a shot anyway.
I've been setting up my workflow very much along your recommendations for naming of files, Imatch usage, etc... and it's been working pretty well. One thing that I wonder about regarding batch jobs - say that I select a set of pictures in Imatch and run a batch job to resize for printing purposes - the images tend to land in a single folder (i.e. "output folder"). I would like to keep the pictures together with the originals (i.e. in the original folder), except renamed (i.e. xxx-p.jpg). How do you (or would you) accomplish this?
Thanks. Enjoy your trip. Sounds very adventurous. -Alex
Hi Alex -- Still have a few hours left
...
What you have encountered is one of the more difficult workflow issues
when using IMatch. As the catalog software has already abstracted your view of
your folder hierarchy, it doesn't matter as much what directory your edited
images fall into. I'm not sure whether you're asking about how to change
the scripts to preserve the folder hierarchy, or whether you're asking about
how one can still use an IMatch workflow with batching that doesn't
preserve the original folder hierarchy.
Assuming you are asking the second question, there are two problems to solve:
If you are in the Database view, then a One-click Rescan will pick up the new files for you (assuming that your edited versions were kept in the same folder as the originals). You can also enable the Folder Watch just before you launch the batch application, so that IMatch can attempt to find the new files. I tend to use the former method. At this point, your files will appear together in Database view only. NOTE: I have configured IMatch to tag all new files _TO_SORT, so that I can quickly find these new files in Category view.
Once the files have been pulled into the catalog application, it is then important to have the tags match the originals so that the images are kept together in Category view. This is where the native IMatch support is missing a key feature: version management. I have worked around this problem by using my Manage Versions script. The key behind this is that all my batch edit processes must save the resulting files with the same base filename as the original, but then append a suffix starting with the hyphen character (eg. -e or -p). My script then copies most of the tags from the original files that were in the catalog database into the edited versions. From this point onward, both the originals and batch edited versions are kept together, even in Category view.
Of course, we are all hoping that IMatch 3.5 will add native support for the above workflow. Other catalog programs have already enabled this workflow in a seamless manner, so it is hoped that the next generation of IMatch will follow suit.
If you were asking about how one could preserve the hierarchy during the batch process itself, it really depends on what script or tool you are using to do the batch processing. If its an IMatch script, then it should be a very simple matter to modify it to read the original file's folder path and use this in the creation of the resulting file. If you're using an external application such as IrfanView, then it really depends on the extended option set offered by the tool.
Hope that helps!
Cal, your site is indeed terrific. I have learned so much!
I had originally bought IMatch about 3 years ago but never really used it for this very difficulty of managing versions. I shoot in RAW and so have at least two versions of an image at any time; the original and the converted to tiff or jpg. Then there are the edited or photoshopped versions, the websized, the prints, the emails - you know how it is. I realized there was no way I could use IMatch without creating different databases for each type (perhpas the only solution until your script!)
I name my files with the date format being yyyy-mm-dd (with the dashes) so it's easier to read quickly. I had a lot of truoble with your versions script until I figured that the prefix strict must be 'false' in order for this to work (increasing the len to 10 did not help). The script works great now, thank you. It still doesn't serve me needs though, unless I am missing something very basic.
The problem is, I have two versions of the same image now, one tagged 'edit' and both tagged 'mexico 2004'. So if I want to look at my pictures of 'mexico 2004' I get both sets popping up. I tried PixelSnaps' solution of the new template for selecting multiple categories, but that only gives me an 'and' & an 'or' option, but no 'not' option. I thought the purpose of version maintenace was to be able to get only ONE version of an image to show up. What am I missing here?
Thanks, Pradeep
There are three solutions I see to your "display" problem. The best method is of course to have native support in the application itself. As this will not be available until IMatch 3.5, we'll have to use a workaround. For the workaround solutions, you could either create a category formula or script it. With the category formula, one would unfortunately have to create the expression each time, which is certainly inconvenient. The best solution would be to write a quick script that creates a selection based on a user-selectable category with the "AND NOT edit". If I find some spare time, I might try to put something together.
In the meantime, I am living with the display of the derivative images mixed with the originals. I have made this less problematic by assigning a color code to any images that are edited. Doing the converse (ie. color-coding the originals) might also be worth considering. In my case I assign all derivative images to be red, so that I know that they have been edited / resized in some way.