The case of the missing camera name

Particularly observant readers may have noticed a bit of an issue with the information displayed below the photographs on this site. Since late April, a piece of moderately useful information stopped appearing for newly uploaded images, so it looked like this:

What? No camera?

What? No camera?

Yes, all the usual gory technical stuff is there, but it’s not revealing which camera was used. I did a bit of head-scratching at the time it started happening, but didn’t get very far. I wasn’t sure if it was WordPress oddness, as it happened around the time of an update, or Lightroom oddness, as it followed the appearance of Lightroom CC.

Well, I sort of forgot about it until today, when I did a bit of looking, and the first thing I found was a thread on the WordPress forums relating to the Exifography plugin I use to display the data. This clearly pointed the finger at Lightroom, which is doing something a bit odd with the Camera Manufacturer field in the EXIF data which stops WordPress (and apparently some other software) from recognising the contents of the Camera Model field, leading to the results above.  Apparently some people were getting odd bits of data rather than nothing at all.

Anyway, the work-around, until Adobe do something with Lightroom, is to omit the camera manufacturer field when exporting images. And how would you do that? Well, it’s plugin time – in this case Jeffrey Friedl’s Metadata Wrangler, which is yours for a free trial and a donation after that. It can do various things, including allowing you to select which metadata fields to include or exclude. I set it up to omit the camera manufacturer and did a quick test, which produced the result I was hoping for.  :bouncy:

But then there was the matter of the posts from late April up to today – I really wanted to fix those, but how was I going to do it? I needed to export the images again and replace the duff ones in each post. Well, that would be easy enough, but the original images are on the iMac, which I don’t have to hand.

I took a slightly lateral approach. I knew that most of the exported files would have been backed up by Crashplan, so I used the client on the MacBook to restore what looked like the right deleted files from the backup of the export folder on the iMac. This caught a very high proportion of them, only missing those that I’d deleted too quickly after exporting for Crashplan to catch them. I then imported those into Lightroom and exported them again, with the corrected metadata.

Now all I had to do was visit each affected post and confirm the image files needed. Hovering the cursor over the image reveals all in the status bar:

Pick a file...

Pick a file…

It was then a simple matter of editing the post, deleting the current image, inserting the new one and saving the change, leading to this:

That's better

That’s better

For the remaining ten or so posts, I used FTP to download the images from the uploads folder in WordPress (yes, I could have done that for all of them, but that would have been fiddlier, as I’d have had to select a load more files). A few more quick edits and normal service was resumed.

Wasn’t that fun?

Update: and it’s not the first time! I had a vague memory of a previous issue with Lightroom. Almost exactly two years ago, I reported that Adobe had fixed a similar issue – mind you, that time the problem didn’t get past the beta stage.