Versioning and JPEG files used as Masters question

[DavidOfMA]

I can't figure out how to have a Master in one folder and a version in another folder, and have the metadata from the Master be copied to the versions in other folders. For instance, say I have a file named filename.jpg, derived from filename.rw2, and I create a file called filename_web.jpg from filename.jpg. How do I let IMatch know to copy the metadata from filename.jpg to filename_web.jpg if filename_web.jpg, regardless of where in the database filename_web.jpg resides?

Sorry if this is a dumb question.

EDIT: It looks like I can specify a Versioning rule for JPEG files that says "Treat this file as the master, and then any file that has this filename root anywhere in the database will be a version." This string seems to work for the Link Expression: ^(_*{name})[+\-_]*[0-9|a-z]*\.(jpg|jpeg)$

Is that correct use of this feature? Or will this somehow confuse the Buddy File relations, where DNG, SRW, and RW2 files are master files for JPEG and TIFF?

David

[Ferdinand]

David, file relations are not that hard and it really is a good idea to read the very well-written help file.

There are a couple of points to watch out for.  (i) buddy files and versioning are quite separate and used for different things.  Files can be a buddy, or a version or both or neither.  When you rename/copy/move/delete a file you do the same to its buddy files.  (ii) Versioning is used to find other versions of a file, create version stacks, and propagate metadata.

You say that you have a version in "another folder".  Your versioning relation will need to specify how to find that other folder.  There are several options.  You will also need to specify how to locate the version given the master.  Using the file name and link expression is one way, but there are others.

Details in the help file.

[DavidOfMA]

Thanks for your answer. I have read the section on versioning in the Help file twice. I don't know why people responding to my requests are assuming I haven't read the help file. I come to the board AFTER I have read the relevant sections in the help file, struggled to do what I'm trying to do, and then still can't figure it out. What's easy for some is not easy for others. The IMatch 3.6 UI was easy for me. This one is not.

[Richard]

I don't know why people responding to my requests are assuming I haven't read the help file.

There are countless posts where the person has not read the help at all. So folks tend to encourage others to read rather than just ask.

What's easy for some is not easy for others.

That too is common and the folks here will do there best to help but it is always wise to state what you read and what you don't understand.

[Mario]

Please be careful when working with file relations when the master and the version use the same extension. You can shot yourself into your foot quickly.

The general idea is:

1. You tell IMatch how to identify (file mask) a master.
2. Then you tell it how to identify a version (file mask)
3. You tell IMatch where to look for versions (folder specification).
4- You tell IMatch what do copy/propagate from the master to versions

It's OK to use the file extensions for both version and master, but then your version expression must be real specific about in which folders to find the versions. Or your master file mask must be defined in a way that will never match a version. Otherwise IMatch may consider a version a master, depending on how you work, how you add folders and files to your database etc.

Do not use the option to search the entire database for versions. Not only will this very, very slow but also prone accidentally identify a version as a master or vice-versa.

Tip: While you try things out, propagate only a pin or dot. This allows you to re-run your relation rules quickly, to propagate to see if everything works etc. Make sure you use a file window layout which shows the version icons so you see if the correct versions were found. Also open the Version panel to see the effects of changes you do.

This should allow you to quickly setup your relation rule as needed.

[DavidOfMA]

Thanks for the warning. The versioning script I used with IMatch 3 allowed me to specify a source category, such that only files in that category would be regarded as Masters. Is there a way to do that in IMatch 5? I couldn't see one. The alternative is to keep adding to the folders to search for versions, which in my case could be stored in numerous locations.

[Ferdinand]

I don't know why people responding to my requests are assuming I haven't read the help file.

There are countless posts where the person has not read the help at all. So folks tend to encourage others to read rather than just ask.

Richard hit the nail on the head.  That is a frequently recurring issue that clogs up the forum.  My apologies for making the wrong assumption, it's just that normally when people have tried to read the help first they say so.  If there are still issues of understanding then we are more than happy to help.

The versioning script I used with IMatch 3 allowed me to specify a source category, such that only files in that category would be regarded as Masters. Is there a way to do that in IMatch 5? I couldn't see one.

My 3.6 image synchronisation script used categories as a way to identify masters just as a work-around, since I couldn't find a better alternative.  That isn't an option in IMatch 5, although you could always submit a feature request.  I think there are better (more automatic) alternatives.

I wonder if using the categories approach in 3.6 is making migrating to 5.2 harder in your case.  You will have read of the various ways that IMatch uses to see if a file has versions, and thus is a master.  You need a system to link masters and folders.  If you're telling IMatch to look in certain folders, is there a way that specify that folder name in a formula expression?  Give us a little information about your folder structure and your file naming strategy and we may be able to advise which of the available options best suit your workflow.

[Ferdinand]

I wonder if using the categories approach in 3.6 is making migrating to 5.2 harder in your case.

I thought I should clarify this statement.  What I meant was that in IMatch 3.6 you had the luxury of putting your master file anywhere compared to its versions, and so long as the master file was in the safety catch category then the image synchronisation script would work (although there was a performance hit from searching across the whole database).

You don't have quite the same luxury in IMatch 5 - you need to be a little more systematic in telling IMatch where to look. 

Well that's not quite true, you can tell it to search the entire DB, but we're told by Mario that this is not advisable.  I've not tried. 

Hopefully we can point you to a better way, using folder patterns in the list of folders dialog.

[DavidOfMA]

Given my folder structure, I need to use two main folders as masters and then all the other folders as versions, and to search down as many as 6 or 7 levels. That means two passes of several hours each, but it should work. I hope subsequent swatches for new files are quick, once I've gotten the basic relationships established. The category approach was easier, but I may be able to simplify my folder structure to work beter with the new system.