HOME


Digtal Photography

This page is old and pretty much obsolete, and I'd forgotten about it until I got an unsolicited email from "Morgan ... from Comparitech". I'd never heard of Morgan or Comparitech and assumed it was yet another SEO spam. It wasn't; the email linked to a page on their site called "EXIF metadata privacy: A picture is worth a thousand data points" which talked about the use of exif data in images posted online to reveal personal information about the pictures' subjects. Well worth a read, unlike most of the rest of this page!

— January 2022


I get the pictures from digicams (currently a Panasonic Lumix DMC-TZ20 compact; before that a DMC-TZ6, a Pentax K100D DSLR and various the old Canon compacts; and occasionally the camera built into my phone which I use if I've nothing else around) by putting the camera's memory card into a reader and using my getpix script.

This script was designed to locate and mount the device the card reader shows up on (e.g. /dev/sdc1 or whatever) but nowadays that part of the code is moribund and I mount the card manually (in kde, by responding 'open with file manager' to the dialogue that pops up when I plug in the card+card-reader combo) and run the script specifying the mount point with the --source /mount/point option e.g.:

getpix --source /media/9016-4EF8/

getpix then finds any and all files under the source directory and copies them to a directory with today's date in YYYYMMDD format as its name. This directory is inside a directory named with the year as 4 digits, within a directory ~/pix/, so if today is Xmas day 2010 pictures will be placed in ~/pix/2010/20101225/.)

The script renames each image file, transposing UPPER CASE to lower and prefixing the camera-generated filename with a date-and-timestamp derived from the image creation time in YYYYMMDD_hhmmss format, so an image file that appears as, say, DSCN1234.JPG on the card may end up at ~/pix/2010/20101225/20101225_102234_dscn1234.jpg. This uses Phil Harvey's ExifTool to access the images' EXIF data and rename the files.

Files not having exif Date/Time Original data will not be renamed with a timestamp prefix, except in the case of .avi movie files created by (some?) Canon cameras which, although they do not have an exif datestamp, are accompanied by thumbnail JPEGs of the same serial-numbered filename (i.e. img_nnnn) but with the extension .thm. When the script encounters one of these .thm files it looks for a corresponding .avi file in the destination directory and renames that with the timestamp derived from the exif data in the .thm. (This relies on the .avi file being copied from the card to the destination before the .thm is processed.)

I didn't always timestamp my digicam images so when I started doing this I needed a way to rename my existing collection to timestamped format. This is relatively easily done with a one-liner:

exiftool '-FileName<CreateDate' -d %Y%m%d_%H%M%S_%%f.%%e <dir>

which operates on just one directory - or to recurse down a specified directory tree just say:

find <dir> -type d -exec exiftool '-FileName<CreateDate' -d %Y%m%d_%H%M%S_%%f.%%e {} \;

(It would probably be better to use dateTimeOriginal rather than CreateDate)

Converting the names of Canon .avi files was not so easy and I resorted to writing a litle script tstampavi.

The getpix script also auto-rotates images according to their exif orientation tag.

For raw files (currently .nef, .pef, .cr2 & .dng) it calls a companion script raw2jpg , which uses Dave Griffin's dcraw converter for proprietary camera formats, with cjpeg (it could use ImageMagick's convert) to make a JPG copy of the raw file, and exiftool to copy the exif data from the raw file into the jpeg.

Once my digital pictures are uploaded to the PC it inevitably turns out that some are quite duff and I quickly delete the JPEGs of them. If the JPEGs were derived from raw files these remain, taking up space on my HDD, so to clean them up I run the script rmraworphans. (This only works for .PEF raw files.)

Occasionally the memory card gets mounted Read-only. Where this is not caused by the tiny write-protect switch on an SD card getting moved(!) it can be due to some sort of problem on the card's FAT filesystem. This typically results in kernel panic messages in /var/log/messages, and can be cured by running (as root)

fsck.vfat -a -v /dev/<memory-card-device>

e.g.

fsck.vfat -a -v /dev/memory_card_SD


HOME