Issues with Photomatix 4.0 Beta and Lightroom 3

I live the bleeding edge when it comes to photography workflow. With the exception of my core asset management software, Lightroom, I’m quick to update plugins and other components as they become available, as long as I can roll back the changes.

Recently HDRsoft released the open beta for Photomatix 4.0 to the general public. The new manual ghosting adjustment and thumbnail previews of different  settings helped in the HDR workflow stage.

My environment is:

• Windows 7 64-bit
• Lightroom 3.2 64-bit
• Photomatix 4.0 Beta 9 64-bit

After going through some images, I ran into a case where things didn’t work as well as expected. As these new features are so good, I really didn’t want to roll back to the previous known working version.

Calling Dr. Watson

Yuck. After selecting the re-import option, Photomatix progressed along and…. died. A TIFF file was created in the directory where the Lightroom images were located, but it appears that the TIFF metadata was corrupted. Here’s the result of the bad file:

bash-3.2$ tiffinfo.exe *tif
TIFFReadDirectory: Warning, GAA_20100806_0055.tif: invalid TIFF directory; tags are not sorted in as
cending order.
GAA_20100806_0055.tif: Error fetching data for field "XMLPacket".
GAA_20100806_0055.tif: Error fetching data for field "RichTIFFIPTC".
TIFF Directory at offset 0x396d808 (60217352)
  Image Width: 3872 Image Length: 2592
  Resolution: 300, 300
  Bits/Sample: 16
  Compression Scheme: None
  Photometric Interpretation: RGB color
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 3
  Rows/Strip: 2592
  Planar Configuration: single image plane
  Model: NIKON D200
  ICC Profile:
, 560 bytes
  EXIFIFDOffset: 60234224
  GPSIFDOffset: 60234334
TIFFFetchDirectory: GAA_20100806_0055.tif: Can not read TIFF directory count.
TIFFReadCustomDirectory: GAA_20100806_0055.tif: Failed to read custom directory at offset 60234224.

While this is a “good” Photomatix generated file:

bash-3.2$ tiffinfo.exe GAA_20100806_0006.tif
TIFF Directory at offset 0x396fe12 (60227090)
  Image Width: 3872 Image Length: 2592
  Resolution: 240, 240
  Bits/Sample: 16
  Compression Scheme: None
  Photometric Interpretation: RGB color
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 3
  Rows/Strip: 2592
  Planar Configuration: single image plane
  Model: NIKON D200
  XMLPacket (XMP Metadata):
<?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?>
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 4.2-c020 1.124078, Tue Sep 11 2007 23:21
:40        ">
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about=""
xmlns:pmtm="http://www.hdrsoft.com/tone_mapping_settings">
<pmtm:Version>3.2</pmtm:Version>
<pmtm:Method>Details Enhancer</pmtm:Method>
...

After seeing that the XMP metadata wasn’t present, I thought back to some of the differences on the images I’d just taken. For some images, I’ll marry up GPS data to the RAW (in my case Nikon DNG) files, and I use Jeffrey Friedl’s excellent Geoencoding Support plugin. First thought is that it might be something to do with this metadata.

Wrangle That Data Hoss

Going under the assumption that the Photomatix Lightroom plugin which is also in beta may be at fault, I looked for the best option to control what metadata was sent to Photomatix. Of course, the best solution is, again, Jeffrey Friedl’s Metadata Wrangler plugin.

Using this, I was able to perform different levels of metadata export to Photomatix, with the following results:

• Default metadata – Photomatix crashed, resultant TIFF file corrupted
• Preserve only the basics – removes a lot of metadata including information such as the title and caption. Successfully re-imported into Lightroom, but with a TIFFReadDirectory warning from tiffinfo.
• Touch of privacy – Keeps most data, excludes edits. Photomatix crashed, resultant file corrupted.
• Touch of privacy (adjusted) – Success! Selecting the preset but removing the IPTC block worked (with TIFFReadDirectory warning). All values including EXIF GPS data were included.

At first glance it appears there is something up with IPTC data. However, the warnings about unsorted tags makes me think the re-import process is choking on some data, either unsupported data (GPS Shadow) or maybe an improperly escaped piece of XML data.

Summary

Hopefully if anyone else has issues with the beta of Photomatix and Lightroom this will be helpful. I’ve been sending HDRsoft bug reports on this issue. I’m not familiar with the API or process that Lightroom uses in the plugin architecture to deal with round-tripping images, but hopefully a solution is simply and forthcoming.

In the meantime I’ve created a new export for Photomatix that includes the Wrangler filter to remove the IPTC info. Chances are it’s not just IPTC, so I’ll adjust my new present named DangYouPhotoMatixBETA accordingly. If anyone has more info, please share or email!