I am a photographer and a software engineer by trade. Over the years I have amassed a huge collection of photographs of both film (mainly slides) and digital images. Some of these images have a very high value to me, some are irreplaceable.

One problem I have encountered is where and how to store my collection of Images. One source of reference was Peter Krogh’s book The DAM Book: Digital Asset Management for Photographers. (Nov 2005).

This introduced me to DAM. DAM is based on standard document control systems with simple rules:

1. Being organised

2. Do No Harm

3. Be Safe With Your Data

4. Back Up Supporting Documents

5. Make three copies of all important asset items.

see: Simple DAM rules.

These rules are standard practice in the IT world but not normally applied to photography.

These are very like the same rules I use as a Software engineer to manage software projects but applied to photography.

So my idea was to write some software that encompass these ideas. ImgArchive is that software.

ImgArchive is based on DAM practices and components, plus IT Software Control Systems such as Azure DevOps, SVN and GIT.

How ImgArchive supports DAM practice

This section describes how ImgArchive embraces standard DAM practice.

Repositories

DAM defines two repositories that use used to support image storage reequipments. ImaArchive largely contains these repositories in the Digital Vault which are invisible to many users however, these repositories are fundamental for both DAM systems and ImgArchive.

The DAM defines the use of two repositories:

• A Master repository - for containing master or original images.

• A Derivative repository - for containing Derivatives of the master image (versions)

Both repositories have optionally two backups. As it is unusual to delete only add to these repositories then they will only grow in size as more images are added (imported). New items will normally be at the top of these repositories so making archival backups to tape or DVD more easier.

further to this, DAM defines a image naming convention that is mandated across the archive. In ImgArchive this consists of a dated partition system that holds a days worth of images. Each image within that day must have a unique image file name that formatted in a consistent way. The image file name must be unique within the day partition and is best practice to make unique across the archive. see file naming below.

Working files

DAM defines a set of working files, ImgArchive supports these working files as the Workspace. The Workspace is a controlled area for editing working image files. This supports check-out check-in strategy for version creation in a similar way that computer source code is controlled. The only deviation is that in practical terms on one person can edit an image at one time. So only one editable copy is checked out to the workspace. In the case of computer source code that can be edited by more than one person so there is no constant to the number of times a source code file can be checked out.

Like the repositories the work space is organised in the same way. The Workspace consists of a dated partition system that holds a days worth of images.

Metadata

Metadata is an integral part of the DAM philosophy. DAM splits metadata into categories, From autogenerated to user added information.

This can take the form:

• Process information

• File information

• EXIF information

• Bulk information

• User added information

This list is in the order of the time consumption to the user. User added information is the most time consuming. ImgArchive supports these categories mostly as part of the import process.

Both an internal and external Exif readers are supported by ImgArchive, Metadata templates are used to add bulk metadata at the image import stage and image Metadata can be updated using the Metadata command. see Metadata

File Naming

DAM specifies that image names must be unique in the archive. ImaArchive has a number of re-naming methods, by default creates a 6 digit number. This is carried out at import time. The original name is also saved in the metadata. see File naming

Work flows

DAM describes a number of works flows that are used for common archiving activities. ImaArchive enables you to automate all of these common work flows. This is a big part of what ImgArchive is, These work flows are the things that make the archiving of images time consuming, Having ImgArchive automate these jobs not only saves time but makes these DAM work flows more consistent. These work flows are described in a bit more detail below.

• The Import Work flow

• The Edit Work flow

• The Export Work flow

• The Catalogue Work flow

• The Maintenance Work flow

How Software Control Systems fits-in

Source computer code is made up of individual files which are then compiled into a computer program. These source files are expensive to produce and can change many times and can be moved from one project to another over a long period of years. It is rare for them to be deleted, and many of the source code control systems make deleting source code files difficult. The only main difference is that they store a text files in a repository and not binary files such as a digital image.

This makes an important difference, Text files can be shared and updated. The changes can be then merged back into repository, the only the changes stored in the repository. This is known a non-exclusive check-out for changes, i.e. files are copied out of the repository for changes (checked-out) then back in after modification and a new version made (checked-in). Text files can be changed by a number of people and be merged latter.

In the case of binary and hence digital images, they can only be changed exclusively by one person using one copy of the original image i.e. (checked-out) exclusively. Once the modification complete copied back into the repository (checked-in) to make a new version..

However these source code control systems can store binary files but unlike text files can not be shared between users or edits.