Home

Photo Archive Modernization

As part of the PhotoApp, it may be time to start thinking about modernizing the photo archive itself. When I started the photo archive in the late 1990s, the basic structure was of rolls of films that would have about 36 individual photos. The presentation was on a desktop computer with a keyboard and a mouse. Now in the digital age, photos are endless streams on an app, and the main presentational tool is scrolling.

The archive has evolved in the 25+ years, have features added to it. For instance, the image record has a “category,” a “quality,” and a “type” attribute, and those have vague definitions. Meaning is derived from the structure of the image and set IDs, as well as from special values like 9999 and 9998 for the year value. There is a “persons” field in the database but that field seems to be a copy of the personref table.

A modern approach to the archive would benefit from a create and a last update timestamp, allowing to show “newest photos.” Those do not exist, so they will have to be derived and possibly guessed.

Created and Last Updated

To populate the created and last updated fields, the EXIF information from the photos and the timestamps for the physical photo files can be used.

If the photo has an actual timestamp when it was taken, that one can be used. However, it will be necessary to guess at the time zone. The vast majority of photos will be in the Eastern time zone (EST or EDT), but there are going to be some that are different.

The sort value can help for digital photos. Sort values are based on the UTC timestamp for the photo.

In all cases, the timestamp of the original photo (jpg and/or raw format) is also checked. If the timestamp is before the EXIF timestamp, or if there is no reliable EXIF timestamp, the file timestamp will be used instead.

The last updated should reflect when the data was last updated, which we can’t determine anymore. So for the initial data conversion, it will be made equal to the created value. However, if there is an “edited” version of the photo, and that has a later timestamp than the created one, that timestamp can be used.

Authorization, Category, Year

The access to individual photos (and sets) is mostly through the category field. The problem with the category is that the list of categories is hard-coded. Categories are good, but they should be customized to the instance of the photo archive.

The main archive defaults the category to “new” and gives only the administrator access to new photos. “Private” is used for photos that should not be shared. “Special” is used for photos that people should not see by default, but can see if they select to see them.

The categories “Nicoline,” “kids,” “Theo,” “parents,” and “other” are not used for authorization, but to identify ownership (who took the photo), although some of that is also represented by the copyright field.

There are three special year values in use: 9996, 9998, and 9999:

  • 9999 is for the x* miscellaneous photos.
  • 9998 is for the d* and p* photos from my father.
  • 9996 is for the a* album photos.

In the redesign, one specific field should identify whether a particular user is allowed to see a photo or not. In the migration, this field would have three possible values: New, Regular, and Private. The configuration would default to New, and as part of processing the value would be changed to either Regular or Private.

Another field should give the true category. For the archive, this would have as possible values:

  • Regular
  • Nicoline
  • Ab Grivel
  • Frank
  • Mark
  • Photo Album
  • Document Scan
  • Miscellaneous