Return to Digital Photography Articles

IMatch (Photools)

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.


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.


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.


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
Rating3+ = "Tags.Ratings.Rating3-Good" OR
           "Tags.Ratings.Rating2-Great" OR
Rating4+ = "Tags.Ratings.Rating4-OK" OR
           "Tags.Ratings.Rating3-Good" OR 
           "Tags.Ratings.Rating2-Great" OR 
Rating5+ = "Tags.Ratings.Rating5-Bad" OR 
           "Tags.Ratings.Rating4-OK" OR 
           "Tags.Ratings.Rating3-Good" OR 
           "Tags.Ratings.Rating2-Great" OR 
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

  • New User Interface
    The next version has a modern, "sexy" user interface. Think about a mixture of Windows XP and Mac
    The user interface has flexible "panels" which contain information or "views"
    on the database. These panels can be arranged in many ways, and even on multiple monitors.
    Toolbars and other UI elements have also been revamped. Look at the icons used here on the forum to get an impression on how to toolbars look in the next release.
    There are also extended customization options, like assigning keyboard shortcuts to functions or category assignments.
  • New Database Technology
    The next major version uses a more versatile standard database technology, combined with my own database technology to get the performance required.
  • UNICODE(TM) support
    The next major version is fully UNICODE(TM) aware and supports all UNICODE-language elements on Windows 2000, Windows 2003 and Windows XP. No more problems with Chinese or Japanese file names or other special characters.
  • Calendar View
    Yes, the next major version of IMatch has a calendar view. But with some extra features and the "integration" of the category concept in IMatch. Pretty cool.
  • Better Categories and Splashers
    The categories in the next version of IMatch have learned some new tricks and are even more flexible. Yet easier to use. And yes, you can now select more than one category in the category tree. And I have also found a comfortable solution for the AND/OR/NOT thing when selecting more than one category.
    Splashers are still there but are easier to create and maintain.
  • Easier handling of media in the database view
    IMatch will change the display in the database tree so managing a large number of media will be easier. Each drive will be present as a root node. If the drive supports removable media (like CD or DVD), a second level with "media nodes" will be shown below the drive node. Below that, the folders will be shown. For hard disks, you will only see the drive node with the folders below, like in the current version.
  • International versions
    The next major version of IMatch is based on my localization framework. This allows me (and others) to localize IMatch to other languages by editing a single (!) XML file (even with Notepad). From what I can tell now, the next major release will be released in English and German at the same time.
    Some users have volunteered to help to translate IMatch into other languages. We'll see what can be done in this area.
  • Versioning and Derivative Images
    It seems to me that every user has different views on the topic of version management and derivate images .
    For me, a version of a file is an updated version of the file, e.g. when you load, edit and save a file, you get a new version.
    A derivative image is an image that is created from an original image. For example, when you open a RAW file in your imaging application and then save this file as a TIFF file on your disk.
    Some vendors include a versioning or "stacking" concept in their software, but only on the basis that they take full control over your images by moving all your images into a dedicated place on your hard disk. Such a schema may work when you have < 10,000 images, but it will fail if you have the average image volume an IMatch user has. Or when you store your files on removable media like CD-ROM or DVD. IMatch will implement versioning and derivative files management in a way that it also works with files on removable media also.
  • Multi-Monitor Support
    Yes. The panels in the new user interface can be moved outside of the IMatch program window, and also on different monitors.
  • Multi-User Support
    There will be a special multi-user version of IMatch. This is an extra product. No central server is required. The multi-user version will be released after the initial release of the standard IMatch version.
  • Scripting
    A new, enhanced version of the proven Sax Basic Engine will be used in the new system. This new version uses "early binding" technology, which means much faster execution of scripts. The object model of IMatch will be enhanced to incorporate the new features and database changes.
    The next major version of IMatch treats metadata as part of the database (full cached approach). No need for explicit IPTC/EXIF imports anymore. More features in this area are on my design sheet.
  • Variables
    The variables concept in IMatch has been enhanced in many ways. Variables are used everywhere, from import and export to customizing the user interface.
  • Support for Video and Audio?
    Yes. Currently my working model supports all the video and audio formats you can play with Apple's QuickTime and Windows Media Player. I'm still thinking about RealPlayer support.
  • Support for other file types
    IMatch will allow you to manage all files. Support for image, text, video, audio, text and HTML files is built-in. Other file formats can be added via plug-ins. Depending on the file type and the availability of plug-ins there will be more or less options for certain file types. For example, IMatch will allow you to see "icons" for all files (like in Windows Explorer), but thumbnails for supported image file types. The preview window is also sensitive to the selected file type. If the file type is fully supported you will be able to see a preview of the image, video or text file.
  • Plug-Ins?
    The next generation of IMatch supports plug-ins to add new file formats, meta data and even functionality to IMatch. The file format support in IMatch is based on such plug-ins. This allows me to split the IMatch installer into several parts so users only need to download what's needed. Saves, for example, 10 MB if you don't use a Canon camera
  • ???
    I probably will add more bits and pieces here in the future...

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.

  • Day-time job
  • Working on the next release. Making it as good as possible. Release when finished and good, not when marketing dictates.
  • Supporting the current version. Answering emails and monitoring the user forum.
  • Adding changes, bug fixes, new RAW formats and other things to the current version. Ship an intermediate update about every 12 weeks.
  • Having a life...(well, after the new release has been finished)

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!
 Open database format. Is it possible to transfer the Categories tree from IMatch to another database? Let's say SQLite?

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?
 This is very easy to do! One thing that Mario (the author of IMatch) should be given credit for is the fact that he has always made it easy for users to export their data, should they ever find a need to do so. You can write a simple script to convert your database directly into a format appropriate for SQLite import if you like, or you can use the built-in export functions to create a text file output of your IMatch database.

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.
 Well, version 3.6 is now out, and the big surprise (said sarcastically) is NO Versioning and Derivative Images support!

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
 Yes, this has been quite frustrating.

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.
 > All editing programs honor the read-only flag

Actually BreezeBrowser does not. It will allow you rotate images even if they have been set as Read-Only from within Windows.
 Good point... One has to be careful with statements like that as obviously there are exceptions. I've changed it to read "most should" -- of course there are times when ignoring the read-only flag is probably acceptable (such as is the case with reversible operations such as rotation). Thanks.
2006-02-18Michael Friess
 Hello Calvin, excellent web site, valuable info. I am currently in the pursue to identify my photo cataloging software. Your info is incredible help. Before finding your comparision table, I had come up with the following list: Kalimages, CyPics, PhotoCollector and Corel Photo Album. I tried them all today and already wiped out the last three. After reading several of your articles I had closer look to IMatch, iView MediaPro and idImager.
I have a few discussion points wrt IMatch and this article:
  • IMatch 3.5
    I saw it is available since two days - unfortunately not yet as trial version. Have you already got some experiences in this short timeframe?
  • sync database and image metadata
    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.
  • metadata for raw files
    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?
  • keywords / categories
    I see two disadvantages of everybody defining their own categories:
    1. you can not search across these, eg. if you make available some under a creative commons license and share them ( or so)
    2. I consider it an incredible effort building a clean controlled vocabulary / thesaurus. I found one public available one: TCM I+II from the Library of Congress. I liked about Kalimages that it nicely supports TCM. Try it out on a few image files to get an idea what this means. It still allows own keyword handling in addition. To fold in keywords from several (controlled) vocabularies into the same IPTC Keywords field I would introduce some namespace concept - eg. all my personal keywords start with something like "prv:". Have you looked in TCM-I - maybe I missed it on the website.

Okay, enough writing. I appreciate your view on these topics.

Cheers, Michael
 Michael -- Thanks! I've been working with IMatch 3.5 for a while now and certainly see an improvement (it was worth the paid upgrade IMO). The boolean category selection was very nice and many other features have been added that I have yet to fully explore. Round-trip metadata support is extremely useful. I am currently trying to adopt this sort of workflow, thereby eliminating one more concern about reliance upon the software. XMP does look like the way to go as its clear that the proprietary formats (maker notes, especially) are not going to enable writeback in any other manner. Kudos to Adobe for developing this. IMatch seems to support this nicely now.

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!
 Thanks for your wonderfully written website. I read and liked a lot of articles, especially this review on IMatch. Having surpassed 4000 photos, I've been looking at image management software for a couple of years.

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.
 Thanks! Some of these catalog applications will do round-trip metadata maintenance for you (either native or by scripts). Basically, they will keep a mirror of your tags in the metadata of the files. So, you end up with the benefits of the catalog-based access to the parameters, but the longetivity and reliability of in-file tagging.
2005-11-28bill s
 very valuable and useful piece of work here- thanks.
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
 To my knowledge, IMatch doesn't directly support this functionality, although people have achieved it by running a separate script. You could synchronize your database categorization with your image metadata and then do the reverse later to effectively protect your categorization efforts. However, it certainly would be better to have this integrated into the catalog application, as it would only need to resynch when you made a change within the application or the file changed externally.

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).
2005-10-18Adobe Photoshop Elements 3.0 User

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!



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:

  • How to import these batch edited verisons back into IMatch
    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.
  • How to keep the tagging consistent between the originals and the batch edited versions
    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.


Leave a comment or suggestion for this page:

(Never Shown - Optional)