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.

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

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.

How to add Multi-Version support: Manage Versions Script

Other IMatch Scripts

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

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.

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.

EXIF, IPTC, XMP
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!

2007-06-08

Micheal

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.

2007-05-23

Arved

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.

2007-03-04

Peter

> 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-18

Michael 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:

you can not search across these, eg. if you make available some under a creative commons license and share them (flickr.com or so)

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!

2006-02-07

Don

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-28

bill 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-18

Adobe 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!

2005-06-25

Alex

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

2005-06-23

Alex

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!

2005-03-13

Pradeep

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.