AnnotateImages : volunteers add image annotation

This is a menu of the topics on this page (click on any):
Background
Instructions for Annotating Images
Software Evaluation
Software Improvements Improvements Already Made Improvements Not Yet Made .

Background

We have thousands of images which have virtually no digital or on-line documentation. A high priority for H&A is to improve our presentation of them, to integrate them into the rest of our archives, and to provide a means whereby volunteers can provide annotation. A great deal of the annotation will be found leafing thru Swim Magazine and typing in the photo captions. Click here for our description of the Image Library Project. The purpose of this page is to specify the conditions and requirements for how the annotation process will work.

We do not have the legal right to put Swim Magazine photos on the web unless we get specific permission from photographers. Whenever we have asked permission, it has been granted, but photographers have only granted permission to Swim Magazine to use their photo in one (or maybe more) issues of Swim Magazine. Any other use requires explicit permission for USMS. Therefore compact disks with small versions of images are the logical way to give volunteers access without going beyond our legal rights. The small versions of images will not be of sufficient quality to be useful for a publication, and, furthermore, distribution of the CD's can be restricted.
Maintenance software currently in use for H&A runs under Windows and uses HTML for display. This approach can work on a CD as evidenced by the CD distributed at convention Some of this software is written in APL, and APL will continue to be used where it is not cost effective to re-write the procedure in another language. Other languages (which are in more widespread use) will be preferred whenever new development work is being undertaken. For background on our use of APL, see Archive Origins.
We need to make it easy to ensure that our image library is in accord with our policy. This means web images and thumbnail images should be automatically created whereever they do not exist or do not conform to our policy. Adobe Photoshop and batch processing with ULead Smart Saver Pro are far too labor intensive to provide for management of our thousands of images.

Instructions for Annotating Images

Instructions are being developed at the following webpage. www.swimgold.org/committee/annotation.htm. The library of images we are working with and the annotation we have so far is identified at www.swimgold.org/committee/work.htm.

Software Evaluation

IMGInfo was created by Carl House and Eric Landau using Eric Lescasse's Objects to provide for image annotation. It is part of a suite of four workspaces used for archiving images for United States Masters Swimming:

IMGInfo - provides a form & database capture so image annotation can be created.
IMGIndex - creates an index of all images in any folder, showing annotation & thumbnails.
IMGBatch - uses apldraw.ocx to resize & change image format.
IMGLib - manages a database of images supported by the above facilities.

IMGInfo (runtime system) is on-line in a 1.8mb zip file at www.swimgold.org/ttdb/imginfo. The zip file includes all files needed. It requires no installation; simply unzip all files in the same folder and run them by clicking on the "imginfo.exe" file. (Anyone who has licensed Eric Lescasse's Objects will be provided a development workspace on request.)

imginfo.ZIP	2,030,730	1/9/03 18:53:40
imginfo.w3	1,048,586	1/9/03 18:52:12
index.htm	78	12/19/02 07:47:52
imginfo.ini	65	11/25/02 11:40:49
imginfo.exe	1,649,664	12/12/01 15:13:04
apx20ocx.dll	98,816	12/12/01 15:09:10
imginfo.adf	360,989	5/14/01 17:25:42
pch58d4.jpg	20,548	4/12/97 05:18:48

Software Improvements

Here are some suggestions for IMGInfo from Jeremy Main and Katie Cooper (running Windows 98) who served as our first two testers. The order of these suggestions is rearranged in accord with our expected priority for implementing them.

Improvements Already Made

1) The complete path for the current picture should be stored as one of the data elements along with the index info. This way, if the index was ever corrupted, it can be rebuilt (component one). Also, the path is part of the index info, so you don't have to refer back to the directory for it. This extra protection and convenience can be handy later when combining files or building a meta-directory. Yes, it duplicates some data, but provides valuable backup. It allows each index component to "stand alone". (Carl: this has been done.)

2) Katie found navigating to the proper folder to be unnecessarily tedious. The facility will be revised to "remember" the last used path and start again there. Whereever we store the last used path, we'll also store "captions" as a temporary solution for that request by Jeremy. (Carl: this has been done.)

3) Jeremy says the "Text" box should allow hard carriage returns to be entered so that the text can be organized into paragraphs. Currently, no hard returns are allowed. Also, when testing, he says he typed right off the form for a word or two before the text folded to the next line. He could never view those two words no matter the size of the form. A cut and paste proved that the data was really there. (Carl: this has been done.)

4) Jeremy would also like to see more up front components set aside for future use in the .sf index file. The global variable for captions could go into one of them. If we exchanged files for someone else to view, then the appropriate captions would go with them. (perhaps unlikely, but flexible just the same.) (Carl: five file components are presently set aside up front.)

5) What does the 'reset' button do? Nothing visible happened on the form when I clicked it. (Carl: It sets the data back to that which is on the annotation file. Perhaps we need a clear button.)

Improvements Not Yet Made

6) Katie found that if you try to begin work in a folder that has no images, it seems to crash. Obviously the facility should be made more robust to handle this possibility, whatever it's cause is.

7) Always display the file name even if it means truncating the beginning of the path (or the middle if you want to get fancy). Currently, if you have a long path name, the file name goes off the form and doesn't display. Sometimes file names are very descriptive and we'd like to be able to see that on the form. (Carl: I agree this is important.)

8) Use the tab key to tab only between the input/clickable fields of the form. And in the likely order of input. Presently, a tab will take you to the label of the path of the picture.

9) The RTS version is also putting up a "Messages" log window and both windows are on a maximized "USMS H&A TTDB" form. Is this what is expected?

10) The RTS version remembers (re-displays) the previous index entries. Opening the form in developer mode, using the same directory, does NOT re-display the index info. I think this is what we were seeing in Naples (Jeremy).

11) Since we're using IE to display the pictures, it supports many picture types: jpg, png, gif, etc. so our facility should be capable of handling more image types, especially .png.

12) I also have a couple of other ideas but want to formulate them in a bit more detail first. .../Jeremy