From ptWiki

By Normunds Kalnbērziņš (Normunds)

Contents 1 Download 2 Intro 3 Latest upgrades 4 Script features 4.1 Functionality 4.2 Limitations 5 Quickstart 5.1 Versioning 5.2 Synch metainfo between Bibble and iMatch 5.3 Send selected images to the Bibble workqueue 5.4 Synch metainfo among versions in iMatch 6 Bibble Integrator main panel settings 6.1 Image selection 6.2 Send to Workqueue 6.3 Versioning 6.4 Synch metadata with Bibble 6.4.1 Pull to iMatch 6.4.2 Push to Bibble 6.5 Categories to Bibble keywords 6.6 Global 7 Versioning 7.1 Setup/preferences 7.2 Metadata synchronization preferences 7.2.1 Categories 7.2.2 IPTC 7.2.3 Ratings 7.2.4 Labels 7.2.5 Properties 7.2.6 Exif/exiftool 7.3 Workflow/sample use 7.4 Some notes regarding versioning 8 Installation 8.1 Bibble integrator and BI Version finder 8.2 Exiftool 8.3 BI automatic versioning

Download

• BibbleIntegrator.v2.2.2.zip February 5, 2008 (use with 3.6.0.52)

This version contains fixes to make it compatible with 3.6.0.52 (backwards compatible with 3.6.0.50), but it has not been thoroughly re-tested again. Use it if you need work with iMatch 3.6.0.52. If you find any problems please contact me via my email in the iMatch forum profile or by a post or message in the Bibble forum.

• BibbleIntegrator.v2.2.0a.zip January 16, 2008, update "a" February 5, 2008 (tested with 3.6.0.50)

Intro

I'd like to introduce new changes with this version. I tried to incorporate different suggestions. Please let me know what you think about this re-write and what other ideas would be useful to implement.

Latest upgrades

2.2.1: code modified to make it compatible with both 3.6.0.50 and 3.6.0.52; functionally equivalent to BI 2.2.0

2.2.0: version carefully tested in 3.6.0.50; iMatch version 3.6.0.52 breaks the code

2.2: introduces more metadata synchronisation options (add labels, properties and exif data) and adds more granular control of synchronisation, mostly for IPTC updates, provides warnings about potential image file updates and visual indication of selected images and fixes a number of bugs. It also introduces an option to use versioning code automatically when iMatch adds a new image.

2.1.1.3: bug fixes; attention: if you have used 2.1.1.1 or 2.1.1.2 make sure to verify that all the settings (particularly Versioning preferences) are correct before running the scripts.

2.1.1.2: Included a search script BI Version Finder; select an image and launch this script to find all other versions of this image. New in version 2.1.1: National character handling when copying IPTC info to and from Bibble, optional version matching by regex expressions, preference settings on database level, more robust handling of invalid IPTC records, optional matching of images without exif data (see details below).

2.1.0.2: Another performance fix for versioning of large datasets; also allows originals not be under "originals directory" as far as they are RAW files

2.1.0.1: Performance fix, does not assign selected images to the exif data tree if they have already been assigned there. New in version 2.1: Adds iMatch side version synchronization such as categories/IPTC info and rating synchronization within a version set. It also fixes some minor bugs of version 2.0. The panel layout has been changed to reflect the fact that selection works in the same way for all functional groups/buttons.

New in version 2: Bibble Integrator (BI) provides support for the versioning of bibble files. Selection of the new Versioning enable option will make "Synch with Bibble" and "Add selected to workqueue" blocks work slightly differently than before. The BI will make sure the selected files are processed by the versioning routine and, if the selected file is a version, BI will attempt to use the original raw file as appropriate. See the section Versioning below.

Prerequisites: Bibble Pro 4 (tested with 4.9.8) and iMatch 3.6.0.50 or later. In Bibble select preference (General) – "save setting files (.bib) with original images"

Script features

Functionality

1. Finds the version set of an image – originals and derivatives and links them within iMatch, as well as associates the current bib-file (Bibble image settings file) with the latest version
2. Imports Ratings, Tags and IPTC values from Bibble and vice versa – exports them to Bibble. IPTC import from Bibble seems to be important as Bibble does not save IPTC data in raw files. It just writes this info down in .bib files. iMatch allows to write this info to the raw file.
3. Exports iMatch categories as IPTC keywords for Bibble. So once these exported, you open Bibble, then its IPTC editor and you can assign these values from the list.
4. Sends selected images to the Bibble as a workqueue (or adds to an existing workqueue); uses the bib-file of the particular version to display the image in Bibble
5. Synchronizes iMatch categories, IPTC and Exif fields, labels, iMatch image properties and ratings among versions

Limitations

• The versioning script will always associate the last new derivative found with the last Bibble settings file. So that you always need to import the derivative created and run the versioning script before further modifying image settings in Bibble. This is not likely to change unless Bibble implements their own versioning system; and in that case the current script might become much less useful.
• The linked bib-file will always contain the "current settings of the image". So in case you used default settings to generate the image (did not touch the raw file before the generation of the derivative) you will have no bib-file associated with the version; if anything else than "current" has been defined in "Image settings" section of the batch queue, the bib-file saved will not be the correct one as the real settings used by the batch queue could have been "default", "controls" or "from file" and there is no way to know which one.

Quickstart

Versioning

BI provides an option to maintain image version information in iMatch. It uses exif datestamp (original created date) to identify potential versions, and for images taken within one second (precision limit of exifdate), it matches the images by name.

It records the versioning information in iMatch image property fields _ImageID and _Version. These fields do not exist by default and need to be created manually before using versioning functionality. It also identifies the current Bibble settings file, creates a copy of it and associates it with the latest derivative.

You first need to edit Versioning preferences; there are a number of additional versioning options such as assignment of particular iMatch categories to originals and/or derivatives, moving processed derivative files to different location, automatic versioning when iMatch imports the image, etc. Make sure that you either use an independent script to create categories from exidate, or you select one of auto assign to exif date options, prefereably All. The latter will cause the versioning script always make sure all images have been assigned to an appropriate exifdate category and hence eligible to be matched as originals or versions. The script is very fast and processes only those images that are not yet assigned to the exif date category tree.

When you select images and run Get versions script, the script finds the original/versions for each selected image. There is no need to select versions and original at the same time. Still make sure that original is contained in iMatch database at the time you run the versioning script otherwise BI may end up assigning one of derivatives to be an original (exact result of the resolution depends of naming convention used and if you define regex expressions for original/derivative matching or use the default matching).

See description of Versioning preferences for more information as well as Bibble Integrator versioning philosophy for more information about how versioning is implemented.

Synch metainfo between Bibble and iMatch

BI allows to synchronize IPTC information, tags/bookmarks and ratings for selected images between the two environments. This is rather self explanatory, only note that on iMatch side we save IPTC information to the image file while in Bibble we store this information externally in Bibble settings file. See Bibble Integrator main panel settings for more information.

Note also that for versioned images the Bibble side always refers to the original image as that is the one that we edit in Bibble and that has the settings file. On iMatch side we can select either originals or derivatives. For example if we select derivatives and push ratings to Bibble, this will modify the rating info for the original on the Bibble side. If we selecte a derivative and pull info from Bibble, we will get current rating and IPTC info from the settings of original in Bibble and will write this info to the derivative in iMatch. In order to synch metadata within version set in iMatch, see Synch metadata among versions in iMatch below.

Send selected images to the Bibble workqueue

BI allows select images in iMatch database and send them for processing to the Bibble workqueue. Note that in Bibble we normally process originals/raw files, so that if the images have been versioned and we have selected a derivative, we will add the original to the workqueue instead. In addition, if this derivative have a Bibble settings file associated, this settings file will replace the current settings on Bibble side, so that you can start editing in Bibble from the settings used to create the particular derivative. See Bibble Integrator main panel settings for more information about options.

Synch metainfo among versions in iMatch

BI provides basic synchronisation options for metada within a version set. It allows to synchronise IPTC, categories and ratings using a number of options to provide maximum granularity and choice. This does not relate to the integration with Bibble, but allows to use the BI version as an independent versioning system in iMatch. See Metadata synchronization preferences for more information.

See Settings below more details about functionality.

Bibble Integrator main panel settings

Image selection

All BI actions that act on images work with images selected by the Image selection control. There is a number of options of how the images can be selected. Image selection section defines the source options for Pull to iMatch, Push to Bibble, Send to Workqueue and Synch metadata functionalities described below. We can select images either from:

1. A named Bibble work-queue. These images need not exist in iMatch before. If they are missing, the script imports them and, depending on what your chosen action is, adds ratings, IPTC information, finds original/version set, etc.
2. currently selected thumbnails (if you have selected a folder when running the script, this option will show the appropriate label and will return all images in the selected folder and subfolders),
3. from active selection – handy if run the script from context menu, but take care – from one-click bar it is equivalent to selected thumbnails (in iMatch 3.6.0.50 this selection mode is broken and is always equivalent to thumbnails option),
4. active result set – say if you searched for colour match of 2 images, then all matches is regarded as search result set
5. active iMatch folder
6. active iMatch category
7. OS (Windows) folder

The same selection list is being used for updates both ways (to and from Bibble), Send to Workqueue functionality and Synch metadata script.

The Image selection section has the current context window type displayed in top right corner as a reminded of what iMatch thinks the context is. In case it displays active window type as Thumbnails in red, it is possible that the selection has changed. Make sure you have the correct images selected.

Below the active window type, BI displays the number of selected images broken down in originals, derivatives and “unknown”. As you change the selection the script re-calculates the image count for the current selection. It will show this breakdown in originals and derivatives only if in Versioning preferences you have entered categories to be used for originals and derivatives. Unknown are images that do not belong to a versions set – these may be either yet unversioned images or originals that have no derivatives.

Send to Workqueue

Note: Workqueues relates to Bibble Pro and will not work with Bibble Lite.

Queue name - the name of the work-queue. Use characters allowed in file names as it effectively creates a file

Send – will write images to the workqueue with an option overwrite queue, that will remove content of existing queue, otherwise it will append

IPTC – if write is enabled we have replace/merge/write if empty options available as described in the section Pull to iMatch below.

Ratings – exports iMatch ratings to Bibble; an additional option allow update with empty rating defines if no-rating value in iMatch will remove an existing rating (1-5 stars) in Bibble

on exit start Bibble – after we have created/manipulated the work-queues the script starts Bibble. It does not check if Bibble is already running. In this case you might need to close and re-open Bibble before you can see the updates.

Note: For versioned images it is always going to be an original that we will add to the Bibble workqueue. For example if you send a derivative to the workqueue it will use its Bibble settings file (bib-file) as it was when it was imported/versioned, then add/overwrite rating and IPTC field values in this bib-file with the image's current rating and IPTC fields (provide these options are checked).

Some possible scenarios to illustrate the possible outcomes:

1. we have the versioning disabled and have selected an image DSCN_1234.JPG. In this case we will send the JPG to the workqueue as we have no means to know that we really expect to edit the original NEF file.

2. we have the versioning enabled (in this and following examples) and we have selected an original DSCN_1234.NEF, selected checboxes and options to write and replace IPTC info and update ratings; the image has been versioned and is marked with imageid and a version number. In this case we add the file to the Bibble workqueue optionally overwriting the queue, replace IPTC settings and rating recorded in Bibble.

3. the same case as before, but we have not run the versioning on our selected image. In this case BI identifies our file as RAW hence potentially an original, so it continues to inscribe it to the workqueue and copy the metadata

4. we have selected an image DSCN_1234.JPG that we have not versioned yet and the same metadata options as before. In this case BI cannot identify the file as an original and as it has no version and imageid, the script launches the versioning routine on this file to determine its original. Assuming that the search is successful as we have the original of our JPG – DSCN_1234.NEF – in our database, we add the original to the workqueue, but use the metadata from the selected derivative. During versioning we also back-up the bibble settings file, then write it back when sending to the WQ, but in this scenario we end up with the same – latest settings anyway.

There is a number of options that can modify this last scenario. It is possible that you shoot JPGs and attempt to send the original to the Bibble workqueue. In this case it will take too much time every time to try to find the versions of the each unversioned JPG we send, especially if there are many images in our selection. In this case we can do one of two things in Versioning preferences – we can define that JPGs are originals by adding JPG to the field Additional original extensions or we can define a directory of originals (Root directories, Originals) and keep our original JPGs under this tree. In both of these cases the script will send the JPG to the workqueue without attempting to version it. Of course this will disable the automatic versioning for the JPG images that are really derivatives and that in some cases are stored unders the same tree as the originals, for example in subdirectories of directories containing originals. If this is the case, make sure you keep the versioning state uptodate and run the versioning script before sending the derivative images to the workqueues.

5. we have selected an image DSCN_1234.JPG that we have versioned. In our iMatch database we have the original DSCN_1234.NEF and another DSCN_1234_1.JPG which is a later version of the same original. The other settings are the same as above. The current Bibble settings of the image is those corresponding to DSCN_1234_1.JPG which was created the last. However in this case we replace these current settings with those that correspond to DSCN_1234.JPG as they were at the time we added this derivative, and depending on IPTC/ratings, settings we override the old metadata with the current ratings/IPTC values of DSCN_1234.JPG. And finally we add the original to the Bibble WQ.

As we saw in this scenario, if we do not require the update of metadata when sending to Bibble WQ, we will start with exactly the same values that were Bibble settings when we created DSCN_1234.JPG, not with the ones that exist now. This might be one feature that should need to be changed, as logically it could be argued that sending to Bibble WQ without metadata update implies keeping the current IPTC/rating, but as far we understand this and have all the options to pull the current metadata from Bibble or get them by synchronising with the latest derivative, it is a minor inconvenience if any.

Versioning

The new block in version 2 allows to enable versioning support. If disabled it will be compatible with version 1 behaviour. Click Version prefs button to define versioning preferences before launching any version related tasks. The mandatory fields should be filled in before you can use any of synch/send to workflow functions when the versioning is enabled. See section Versioning below for description of the preferences panel and for more info about how versioning works or check out the more detailed Bibble Integrator versioning philosophy.

Get versions - a new button Get versions runs a script that matches image versions using exif datastamp and filename. Use Version prefs button to define several key parameters used by versioning. In case you run Get versions or enable versioning and run iMatch/Bibble synchronization code or send images to the Bibble workqueue, selected images that are not yet versioned get matched and their originals/derivatives get determined. In order to be versioned the images need to have a valid exif datestamp. They get matched by the timestamp and the filename, so the images taken within the same second and having a similar file name will be assigned as versions.

Version prefs - this button allows to modify the way versions get treated. See Versioning, Setup/preferences below.

Synch metadata - this button launches a metadate (category/IPTC field/rating) synchronization script. For the description of options see Metadata synchronization preferences below.

Metadata prefs - this button allows to define rules applicable when synchronizing categories/IPTC fields and ratings. In case the checkbox Show options on launch is selected this preference dialogue appears each time the script Synch metadata is run. For the description of options see Metadata synchronization preferences below.

Synch metadata with Bibble

As we have a iMatch centric world (we run the script from within iMatch) I changed the labels (Push/Pull) to reflect this.

Pull to iMatch

This action imports settings/metadata from Bibble settings file and stores as metadata (bookmarks or ratings) in iMatch database or in the case of IPTC data, stores them directly in the image file. In this point iMatch differs from Bibble as it always stores IPTC information in the image file independent if the image is the original or derivative.

Tags as bookmarks - imports Bibble tags as bookmarks

Ratings - imports Bibble ratings with an additional option allow update with empty rating, that is, allow to remove a valid (1-5 star) rating if there is not rating in Bibble

IPTC section defines the import of IPTC fields from Bibble settings and optionally allows to categorize images by IPTC keywords. If the checkbox and categorize by IPTC keywords is selected then the script will try to assign to categories with this names same as IPTC keywords. categorize by IPTC keywords – works both with dot notation and with plain keywords and attempts to match category. If the checkbox write is selected we can choose that IPTC update mode:

• replace will overwrite any existing IPTC info,
• merge allows to add only new fields (existing values win) and as well as merge values in multi-value fields – supplemental categories and keywords (in iMatch talk); and finally the option
• write if empty allows to write IPTC info if no IPTC fields have been entered in the target image yet.

The same IPTC update options are used in all other places where we copy/update IPTC information.

Bookmark updated - bookmarks all updated images

Label imported - mark all images processed with the selected label.

A new check box refresh updated is added to force iMatch update in case IPTC data are written to the file. It seems that iMatch normally picks up the new updates automatically, but if the info fails to show up, check this box (it might slightly slow down the script execution as it will force update of each image)

Push to Bibble

Bookmarks as tags - imports iMatch bookmarks as Bibble tags

Ratings - exports iMatch ratings to Bibble; an additional option allow update with empty rating defines if no-rating value in iMatch will remove an existing rating (1-5 stars) in Bibble

IPTC section defines the export of IPTC fields from iMatch database to Bibble settings. If the checkbox write is selected we can choose that IPTC update mode. For available values see section Pull to iMatch above.

Bookmark updated - bookmark all updated images.

Categories to Bibble keywords

Export to keywords button replaces Bibble IPTC keyword list if an option of overwrite keywords, else it appends to existing keyword set. By default the script exports the whole hierarchical dot-separated name. The option Export only last level will cause it to export only the direct category name, so closer to the classical understanding of the keyword.

Global

Contain a Trace prefs button that allows to enable printout to Scripting output window. This may be useful to track down the problems, for example enable Version matching to see how BI matches files using your regex expression.

Buttons in the left, bottom corner: Save settings – saves only the values entered, but does not execute any script. Click appropriate buttons in each section to run the scripts. Cancel – closes the dialogue box and discards the changes

Versioning

Setup/preferences

The versioning works similar to other versioning schemes implemented in iMatch and can be used in parallel or instead of other versioning implementation. At the same time it specifically targets image versions that has been created by Bibble and if present stores the related bib-files. For example we can store several a JPEG preview versions of the Bibble transformation, then select one of them, use "Send to workqueue" functionality of BI to replace the current bib-file with the one from the particular version. In this way we can use the same settings to create, for example, a high resolution TIFF file for further processing in Photoshop or Gimp.

Let us see, how this is implemented and what we need to set up, by looking at the preference panel.

There are few mandatory fields that need to be filled in before we run any BI tasks with enabled versioning. We will point them out as we go along:

• "Originals" (optional) – we provide the root directory for all raw/original images; this possibly narrows the application, however it is only preferable not mandatory to have all originals (and none derivatives) under this directory; it is used as one of parameters in order to determine if the particular image is the original or derivative and has a limited use in case you define your own regex expression(s) to match originals and derivatives.
• "Bibble version storage" (mandatory) – you must simply assign a space somewhere. This is the directory where we will store the versions (copies) of the bib-files (Bibble settings files). The files are small, get named using a particular rules ([imageid]-[version].bib) and should not be handled manually.
• the block "Move Bibble output to iMatch" (optional) allows to force moving of files from the Bibble output tree to the directory tree in iMatch that you use for derivatives. Each time we identify an image as a version, BI versioning script moves the image from "Bibble output tree" to the "iMatch derivative tree" keeping the directory structure. In case the file with the particular name already exists under iMatch tree (inevitable if you keep creating the new ones with the same name), BI versioning script appends "Image Version" property to make the filename unique. I for example define one output directory for batch queues and define that the output should go into subfolder “[YEAR]/[MONTH]/[DAY]”. Then when I import images in iMatch I use the option above. It is perfectly possible to leave these fields empty and keep the derivatives at same place where they were or use later iMatch to move them around and rename – once we have them versioned, we can rename the images without any problems as their relation to the version set has been defined at the moment when we assigned them the imageid and version number.
• "Exifdates" (mandatory) – BI versioning uses a combined approach to find/group versions. It marks all members of the version set with and ImageID (see below) and it uses a category tree by exifdate (one category for each day with a photo) to limit the scope of search. It versions only the images under this category tree. Hence before we attempt to find/link versions we must be sure that all images that we want to match as versions have been assigned to a category under this category tree. Use the dot notation to define a subcategory as a target. In case the entered category does not exist the script will create it. It is possible to use existing categories created annd/or maintained by other scripts. I was told that there are two options other than the originally offered cascading system – flat with hyphen (2007-11-21) or colon (2007:11:21) as separators, so I provided and additional option to re-use the existing categorization. Understandably whichever system you apply all images have to be assigned to date categories according to this system before they can be versioned.
• "Auto assign to exifdate category" helps to make sure that all relevant files (originals, derivatives) have been assigned to the "exifdate category tree", so we have an option to automatically assign them. The simplest would be to use "All" option that will make sure that all images in the database have been categorized, but I assume that there may be other considerations. The most restricted option is "None" that means that only those images the are already under exifdate tree and those images that are currently selected can be matched; no other images will get automatically assigned to this category.
• Two optional category related checkboxes: "missing exif from parent folder" will search parent folder(s) for original or version with exif info and will use date from this other image. In case you have defined regex patterns (see "Regex patterns" below) for matching, the script will copy exif date info only from the original, else it will take it from original or version, whichever it first finds.
• "copy categories from last version" will assign the new version to the same categories than the last version or the original (with exception of "originals" in latter case). This might usually be handy though not always we will have all the same categories for all of the versions.
• the next (optional) block "Assign originals and derivatives to categories" allows to define categories that we will assign to either originals or derivatives, or both. While not directly necessary for the execution of the Bibble versioning script, this could be handy to identify originals vs. versions. Also if these categories are present, BI script uses them to speed up execution and in some cases provide additonal information by being able to split selected images into originals and derivatives. In case you add these categories later, re-run the versioning script to assign all images to the correct categories so that the data are consistent. An additonal checkbox “assign bib-versions to subcategory” will add a subcategory “bibble” to the category you assigned for derivatives and will assign to it all those images that have backed up bibble settings files (that we can later re-use by selecting those derivatives ad sending them to the Bibble workqueue).
• the (optional) block "Version matching" allows to define two other parameters used in image matching.
• "Additional originals' extensions" provides the extensions of your potential originals. I have hard-coded a number of raw filenames (not from Bibble site, so we may need to add to this list) – "NEF", "RAW", "CRW", "CR2", "ORF", "SRF", "K25", "KDC", "DCR", "MOS", "TIF", "MRW", "PEF". In case you have different original extensions or for example you use JPG as originals add these extensions as a comma separated list in this field. The versioning will work without this information, however in some cases, for example, if there are a number of versions, this info (along with the field "Root..Originals") may be used to decide which file is the original. Also, in case you attempt to send an un-versioned file to the Bibble workqueue BI will attempt to version it, unless it can guess that it may be an original.
• "Regex patterns" – allows to define one or several case insensitive regex expressions in a format originalname.ext:derivativename.ext,... (no space after or before comma unless it is a part of the filename). The regex syntax is that of VBScript, see Expression Syntax (Scripting) For example pattern: ^\w*_([a-z]*_[a-z]*\_[0-9]*)\.(?:NEF|CRW):\1(?:-[0-9]*|)\.(?:JPG|JPEG|TIFF|TIF|PNG)$ will match _water_melon_1.NEF (original) to water_melon_1-11.JPG (version) and ABCD_downhill_skiing_0091.CRW (original) to downhill_skiing_0091.TIF (version). In case you provide a comma separated list of several regex patterns they get matched in the order they are entered, i.e. at first we attempt to find the original by comparing all files (within the same timestamp second) by using the first pattern, if it fails, we take the next one, etc. See some more examples in Bibble Integrator, regex samples
• From the block “Db properties used”, two – "Image ID" (String) and "Image Version" (Unsigned integer) are mandatory and are used by the versioning. You can use different names if you wish than ones provided by default, but make sure that the properties you enter in this field have been created before running the script. Unfortunately I see no way to to create Properties definitions automatically by using a script. A new checkbox related to imageid is called omit exif datestamp and it will not prepend datestamp when creating imageid, in case the filename itself starts with this datastamp.
• “Created date” (optional) is used to speed up the date matching and will store a copy of the exifdate (Image.EXIF.Date and time Original). The use of it versioning and version retrieval, so it is recommended to create this category and fill in the name in this dialogue box.

A new checkbox enable automatic versioning is available in case we have implemented a database script (see Installation section below) that intercepts adding of images and runs the versioning routine on each image as it gets added to the database. In this case this checkbox is active and can be used to stop start the automatic versioning.

• checkboxes "Show options on launch" and "Save settings on run" are related to the option to display this dialogue box when clicking on "Get versions" button. In case the checkbox "Show options on launch" is checked this preference dialogue box is shown upon clicking on "Get Versions"; in this case it contains also a Run button.

Metadata synchronization preferences

At the top of the panel we have an image selection indicator. If we arrive in this screen by using Synch metadata button, it contains information about selecte ddocuments. In Edit preferences mode it is empty.

Categories, IPTC, Ratings, Labels, Properties and Exif all have separate setting sets. We can select disable option (or uncheck push option) for any of them to synchronize only the other metadata sets. All data sets can optionally exclude original of the version set (if update original is unchecked). Original always refers to the image identified by BI versioning as “original” or version nr. 1.

For Categories, IPTC and Ratings, Push refers to writing data from the currently selected image(s) to other versions of this image, Pull copies appropriate data from other images of the version set to the select image(s) and finally Synch copies the same information to all images of the version set.

Synchronisation of Labels, Properties and Exif data offers only Push mode, i.e. the values from the each selected image will get copied across all members of its version set.

Categories

In Categories section Pull and Synch combines categories before writing them to the target images. The checkbox Merge/add modifies updates for Push and Pull options in a way that the info get added (or merged) to the existing categories. If this checkbox is unchecked the pushed or pulled values overwrite the existing ones. Understandably this does not apply to Synch mode as in this case the data get combined and include categories from all images in the set, so merge option would not modify the behaviour.

For Pull and Synch options, the categories to be copied get aggregated from all the versions in the set (for Synch including and for Pull excluding the source image(s)).

In the field Ignore categories equal or starting with... list comma separated categories that will be ignored and never copied or overwritten. Spaces are regarded as a part of the category name, so take care not to leave any space if you do not intend to. Use dot syntax to indicate a particular branch.

The checkboxes Originals updatable and Update empty only modifies the target image set by allowing to exclude originals as well as allowing updates only for images with no category. Image is regarded empty or having no categories even if it contains any categories from Exclude categories list.

IPTC

IPTC section is similar to the Categories section above. The data can likewise be pushed from the selected images, pulled to them or in Synch mode the same updates written to all members of the version set. In case of Pull or Synch there two points where the data could get merged. One is during creation of dataset in Pull and Synch modes, when we need to create a single IPTC data set the will be written either to the selected image or to all images of the set. In this case the merge of IPTC data this applies only for Keywords and Supplementary categories that can have multiple values. Otherwise fields that are not empty and have different values may be lost. If you set the IPTC field Caption for one version to "Frère Jacques" and that of the other to "Father Williams" the result of Synch action is undetermined. The script uses data from the selected image if present, then the data from each image in turn starting from the oldest image and each time the already merged field wins.

The second merge point is upon writing the data to the image (in iMatch the IPTC data will always get written to the target file itself). At this point it can be determined by selecting in updates section replace (all data in target file get replaced wby the new data set), merge (only fields that does not exist in target get written and multi-value fields get merged) and write if empty (IPTC data will get written only if there is no IPTC info at all in target).

Ratings

The Ratings section works similar to two previous section except for Pull and Synch options the rating gets additionally selected/calculated. Mean calculates the average rating (for Synch including and for Pull excluding the source image(s)); Mean- rounds 0.6 down and Mean+ rounds 0.4 up.

Labels

In Labels section we can enable Push option and optionally add a comma separated list of labels that will be excluded from the push. Use minus sign (“-”) to exclude no-label state being copied over.

Properties

In Properties section we can either copy all properties or optionally include some or exclude some properties from being copied over. Enter them as comma separated list. Version property used by the versioning code itself will get always excluded.

Exif/exiftool

Exif section is slightly more complicated. This is not a part you might use in your everyday work, but rather for a one-off job to correct some problems in your Exif data. Or probably you might want to edit something such as GPS data, then you will need to copy if over to other images.

If we choose the option iMatch it is fairly straightforward - we push all exif information with possible exception of some maker notes. The only additional options are writing to original (update original)and reset of orientation to top/left (=1) in case incoming exif has different orientation setting. These settings are common for both iMatch and exiftool options.

On the other hand, if we choose Exiftool, the script will use the windows executable of exiftool.exe (version 7.06 included) and provide a command line parameters. As a result we can use practically any commands exiftool is able to execute, including copying of IPTC and XMP information in addition to EXIF. It is extremely powerful, but will handle often under-documented in-image formats so has a potential of ruin some data.

In case you are not familiar with the tool, it is recommended to read the exiftool documentation (http://www.sno.phy.queensu.ca/~phil/exiftool) to understand what you can expect from the different options. The tool writes data to the file, so make sure you test the operations you intend to make carefully before using them with original images. In some cases such modified data formats can be read by some applications and not with others.

Make sure you test it on test images in test database and always have backups of your original files and that you understand the implications of clear and copy options.

The BI implementation provides a few quick checkbox options to clear all of parts of information in target and copy whole blocks of metadata – xmp, iptc or exif. Additionally we can choose if we change exif updated date to the current one, allow exiftool to ignore minor problems and to choose overwrite in place option. If this last option is not selected exiftool will create a backup of each processed file with the same filename appended with “_original”.

As an option we may choose to take the source data from XMP sidecar (if it exists) and write to the sidecar of the target (if the target is a raw file, else the target XMP option gets ignored). I would not expect you will need this option in a normal course of using iMatch.

Finally we can fine-tune the exiftool by adding any information to the command line in a freeform field. For example instead of checking the whole block options, such as iptc, exif or xmp, we can enter the particular tag we want to be copied over.

In order to document/trace the use of exiftool, you can open Tracing prefs from the main panel and select Exif/exiftool checbox. This will cause the script to write additional info (including exiftool output in a verbose mode) to the iMatch script output window.

Buttons in the right, bottom corner:

• Save – saves only the values entered, but does not execute any script. Click appropriate buttons in each section to run the scripts.
• Cancel – closes the dialogue box and discards changes

In case the checkbox Show options on launch is checked this preference dialogue box is shown upon clicking on Synch metadata; in this case it contains also a Run button.

A new checkbox refresh updated has been added to force iMatch update in case iptc/xmp/exif data are written to the file, so it applies to IPTC and Exif/exiftool sections. It seems that iMatch normally picks up the updates automatically, but, if after script execution the info fails to show up, check this box before running the script (it might slightly slow down the script execution as it will force update of each image)

Workflow/sample use

The setup I had in mind when writing the script was to keep three separate trees - originals, derivatives and a temporary tree for Bibble output (and move the images to the derivatives once we have identified the original and marked the version with a particular VersionID). Still this is not mandatory, provided the script is able to tell originals and derivatives apart even if they are stored under the same tree. There are no particular rules for the filenames apart that they must be similar enough, up to the point when we run the script and match them. For example it is be enough if the filename of the original (without extension) is contained in the derivative file name.

Sample use 1: Import original raw images in iMatch, rate, categorize, sort and select few of them to be processed in Bibble. Start Bibble Integrator (from menu or click in the scripts sidebar aka one-click bar, if you have added it there), define appropriate selection conditions an click "Send to workflow". Change Bibble controls, then send the workqueue to a "JPEG proof" batch queue that stores the output in (or any place under) the directory we have defined in "Bibble output".

After Bibble has finished, start again BI, select Bibble output root directory as a source using option OS Folder and click on Get versions. BI will import all derivatives, categorize all images by date, find originals, mark versions and store the current bib-file for later use. Now you might select a number of originals that you want to convert to B&W (some of them already processed in the first step). Send them the same way to Bibble, adjust Andy and/or Tony or use some other means of conversion, send the workqueue to the appropriate batch queue and, after it finishes, import the new derivatives again by using "Get versions". Note that when using OSFolder as a seleciton source, we even do not need to import the Bibble output images – they get imported and stored in iMatch as the part of the versioning. Now as a result for some original images we have in iMatch both colour and B&W versions. We can select any of these, run BI, select "Send to workqueue" and we will get the bib-file that was used when we created this image; we can use the same settings now save a new version as a TIFF instead so we can work with it more carefully in Photoshop.

Sample use 2: initialization of the versioning: Import original raw images in iMatch, rate, categorize. Process some of them in Bibble, import derivatives; change Bibble controls, create some more versions, import them again. Now we have a typical "pre-Bibble versioning" system. Once we run BI and click Get versions, BI attempts to sort out the versions and save bib-files. However in this situation we have only the last bib-file available and it gets attributed to the last derivative found in iMatch. If we subsequently create new derivatives from Bibble and repeatedly run the script, the new images will get associated with the new bib-file versions. Test on a smaller database before attempting to run versioning on all your images. Provide enough time for the full run, possibly an hour, if you have a large database with 100k+ images.

Sample use 3: indirect versioning: We have imported originals in iMatch; then we create a set of derivatives using Bibble and also import them as usual in iMatch database, not necessarily under the appropriate root directory. We select a derivative image, start BI, but instead of clicking Get versions, we select Send to workqueue. In case the versioning check box is enabled, BI attempts to version the image, finds the original, stores the current bib-file with the derivative, then writes the name of the original file to the workqueue (we normally work with the RAW file in Bibble, right?) and opens Bibble. The act of sending a potential version to the workqueue had triggered the versioning, so we did not need to run it explicitly.

Some notes regarding versioning

• Single originals (without derivatives) do not get versioned. Images get marked as original only once we are able to identify at least one derivative. For this case it is advisable to correctly store them under Originals tree or make sure that they are regarded as raw files (use Additional original's extensions field if necessary), so that BI does not attempt to version them each time we send these originals to the work-queue or synch with Bibble. This behaviour does not cause any problems, except that each operation will take a little more time. Note though that by adding JPG to the raw extensions list, we will disable the "indirect versioning" for JPG files, so we will have to make sure we run the versioning script explicitly before "sending" the derivative "to the workqueue".
• The filenames of the non-versioned files must be similar. There are two possibilities. Either you provide one or several regex expressions to describe how to match originals and versions (see "Regex patterns" above), or the script uses a simple algorithm to find similarly named files. For example the original must be located under the originals directory or be a raw file or filename of the version (without extension) must start with a filename of the original.
• After the versioning script runs, the names can be changed to fit any other patterns as the versions get further maintained and matched by the image properties.
• In case the simple method creates false positives or does not find all versions, use the regex method that allows to precisely define the relationship between originals and derivatives according to your naming schema.
• Assignment of images to Originals and Derivatives categories as well as the assignment of CreateDate property improves the speed of versioning and retrieval.
• Since version 2.1.1.1, Bibble Integrator includes BI Version Finder script that builds on the Version Finder script family, but performs search by the ImageId property value assigned by BI.

Installation

Bibble integrator and BI Version finder

Unzip to iMatch script folder (..\Application Data\photools.com\IMatch\Scripts\User) and you are in business (you may need to restart iMatch). By default it adds Bibble Integrator and BI Version finder to the Workflow\Bibble category; add it to the Scripts sidebar (in the one-click bar) or to the context menu if necessary.

The folder path depending on your configuration may be: Documents and Settings\YourWindowsUsername\Application Data\photools.com\IMatch\Scripts\User or Documents and Settings\All Users.WINDOWS\Application Data\photools.com\IMatch\Scripts\User or similar name.

Exiftool

Exiftool executable (Version 7.06) is located in BibbleIntegrator\Includes directory. In case you need to upgrade the version, rename the executable exiftool.exe and replace the file in this directory.

BI automatic versioning

In order to be able to use Enable automatic versioning checkbox we need to create or edit database script:

• Download this script sample: Media:Bi-2.2dbscript-sample.zip
• Copy BibbleIntegrator folder from Scripts\User where you installed it to be avaialble from menu to the database folder (where your imd4 files are located).
• If you do not use database script, copy this script to your database directory and name it accordingly. If the db name is photos.imd4, name the script photos.bas.
• if you have existing db script, open this script and copy the lines referencing vHandler and lines that start with '#uses to your script. Save and close the file and re-load the database.

Now you must be able to select enable auto update in Versioning preferences. If this setting is checked, any new file added will get assigned to the version set automatically. In the same way as for manual versioning, make sure you have imported the originals before versions.

Known problems with "auto-versioning":

1. there is an apparently iMatch problem that will not allow iMatch application to close if you use above script (it is a more generic problem of using some type of code in db script). As a workaround, when you finish work with iMatch, you need first close the database and only then close the application. Attempt to close the application while the db is open will not work and the iMatch will not close down any more.
2. if you intend to use automatic versioning (or any other db script), it does run with limitations on 3.6.0.50 (see the note below) and currently there is a problem with the BI compatibility with iMatch version 3.6.0.52. The new version of BI 2.2.1 contains modifications necessary to make it compatible with 3.6.0.52 however it is not carefully retested. Use it on your own risk.

Limitations for 3.6.0.50 - will use this script only when you open the db for the first time. If you later close the database without closing iMatch and then re-open it, the script will not load and as a result the automatic versioning will be disabled.