GnomePlanet Stock Travel Photography

Register and login to use the Lightboxes and Client Area.

 

There are 0 registered members and 13 guests currently viewing the site.

Member Login

Not a member yet? Sign Up!

 

A password will be e-mailed to you.

Visit the GnomePlanet Stock Travel Photography Gallery for High-Res Stock Travel Photos, Travel Photographer Tutorials, Tips, and Resources  

Organising Your Photos

As the number of photographs that you take slowly increases, it is important that they are stored and referenced properly. It is no good trying to remember what you took, when and where. Photos of a particular subject may be scattered throughout your collection. When you have a need for that type of photo, you need to find it, and all ones like it, straight away. The secret to making the best use and the maximum return on your image collection depends on a reliable method of photo organisation that is easy to create, easy to update, and easy to retrieve from. This article suggests ways that this can be achieved. Of course every photographer is different, and what works for some people may not work for another, but if you follow the general guidelines that are laid out here, you should be able to refine my ideas to something that will fit your own style.

Organisation can be split into two areas: Storage and Referencing. Lets start with photo storage. These days, this means digital photo storage, and the best way to do this is on an internal or an external hard drive. There have been too many stories of burnable storage media failing at the critical time for us to regard CDs or DVDs as fully reliable. They can still be considered as an extra method of storage - you can never have too many copies of your photos - but the primary method of reliable storage should be the hard drive. Prices have been tumbling considerably in the last few years, and at the time of writing, an external USB hard drive with a 1 Terra-byte capacity can be purchased for 100 USD. One Terrabyte (1TB) means one trillion bytes, or one thousand giga-bytes. With the average size of a 12MP RAW file at, say, 15 Megabytes, this means that a 1TB drive can store about 67,000 images. Compare this with the 313 images that a DVD can hold, and the choice is obvious.

How many copies do we need? The more the better, but realistically, you should have at least 3 copies of all your original images. These copies should be physically located in different areas, to guard against accident or theft at one site. Name your storage media so that there is no confusion as to what is what: Master, Backup-1, Backup-2. This way there is no doubt as to which version can be relied upon. You make changes to the Master volume, then copy those changes to the Backups.

Originals. Working copies. Version 1c. Fullsize. Background. Selection. Alpha Channel. There may be many versions of the original images, so we need a scheme that can cope with all of these, plus future changes, without being too unwieldy from the outset. The scheme should keep similar files separate, yet quickly identify which version is which. To do this, I suggest a combination of folders and file suffixes. Folders will keep the files grouped together as required, and suffixes will identify which version is which.

I like to keep photos stored in a broad grouping depending on the trip that I took them on. The name used is not important. Within that folder, the individual photos are stored in daily folders. example of image file structure The screen grab on the right can illustrate this scheme. Note how folders less than 10 are named, for instance, '04' rather than '4' so that they are kept in the right order by Windows. This date structure is useful, as an address can easily be constructed automatically from the file date. A folder name such as 'Athens' or 'African Birds' is not so versatile. Again, none of these names are actually important, though. The key thing is that they suit me, and are laid out in a logical manner. Why are the names not important? Because they are referenced from my database, which is used to locate whatever I am looking for.

Before we move on to databases, I'd just like to talk about filenames, how useful they are, and whether you should stay with the ones that you have. Your camera will produce automatic filenames, and may give you the option of changing some of the letters or numbers in the name before you start taking photographs. My Nikons provide a 3-letter, 4-number filename, with the numbers incrementing from 0000 to 9999, and then back to 0000 again. I therefore alter the letters after every 10,000 photographs. It is important that whatever combination of letters and numbers that you use, you keep all filenames unique. One letter and 4 numbers would give you 260,000 possibilities. Adding a letter will increase the available combinations yet further. You could, of course, add a descriptive word to your filenames, such as 'Athens0001', though this will soon fill out your database and make the processing slower. Best to remain short and cryptic.

Might your filenames might tell other people about what you are doing? Potentially, they could give an indication of your 'failure rate': in other words, how often you take a photo that you decide is a 'keeper'. This is not the kind of information that I wish to share with others, so I don't leave my filenames unchanged. If, for whatever reason, you wish to rename your photos, there are a number of programs available that can do the job. I use one called 'FileRenamer', that you can find at the Sherrod Computers website. The Basic version is free to download and use. It is very versatile, will let you re-name or re-number files in a variety of different ways, and shows you a preview of what it is going to do before actually performing the rename function. Note that the re-naming process does not write over any of your precious photo data.

Dan Heller, one of the web's most respected columists on all matters relating to commercial photography and its representation on the internet, emphasises the importance of image naming when trying to get a high return in the Search Engine returns page. He insists that when designing a site for the best Search Engine Optimisation returns, images should have a descriptive filename that the Search Engines can identify, such as 'Athens_cat_in_street.jpg'. This is obviously a task that must be performed by hand, and would be quite time consuming to do on a site with 1000+ photos, but may well be worth considering. A database-driven website can still reference such a name as easily as it can 'AB0001.jpg', though the processing time and space required would be much greater.

I am sure that I do not need to emphasise the importance of keeping track of your photographs, and finding photographs that meet certain criteria in a hurry. Your business may rely on the speed and efficiency with which you can do this. Such tasks can really only be performed by a database, and I would encourage all photographers to start one as soon as possible. The idea of a database may be quite daunting to some, but this need not be the case at all. A simple list, consistently laid out, can afterwards be imported into a database package, can be combined with other data, and referenced in many ways. You may have suitable software already on your computer, as most Office program-suites include this functionality as standard. You can even use a simple text editor to start your list. The simplest way to start a database is to use a list of your existing photo filenames. A program such as 'Karens Directory Printer' will produce a list of all photos within a nest of folders, and you can then use a program such as CsvEd to put the list in a proper format. The 'CSV' in a CSV file stands for 'Comma-Separated Variable', in other words, a list where each item on a line is separated by a comma. Other separators can also be used: one that is unlikely to appear in your database entries, such as the Tab or Pipe character, is the best choice. Such CSV files can be opened in any Text Editor, or CsvEd, or easily imported to any database program at a later date.

What is a database? The word often worries or mystifies the newbie, but the basic concept of a database is very simple.

IDNameTypeColor
001PotatoTuberWhite
002CabbageBrassicaGreen
003BroccoliBrassicaGreen
004Broad BeanLegumeWhite

The table above shows a simple database of vegetables. Each row is a separate entry to the database, identified with a unique ID number, and each column contains information about each entry. The first line tells you what each column contains.

PhotoID;PhotoName;Date;Time;Country;City;Description;Keywords
001;DSC023;2011-07-16;08:12;England;York;Daffodils in front of city walls;flower,yellow,roman,building
002;DSC024;2011-07-16;08:12;England;York;Minster at sunset;church,christian,stonework,religion
003;DSC025;2011-08-01;England;Worsley;Boats on the Manchester Ship Canal;water,tug-boat,cargo

The table above shows a photographer's database, in CSV file format. Like the vegetable database, each entry has its own line. The columns use a semicolon separator, as the keyword column uses a comma to separate individual keywords within that column. Such a table can be composed in any Text Editor program, and if opened in CsvEd will display correctly. Later on, such a file can be imported to any full-feature database program, when it can be simply related with other tables in a 'relational database. The table that follows 'relates' to the initial photo table, and provides the geo-referenced coordinates for each photograph. The identical PhotoID for each entry links the two tables together.

PhotoID;Latitude;Longitude
001;N53.94993;W1.10458
002;N53.96839;W1.08747
003;N53.49835;W2.37781

An in-depth discussion on database design is beyond the scope of this article. You should do some further research on this, and spend time planning your photo-database layout before starting. You may also like to look at the structure of a more complex example: my own 'Photographer's World Database of Countries, States, and Cities'. Always keep copies of your work in its different stages as you progress, so that you can go back if a particular method proves un-fruitful. Be consistent in the layout that you chose, and try not to duplicate data. It is much easier to use a number of separate tables that you can later link together than to have one fat table with the same data repeated many times. CsvEd can be used to re-order columns, change the format, the separator, add auto ID numbers, change letter-case, search and replace, and many more functions.

Whilst on a subject of geo-referencing, I will mention the organising of those files as well. My Garmin chooses its own filenames, such as 20101231.gpx, based on date and so my general structure is based on this. I keep gpx files in a separate folder from the photographs, though they could just as easily go in the same one. There may also be a small text file with the photo folder that contains any notes relevant to the photo in that files, such as if the camera clock was noted to be out of sync with the satellite. I prefer not to update my clock in the middle of the day, causing a disparity between photos already taken, and those still to come. Easier to keep them all the same, then adjust the whole file later on, using a tool such as EXIFtool or RoboGEO. For further information on geo-referencing, see my geo-referencing tutorial.

Stock Photograph Search

Advanced Search Page

Latest Photos

Ciudad Sagrada de Los Quilmes, a pre-Inca community of the Diaguita peoples covered 30 hectares.Vans and cars on the car transporter carriage of the GSR Ghan train.
Interior of Uyuni Cathedral on Avenida Colon.Passengers from Ghan train collect luggage at Alice Springs railroad station.
Three saffron-clad Hindu Holy Men wait for alms in Juna Akhara festival tent.Ghan train camel logo and carriages at Alice Springs railway station.
View some of the latest images posted to GnomePlanet Travel Photography

Random Photo

Two young girls walk past the wooden columns in the Djuma Mosque.

Two young girls walk past the wooden columns in the Djuma Mosque..

free counters

Web design by gnomeplanet.com   ::   All images and pages on this site are © 2008 - 2024 and remain the property of gnomeplanet.com   ::   All rights reserved