From Electron Cloud
Jump to: navigation, search
(Current workarounds)
(Problems to be solved)
Line 1: Line 1:
 
==Problems to be solved==
 
==Problems to be solved==
* Current-model Canon cameras have gotten even more stupid than old ones regarding the naming of photos on the memory card.  My Powershot A50 would remember (via in-camera memory, apparently) how many pictures it has taken during its entire life, so, say, if aut_3902 was the last picture I took, and then I insert a different memory card, the next picture will still be aut_3903.  This is as it should be.  The SD300, however, always starts over from zero.  So you end up with a lot of img_0001.jpg, over and over and over again, every time you delete anything from the SD card.  It's otherwise a decent camera but this is really, really stupid of them.
+
* Current-model Canon cameras have gotten more stupid than old ones regarding the naming of photos on the memory card.  My Powershot A50 would remember (via in-camera memory, apparently) how many pictures it has taken during its entire life; so, say, if aut_3902 was the last picture I took, and then I insert a different memory card, the next picture will still be aut_3903.  This is as it should be.  The SD300, however, always starts over from zero.  So you end up with a lot of img_0001.jpg, over and over and over again, every time you delete anything from the SD card.  It's otherwise a decent camera but this is really, really stupid of them.
  
 
* The typical filesystem (on Linux or otherwise) doesn't go to any great effort to preserve the original date and time of a file.  E.g. in the past I'd copy my pictures like this:
 
* The typical filesystem (on Linux or otherwise) doesn't go to any great effort to preserve the original date and time of a file.  E.g. in the past I'd copy my pictures like this:

Revision as of 17:45, 12 August 2006

Problems to be solved

  • Current-model Canon cameras have gotten more stupid than old ones regarding the naming of photos on the memory card. My Powershot A50 would remember (via in-camera memory, apparently) how many pictures it has taken during its entire life; so, say, if aut_3902 was the last picture I took, and then I insert a different memory card, the next picture will still be aut_3903. This is as it should be. The SD300, however, always starts over from zero. So you end up with a lot of img_0001.jpg, over and over and over again, every time you delete anything from the SD card. It's otherwise a decent camera but this is really, really stupid of them.
  • The typical filesystem (on Linux or otherwise) doesn't go to any great effort to preserve the original date and time of a file. E.g. in the past I'd copy my pictures like this:
cd ~/pics
mkdir 200607-timbuktoo-trip-1
mount /mnt/sd0
cp -a /mnt/sd0/dcim/100canon/* 200607-timbuktoo-trip-1/
cp -a /mnt/sd0/dcim/101canon/* 200607-timbuktoo-trip-1/
...

so, initially, the files all have the correct dates and times, because -a preserves date, time, permission, and ownership. Now suppose I touch up a picture in Gimp and re-save it. The time and date are changed to when I did the touch-up. Linux filesystems don't preserve the original date and time at all. It continues to exist in the exif tags (as long as those are preserved during all the editing operations) but that is beside the point; if I do ls -lrt, they are listed in the wrong order.

  • ReiserFS v4 is still immature, and nobody has figured out how to finally absorb exif tags (and other kinds of metadata) into the filesystem itself, rather than keeping them inside the files. And basic tools like "ls" do not access the metadata inside the files. More advanced file managers (like Konqueror, or Explorer) do use them to an extent.

Current workarounds

I just discovered the quite useful ExifTool.

cd ~/pics/200607-timbuktoo-trip-1
exiftool -r  -d %Y%m%d-%H:%M:%S.%%e "-filename<CreateDate" -o . /mnt/sd0

This I can do repeatedly for each SD card that I used, and as long as the date and time on the camera were correct, I will get files of the form 20060721-11:50:12.jpg. Now that the Canon numbering is completely useless (due to endless repetition) I don't see any point in preserving it. And if I cannot preserve the date and time on the filesystem, at least I can preserve it by putting it in the name. If I want to rename a picture to something more descriptive, I can still just add descriptive text onto the end of the name. (But usually I don't bother.)

However there is a divide-by-zero bug in exiftool when $x_res and $y_res do not end up being defined (I guess these were exif tags it expected would always exist). I worked around it like this (edit /usr/lib/perl5/site_perl/5.8.6/Image/ExifTool/Exif.pm):

# calculate focal plane size in mm
$w *= $units / ($x_res > 0 && $x_res < 1000000 ? $x_res : 10142.86);
$h *= $units / ($y_res > 0 && $y_res < 1000000 ? $y_res : 10142.86);

The default value being the one my camera usually provides.

Now what if the date and time on the camera are not correct? exiftool can offset all of the dtimes by a fixed amount, but here it gets to be a pain, because it cannot fix all 3 dtimes, rename, and copy, all at the same time, apparently. So I have to copy the files, then fix the dtimes, then rename the files again. In the example, the date is off by 1 day and the minute is off by 1 minute.

exiftool -DateTimeOriginal -='0:0:1 0:1:0' .
exiftool -CreateDate-='0:0:1 0:1:0' .
exiftool -ModifyDate-='0:0:1 0:1:0' .
exiftool -d %Y%m%d-%H:%M:%S.%%e "-filename<CreateDate" .