| HelpSet Table of Contents | Back to Project Home Page |
What follows are recommendations on how to manage your Slides collection and how to get it organized in Project Hirtius based on my personal experience. Of course, these are just guidelines. Please feel free to use the tool as it best fits your needs.
Here is an overview of the process:
Let's now discuss each of the steps in details. Please keep in mind that some of them only apply to the first time you will do this. Also, the order defined in the list above is not necessarily strict for all items (you can take steps 8, 9 and 10 in any order, for instance).
(optional but recommended) Through the INXtree Browser and if you don't already have one, you should create a tree structure (= INXtree) with categories that you can then attach your Slides to (or indeed any of the other supported object types). A small part of this structure might look something like this:
Architecture
Civil architecture
Military architecture
Religious architecture
Cathedral
Chapel
Church
Epigraphy
English
French
Latin
Sculpture
In the round
Intaglio
Relief
Stone
Wood
Of course, you don't have to define the entire structure before you start attaching objects to it. You can always expand it later, as the need for some new classification is revealed by the data you manipulate during your research. But it makes sense to start from a basic structure that is already developed enough, to avoid having to reclassify too many existing objects (which is easy enough to do, but takes time).
More recommendations on the design of your INXtree are available in Concepts, and there is a detailed discussion on how you can reorganize that tree while you work in the Projects Management Workflow should you see a need to alter its structure (which can be done without breaking any existing object link).
Please note: there are limits to the size of your INXtree, not in terms of "lines" as this is stored in a database table, but in terms of leaves per node and maximum depth of the tree. Please refer to Database Layout and Database Statistics Page for more information. Both of these parameters must be selected at installation time (see Global Definitions File and the INSTALL document) and can no longer be modified later on.
Your Slides will typically be held in so-called "Trays". If we're talking about actual 36mm slides, the trays would be the straight or circular plastic holder units that you could fit in a projector. For still prints, your photo albums would be your trays. And when talking about digital shots, the trays would correspond to a directory structure on your server, visible to the Project Hirtius application (see section below).
But before creating your Tray records, you need to decide on a Tray management policy. How are you going to organise your pictures? Will you just store them all in sequence, filling one container after the other? Will you define a few high-level categories and group your pictures accordingly (e.g. a container for 'Architecture', another for 'Sculpture', etc.)? For what it's worth, I chose the latter.
Then, you also need to come up with a naming convention for your trays. This may depend on the kind of pictures you will archive. Slides? Prints? Digital? A mix of all of these?
Here is the way I do it. My tray names are on 4 positions: 3 digits followed by a single letter. These 4 characters, taken together, must be unique. The sequence number identifies the container. The letter identifies either the sub-container in the case of slides, or the media type otherwise.
Let me explain: my slide trays are plastic boxes with 2 straight holders inside, storing 50 slides each. So I have a single number for the box, and I call 'A' the left holder and 'B' the right one. In the case of digital shots, I use the letter 'X', and if I had regular photo albums (I don't), I would use the letter 'P'.
So my Trays could be called 003B, 027P or 049X for instance.
Please note: It is also possible for you to digitize all your pictures (by scanning them, for instance). If so, you can either decide to handle all your pictures the same way (as if they all originated as digital shots), or to keep the distinction between analog and digital (through the tray name convention, for instance), while flagging the analog trays as digital and creating a disk structre for them as well (so as to get the automatic link to the picture from the Slide page).
Also, the Tray ID length has now been made into a configuration variable defaulting to 4 (see Global Definitions File). When you first install the program, you have the ability to change this value to support your own naming convention. Please note, though, that the scripts provided for managing the on-disk tray structures (mkcdtray, publish and mvtray) hardcode my own naming convention and would need to be adapted to fit a different one.
This step may seem a bit pointless at first. When dealing with 36mm slide trays, the slot numbering would logically follow that of the physical tray slots, e.g. from 1 to 50, right? Quite so.
But what about photo albums (which may not be numbered at all), or digital pictures stored in directory structures, where any imaginable scheme is possible?
I don't have any generic answer to all this, I can only explain how I do it (or would do it, in the case of photo albums):
Once you know how to call them, you can start creating your tray record(s). Do this through the Slide Trays Edition Page.
One of the important parameters that you will have to give is that of size (the number of pictures your container -- whatever it is -- can hold). A Slide address will be built with the tray name that contains it followed by the 'slot' number on 2 positions. That slot would be the physical slot in a plastic slides holder, or the position (index) in a paper photo album (I guess you'd better number them by hand if they don't come pre-numbered), or a directory name in the case of the directory structure built for digital media (see section below).
The slot number is expected to be specified on 2 positions, so if your container holds more than 99 pictures, please use hex. to number the slots (this will be done automatically by the tray structure creation script, 'mkcdtray', in the case of digital slides).
Speaking about digital slides, you might think that the easiest way to handle this would be to have a single "tray" for all digital shots, and define it as holding millions of entries. I preferred not to implement it like this, because I also wanted to make it easy to backup each of these trays separately. So I typically stick with the amount of data I can fit on a CD media, and devide it by the average picture size (which will vary depending on your camera resolution and preferred file format). Of course, you can base your computations on DVD media instead of CDs -- I personally don't trust them for long-term storage (CDs are not eternal either, I know).
One last point: you have to give each Tray a name (it doesn't have to be unique, though). It could be as trivial as "White Album" or "Blue Album" for photographs. As for me, I group my slides in high-level categories like Architecture, Sculpture, Epigraphy etc., and I use that to name the trays.
If needed (as in the case of digital media or digitized analog ones), now would be the right time to create your tray structure on disk. To do this, use the helper script called 'mkcdtray' (see Helper Scripts for more details on how to use it). You should obviously specify the same size ('-s' parameter) to the script as you did when creating the Tray record above.
'mkcdtray' will create a top-level directory for your tray, and name it after it (e.g. 049X/). It will then create subdirectories, one for each slot, named after the tray followed by a 2-char. sequence number in hex. (so in this example, starting with 049X01/). These subdirectories should be used to store your digital slides, one each. If you have multiple files that all pertain to the same shot (for instance the RAW format and its JPEG export), you may store both files in the same "slot" (i.e. folder).
If you digitize old physical slides and want to keep your Hirtius data in synch with those plastic slide trays, you can also instruct 'mkcdtray' to use a decimal slot numbering convention, of course.
Please keep in mind that the top folder beneath which all your "trays" will be created needs be visible and published by the web server (or a web server -- it doesn't have to be the same as the one serving Project Hirtius). The URL corresponding to that top folder also needs to be defined in the Global Definitions File. Once done, Project Hirtius will automatically link your pictures from the Slides Edition Page, giving you direct access to them from your browser.
If it makes your life easier, you can also decide to first create all your on-disk tray structures inside a local work area on your PC, and only push them on your web server at the end of each update session. The script called 'publish' will help you do just that (see Helper Scripts for more details on how to use it).
A short reminder of the procedure to follow will be provided below.
At first, it may seem a bit silly to spend much time thinking about a numbering policy for the slides. They'll obviously just be numbered sequentially, right ? Well, that's true in most cases, but there are some situations that might require further thought:
I won't directly answer any of these questions, just give you broad guidelines. Please remember (as explained in the Slides Edition Page) that, for Slides objects, the slide_id field is not automatically generated by the database, but specified manually by the user. Meaning that you're free to adopt any numbering scheme you see fit. All slide numbers don't have to be consecutive. You could say, for instance, that user 'A' numbers his slides starting at 10000, and you number yours starting at 20000. Likewise, if you have to integrate two separate collections and the first one has at most 9999 entries, you could just add 10000 to each slide number in the second one, to avoid conflicts with the first one.
The only critical points are that, once you have decided on a specific numbering scheme, you (and all other users of the same Project Hirtius instance) should stick to it; and your numbering scheme, when coupled with your Tray naming convention, should enable you to quickly locate any picture as you're working with it.
You can now start to number your pictures. If we're talking about 36mm slides or color prints, it may be as trivial as writing their sequence number on the frame or on the back. These, I would expect, are already in suitable containers (plastic trays or photo albums), but if you need to reorganise them based on topic, now would be the time.
In the case of digital pictures, you should encode their sequence number in their name. I typically do this by renaming them at the same time as I copy them from their primary storage (in this case, the folder structure where I keep all the digital shots I take, including those of my family) to the Tray structure we created above (which could be a temporary work area). The name you give the file should simply be 'd' (to identify it as a Slide object), followed by the sequence number, then the format extension (e.g. d1234.jpg).
Specifically for digital pictures, while doing this moving and renaming
of the files, placing them in the Tray structure, you should write down
on a sheet of paper the slide number against its tray address (say
d1234.jpg = 059X4b). You will need this information for the next step
-- unless of course you prefer to proceed slide by slide, documenting them as
you place them in your trays, in which case you can dispense with the paper
trail.
You may follow this process for physical pictures as well, or you can base
your encoding on browsing your physical container (your photo album or slide
tray, for instance).
For digital slides, once you have renamed them and placed them in their assigned "slot" (the appropriate Tray structure subdirectory), you should call mkcdtray again on the same tray, but this time with the '-l' option. This will create (or re-create, as the case may be) a set of symbolic links from the root folder of the tray. Links that would resemble something like this:
pan@kermit:~/localweb/dias/059X> ll drwxr-xr-x 2 pan tcs 4096 2012-09-02 12:05 059X01 [...] lrwxrwxrwx 1 pan tcs 18 2012-12-01 18:04 d5371.jpg -> ./059X01/d5371.jpg [...]
The point of these symbolic links it to make it easier to browse your image collection once organised in Trays using a regular image viewer program like Gwenview (even when these trays are burned to CD-ROMs for backup). This step is optional, as Project Hirtius doesn't rely on these symlinks to grant you access to your pictures through its web interface.
If you decided to perform these operations in a temporary (local) work area, now would be a good time to push your data on the server. You can do this by calling the 'publish' script. In addition to copying a specified on-disk Tray structure on the server, 'publish' can also call a sub-script ('tray_gallery_gen') to generate a "photo gallery" for your Tray (whether it is already full or not).
Please keep in mind that if you proceed this way (relying on 'publish' to call 'tray_gallery_gen'), the Photo Gallery will be created only on the target webstore (that is, on the server and not in your local work area). If you would prefer to also have the Photo Gallery locally, you can call 'tray_gallery_gen' on the working area before calling 'publish' (in this case with the '-n' command-line parameter to prevent it from re-generating a Photo Gallery that already exists).
For more information, a whole section below is devoted to the topic of building a Photo Gallery for Hirtius.
With this list (or photo album / trays) in hand, you can now start creating the Slide records in Project Hirtius. For a detailed description of that process and all the fields on the page, please refer to the Slides Edition Page.
To access the new Slide creation form, you can either use the Add action link at the bottom of each page of the Slides List, or open the Slide Trays Edition Page for the containing Tray in 'view' mode and click Add next to the target slot for the Slide (the one you assigned it in the previous step).
There is one higer-level aspect you should pay attention to, though. For the values you will use in some fields, it may make sense to decide on some conventions and then stick to them. Here are some example:
If your pictures collection also includes epigraphy or paleography subjects, don't forget to populate the Reading, Transcription and, where appropriate, Translation fields (more on this topic below).
Once your Slide records have been initially created, you'll certainly want to document them further, using them to store the result of your research. You have a wide variety of fields and meta-data at your disposal to do this (Comment, Reading, Transcription, Translation, Bibliographical References, Source References, Events, Attachments, etc.)
Here as well, you may want to decide on some high-level conventions as to how you will structure this information (the purpose being mostly to help you retrieve it easily when needed, and to provide consistent reporting).
Some of the conventions you may wish to set at this level could be:
(N.B.: the two points above apply equally to Source objects -- for certain source types, at least.)
At the same time as you document your slides, you should also link them together (as well as with other, related objects) where applicable. There are several ways of doing this:
These links will really represent the backbone, the hidden structure of your research, as they will allow you to easily navigate your way through all your objects.
Clearly, these last two sections will be used iteratively over a time period that can be quite long. Depending on your approach, you might even say that this documentation process will never end, as you will constantly strive to refine it and update it.
If, at a later time, you see a need to group a whole list of slides into the same INXtree category (or the same set of categories), you can use the Index Categories Bulk Add Page to do so. As an example, you could use this approach to easily identify all the pictures you took during the same trip abroad based on the date range they were shot.
Here is the way you would proceed:
Please note: Once created in this way, these INXlink entries can be further managed from the affected slides or categories edition screens (the same way any other INXlink record can), but there is at present no way to remove them in bulk. Please also note that the same technique for bulk linking applies to all supported fully-fledged object types, not just Slides.
Once the Slide records have been created, and provided they refer to digital pictures, it may make sense to upload their EXIF data into the Project Hirtius database. The advantage is that it then becomes searchable like the rest.
Uploading this data is done via an external script called 'upload_exif'. Please refer to Helper Scripts for the technical details on how to use it.
This script is able to handle single files, so you can upload the EXIF data for each individual slide as soon as you have created its record in the database. But this may not be the most efficient way of doing it. You can also wait for your current Tray(s) to be full, and then upload the data for the entire tray in one go (this is how I prefer to do it, and I then add a comment to the Tray record to track the fact that it has already been processed).
The EXIF data is strictly R/O in the 'hirtius' database. Even the script won't upload the data for the same slide twice. If you need to re-upload (perhaps because the original data has been mofified in the digital picture file, or that file has been replaced), you need to specify the --wipe parameter: the existing EXIF records for the given slide will first be deleted and then re-created.
If you have not done so yet by using the 'publish' script (as discussed above), now may be a good time to create a Photo Gallery for each of your Trays. You can do so by calling the 'tray_gallery_gen' script. Please refer to Helper Scripts for the technical details on how to use it.
The resulting Photo Gallery will be composed of a HTML index page typically called '00gallery.html' located in the root folder of your Tray on-disk structure, and of a thumbnail image for each one of the Slides it contains, these thumbnails being located in a dedicated sub-folder typically called 'thumbs/'.
This script needs filesystem-level access to the images stored in your Trays (as it will read them to generate the thumbnails and extract some EXIF information from them), it obviously needs R/W access to the on-disk tray structure in order to be able to store those thumbnails in a new, dedicated sub-folder as well as the index file in the tray root, and it can benefit from an access to the Hirtius database in order to query the tray name.
Once created, this Photo Gallery will be accessible simply by browsing the webstore, but the Hirtius application will also refer to it (and to the related thumbnails) when present.
If you prefer to have a printed index to accompany your slides collection, or you're like me and you always carry around a full list of all your pictures when away on a photo expedition, now would be the right time to create those reports.
These are the currently available reports relevant to Slides objects:
More information about each of these reports is available on the Slide Trays Report Page and on the Slides Report Page.
See also:
Project Hirtius, © Les Ateliers du Héron, 2012.
Last updated: Wednesday, Jul. 3, 2024.
| HelpSet Table of Contents | Back to Project Home Page |