June 15th – Nature Photography Day

For Nature Photography Day 2008, I made an NPD Flickr group and invited a bunch of people. The only rules were to a) post pictures taken on June 15th (thank you Flickr / EXIF) and b) about nature or destruction of nature. Unfortunately, I didn’t pay attention to the group as I should have. So a bunch of nature picture spammers (they post the same picture to dozens of groups) posted hundreds of rule violating photos to the group pool. A month later I closed posting to the group because the spammers wouldn’t likely stop of their own accord.

Anyway, I forgot about NPD until the day of. No one posted to the group of their own accord. Who remembers after a year? I cleaned out the photos not following the rules. Set calendar reminders a couple weeks in advance to publicize the group. Hoping NPD 2010 will go better.

I’m also considering bending the rules. Maybe close to June 15th is close enough. Something like anywhere in the range June 10th to 20th is close enough? What do you think?

Anyway, here are the pictures from the group:

Recovering Pictures

William borrowed my camera to go on his honeymoon. He also lost the photos with a poorly timed crash & drive reformat. So he wants to borrow the card and recover the data. Thankfully I have not used the camera since he returned it despite thinking I should.

Luckily I ran across A Computer Repair Utility Kit You Can Run From a Thumb Drive

I didn’t like the setup of Photorec as it runs through the command line. Navigating the tree was confusing at best. It did recover 1,166 photos / 3.62GB for me.

Not trusting a single method, I also tried Recuva. That worked a little better. It reported 1,395 files found. However, 177 were unrecoverable. Getting 1,218 pictures / 3.78GB back was 52 / 160MB better than Photorec. Though many of the “recovered” pictures just say: Invalid Image. Maybe they really are Raw?

While trying to use Restoration, it crashed the first time. Not sure why. It was fine the next time, though it only found 4 photos.

Filename: Photorec doesn’t restore files with anything like the original name. Recuva and Restoration do.

Meta Data: OSes and image editors know about the EXIF data in pictures. All the Photorec pictures have date taken. Most of the Recuva pictures do. Guess I could see if only 52 pictures are missing the EXIF? That might explain why Photorec lost some of them.

All in all, it was an fun experiment. I am not curious how these stack up against of the proprietary software? Why pay $40 when these are better?

Division Issue in YAPB

Problem PHP in Yet Another Photoblog causes “Warning: Division by zero in exifReader.inc on line 859” (the problem line is in bold):


  // More complicated way of expressing exposure time, so only use
  // this value if we don’t already have it from somewhere else.
  if ($this->ImageInfo[TAG_EXPOSURETIME] == 0){
    $sp = $this->ConvertAnyFormat($ValuePtr, $Format);
    // Temporary Workaround for divizion by zero problem
      if (!empty($sp[0])) {
        $this->ImageInfo[TAG_SHUTTERSPEED] = (1/exp($sp[0]*log(2)));
      } else {
        $this->ImageInfo[TAG_SHUTTERSPEED] = 0;


Looks like YAPB is attempting to create a value if one doesn’t exist for TAG_EXPOSURETIME by inventing a new value. In my problem picture, the exposure time is 0.003 seconds which != 0. So why is the ($this->ImageInfo[TAG_EXPOSURETIME] == 0) condition evaluated as true? 

Interestingly, just prior to this is some code dealing with TAG_EXPOSURETIME which seems to be affecting this. Changing the 0.5 to 0.0005 (less than my current value removes the problem.

  // Simplest way of expressing exposure time, so I trust it most.
  // (overwrite previously computd value if there is one)
  $tmp = $this->ConvertAnyFormat($ValuePtr, $Format);
  $this->ImageInfo[‘h’][“exposureTime”] = sprintf(“%6.4f s (%d/%d)”,(double)$tmp[0],$tmp[1][0],$tmp[1][1]);
  if ($tmp[0] <= 0.5){
    $this->ImageInfo[‘h’][“exposureTime”] .= sprintf(” (1/%d)”,(int)(0.5 + 1/$tmp[0]));


With this conditional, the exposure time is “0.003 s (1/400) (1/400)” without “0.003 s (1/400)”. Didn’t see a reason to have it twice, so I’ve dropped it.

Also, I figure it would be better to call ImageInfo[‘h’][“exposureTime”] instead of ImageInfo[TAG_EXPOSURETIME]. With this change, it seems to have resolved the issue for me.