Can I copy categories from a (large) set of images to another?

[markkums]

Hi there,

I am grasping an arrangement where I would create a new db for iMatch and include there my future photos +only a part (obviously 5 newest years) of existing images. The rest of images (10 older years) would remain with the existing db only. Now, if I  rescan those images of the last five years to the new db, they will be displayed there without their current categories, am I right? Is there any straightforward mean to get same categories with images as they have in the existing db?

There mayt be some obvious things regarding this kind of matter that I do not know, but let me know.

B.r: Markku

[JohnZeman]

If your categories are @Keyword categories then it'll be automatic since the categories (Keywords) are written to each file.  Just add the images to your new database and refresh the category tree and you should be in business.

But if you're using standard categories and not @Keyword categories then outside of IMatch I'd probably duplicate your existing database then in the duplicate I'd manually remove all of the images you don't want in the new database.  Afterwards do a compact and optimize on the database and you should be good to go.

[Mario]

Were these images already indexed by the original database? And you now have "split" your database into two, where the new database has only a part of the files of the original database?

1. Do you really need two databases? IMatch works very well and fast up to 500,000 to 1 million files.
Working with multiple databases makes things much more complicated.

2. To split a database, you usually

a) Make a copy of the database in Windows Explorer A => B
b) Open B and go to Edit > Preferences > Database to change the unique database id (Change Database ID)
c) Use the "Remove from Database" command to remove folders you don't want in B
d) Open A and remove all files you don't want in A

This way categories, Attributes etc. stay intact.

3. If you really need to create a B database from scratch but you add a part of the same files you already have in A, you can use the Category Export / Import to transfer categories from A to B.
See Importing & Exporting Categories
If the files in database B are in the same location as they were in A, IMatch will automatically re-assign them. If you have moved the files, use the "Checkum" option when importing.

[markkums]

Hi,

Mario and John, thanks for your replies.

Yes, my categories are std categories, so they will not be copied in rescanning of image files.  One thing which suggests this idea of split is, that I have all image files on outside HDDs, which are now connected with PC on need basis. By splitting db (and image storages) I thought need for creating connections would be less.

Now, I understand what is needed to do  the split, I reconsider the work and if it really is reasonable to do.

B.r: Markku

[Mario]

If you take part of your image collection temporary off-line (because you disconnect the external drive or network resource), IMatch has no problem with that.
It just shows the folders and files as off-line until you connect the disk again.
Searching, sorting, metadata input (no write-back, obviously), viewing files (if cached) etc. all works with off-line files.

In the early days of IMatrch, users managed their collections on dozens of DVD disks. Later on BR-D. An IMatch database managing files on 20 media from the same drive, with only one media on-line at a time, was pretty normal.
Thankfully we don't need this anymore. External disks or USB sticks are very cheap, and have replaced DVD/BR-D.

Even if you use multiple external drives with the same drive letter, IMatch can differentiate them and will show two drive nodes in the Media & Folders view.
All except the connected drive will show as off-line.

Splitting a database, and the extra work and potential problems stemming from that, is usually only needed of the database becomes to large to handle.
And this depends on the number of files you manage, the performance of your computer and what you actually do with the files.

My largest database has 850,000 files and it performs well.
The "performs well" limit can be reached earlier, even with a smaller database, if you run IMatch on an older Notebook instead of a modern workstation.
Or if you have tons of metadata and you need many and complex data-driven and formula based categories.
And, searching/processing 500,000 files takes approximately 5 times as long as searching 100,000 files.

In general, I would not split an IMatch database unless really needed. It complicates things a lot, from working with metadata to categories to Attributes to people to backup.

[markkums]

Hi Mario,

Thanks for further backgroud of iMatch capabilities.

My db is not even close to that 800k, I have now some 200k files  in total. So, this idea is maybe not so useful.

I try to look for my "workflow" and ,maybe, consider if there could be some enhancements in the system hardware.

B.r:: Markku