How to keep a version link?

Mees Dekker · April 25, 2018, 07:34:04 PM

In my workflow I download RAW-files from my camera into a folder "new images" on my computer (C: fast SSD). They are all ingested into my IMatch database, works like a charm. After some culling, rating, assigning of categories etc., I edit these RAW images by using PS and store them as jpg's. IMatch automatically creates a version stack. Both master and versions are now in the same folder: i.e. "new images". I can propagate all desired metadata to the version. So far, so good.

However, when I then move the RAW images to a folder on my NAS and the created jpg's to another folder in this NAS, the version link is broken. Moves are done through IMatch.

Is there an easy way to keep these jpg's version linked to their original RAW-masters, even if they are in different folders?

Mario · April 25, 2018, 07:58:30 PM

Check how you have setup your versions (where the master looks for its version).
This sounds like the master no longer can find the versions after you have moved the master and the version around.

Carlo Didier · April 25, 2018, 08:02:39 PM

Check this

Mario · April 25, 2018, 08:16:07 PM

Quote from: Carlo Didier on April 25, 2018, 08:02:39 PM
Check this

This is the worst case, performance-wise. Making IMatch searching your entire database every time a master needs to update its version list can really bring down IMatch to a crawl.

sinus · April 26, 2018, 08:28:46 AM

I would think about a clever place (performance-wise) for my workflow.
I personally use the same folder.

Carlo Didier · April 26, 2018, 09:31:15 AM

Quote from: Mario on April 25, 2018, 08:16:07 PMThis is the worst case, performance-wise. Making IMatch searching your entire database every time a master needs to update its version list can really bring down IMatch to a crawl.

Well that may be, but I can have versions of images all over the place. I don't put versions for facebook in the same folder as the original. Other versions may exist in folders dedicated to a photobook or forum posts or whatever. For me, the whole versioning only makes sense if it works over the whole database. If all the masters and versions are together in the same folder, I don't need versioning ...

Mario · April 26, 2018, 09:46:00 AM

There are very rare circumstances where a user may need IMatch to search the entire database for versions.
But consider a database with 200,000 files...

It is usually much smarter to device a proper storage schema. If versions of a master can only be in one or more folders, specify that list. There are powerful options for that.
Everything is better than searching the whole database all the time.

Carlo Didier · April 26, 2018, 10:18:33 AM

I can personally live with the performance. Specifying which folders (or subtrees) should be considered would just be one more manual thing to maintain when I actually want to automate it. Kind of a conflict there

As it is, I don't have to think where my versions go. It just works. Convenience over performance is the key in this case.

Of course, everyone has different priorities and for professional use, performance may well be the highest priority.

sinus · April 26, 2018, 11:19:42 AM

Quote from: Carlo Didier on April 26, 2018, 09:31:15 AM
Quote from: Mario on April 25, 2018, 08:16:07 PMThis is the worst case, performance-wise. Making IMatch searching your entire database every time a master needs to update its version list can really bring down IMatch to a crawl.

Well that may be, but I can have versions of images all over the place. I don't put versions for facebook in the same folder as the original. Other versions may exist in folders dedicated to a photobook or forum posts or whatever. For me, the whole versioning only makes sense if it works over the whole database. If all the masters and versions are together in the same folder, I don't need versioning ...

I do it the other way around.
Masters and versions are in the same folder (which is also good for backups).

If I want to use images for projects, online locations, photo books or the like, then I use the IMatch categories to collect the different images that are in different folders into one category (for example "Photo Book").
Otherwise I would have to create one folder at a time and that is not practical for me.

It also allows me to better assign the same image into different categories for different projects.

But right: everyone has their own workflow.
For me, the longer I work with IMatch, the more important it is that the workflow, including folder structure and file names, is well thought out.

Translated with www.DeepL.com/Translator

Carlo Didier · April 26, 2018, 11:43:37 AM

Quote from: sinus on April 26, 2018, 11:19:42 AMI do it the other way around.
Masters and versions are in the same folder (which is also good for backups).

If I want to use images for projects, online locations, photo books or the like, then I use the IMatch categories to collect the different images that are in different folders into one category (for example "Photo Book").
Otherwise I would have to create one folder at a time and that is not practical for me.

Actually, that's not so different from my setup. I have categories like "Social Media" which are based on folders. But the images in those folders still are versions of my masters from other folders. If I wouldn't let iMatch search the whole database for versions, I'd have to add a folder to it's search list each time I create a new event, photobook, forum post, etc.
The whole purpose of automatically detecting versions goes out of the window if they aren't detected wherever I place them (within the scope of the database).

Jingo · April 26, 2018, 01:42:25 PM

I agree in theory - versions should be able to be located regardless of location - but we all know there are limitations to the IM database and speed is a battle I am always fighting. Over the years, I have changed my workflow many, many times to accommodate changes in DAM software which required relocating old files and coming up with new schemes for importing new. I went to a JPG only database when I switched to IM3 because it was MUCH faster for me... with updates to my hardware (SSD's) and the latest (speedy!) version of IM - I could probably go back to RAW+JPG and full on versioning - but still there are limits and balances to keeping the software running smoothly for all users.

tvi55 · April 26, 2018, 01:53:41 PM

I store versions (usually generated in Lightroom) always in a sub-folder (or folders) to the directory with the master raw images.

So all versions are kept closely together with the master (good for backup), but are as well easily accessible for sharing (social media) displaying (slide-show), or other purposes.

Mees Dekker · April 27, 2018, 10:49:03 AM

I did not expect to see such wide and deep coverage of my, seemingly, simple question. Another example of the value of such a forum, that comes for free with IMatch.

From all the comments I read, it is clear that a change in my workflow and/or storage scheme will do the job. The problem can be solved in this way. Thanks for all the tips in that direction.