From Electron Cloud
Revision as of 11:40, 12 January 2007 by Ecloud (Talk | contribs) (Problems to be solved)

Jump to: navigation, search

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.
  • Exif tags include an "orientation"; some cameras (including my Canon) can indicate whether the picture was shot in portrait mode. Unfortunately, many programs pay no attention to this tag, so sometimes when viewing you will see such an image rotated, but often you will not (the portrait-mode image is shown in landscape mode instead).

Note that all of these are open, unsolved problems. The first one is Canon's fault. The remaining is the result of a philosophical mistake - the lack of extended metadata in the filesystem, and tools to manipulate it. Apple showed us the way, more than 20 years ago, with the resource fork. Yet we still do not have an equivalent system in any modern OS. EACH date and time should be accessible via ls. The ORIGINAL date and time should remain the same even when the file is changed. And extra metadata (exposure, lens, camera model and so on) should be extended metadata stored on the filesystem, not in the file. But then there would have to be a cross-platform replacement for the FAT filesystem, which has extended metadata, and everyone would have to use it. It's not hard, just hasn't been done.

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" .

Unsolved problems

  • exiftool does not rename Canon .avi files successfully using these time/date rules.
$ exiftool mvi_0019.avi
ExifTool Version Number         : 6.17
File Name                       : mvi_0019.avi
File Size                       : 24 MB
File Modification Date/Time     : 2006:08:12 18:23:58
File Type                       : AVI
MIME Type                       : video/avi
Frame Rate                      : 30
Max Data Rate                   : 2272 kB/s
Frame Count                     : 402
Stream Count                    : 2
Image Width                     : 640
Image Height                    : 480
Stream Type                     : Audio
Codec                           :
Date/Time Original              : WED JUL 26 18:42:56 2006.
Software                        : CanonMVI02
Duration                        : 13.40s
Image Size                      : 640x480

$ exiftool  -d %Y%m%d-%H:%M:%S.%%e "-filename<DateTimeOriginal" -ext .avi *
$l
WED JUL 26 18:42:56 2006?*

The filename is not valid because the DateTimeOriginal is not in the right format, apparently.

  • There is no cross-platform method of doing drag-and-drop of files to a browser, to upload to an online album service, or printing service. What exists are hacks involving XUL (Mozilla-only), ActiveX (Explorer-only), and Java (only with signed applets, because it would be a security violation otherwise). Consequently getting images printed is usually a tedious one-at-a-time upload process.