Marc,
On the iView forum (
http://forum.iview-multimedia.com/viewtopic.php?t=6896 ) I've been involved on a thread where someone wanted to select / sort images by some of the Exif data. It's possible to do this, but only if you use the List view and customize the display to show the required Exif data. I came up with an XSL file whereby you can export a catalogue to XML and it would create Custom Fields that hold the required Exif information. Create a new catalogue based on this and you have a way of organizing your images by, for example, ISO. This could affect how you process them e.g. different Noise Ninja profiles.
Ignoring the bug that iView has with importing XML it would be much better to use Catalogue Sets, as you're not limited to 16 custom fields (or 9 until the bug is fixed). Also if you have any existing custom fields - I have one to group panorama images together - the XSL doesn't work. I could develop an XSL file that creates Catalogue sets, but this is a bit more complicated to do - in the XML layout images are associated with a set and not a set with an image, so you’d need to parse the data many times. Worst of all anything done with XSL is rather retrospective, and screws up any workflow you may have!
Hence I was looking to see what ImageIngester can do. It almost does what I want! In fact it does it, just in an unfriendly way. Some of the Exif data items use codes to store the value. I think it would be useful to have a second macro for these items that contains a text value. For example the original poster of the iView thread (about 10 posts in!) wanted to identify images according to metering mode. Your {@exif.MeteringMode} works perfectly, but it returns a code of 1, 2 or 3 etc. Unless you know what these codes mean they have little value. If you had another macro e.g. {@exif.MeteringMode
Text} that returned
Average,
CentreWeightedAverage or
Spot etc then it would be of more use in a catalogue set. This would then match what iView and Bridge do i.e. they show a text value. Alternatively just show the text value with the existing macro.
My XSL method highlighted a difference between iView and the Exif standard. For LightSource, which is effectively a white balance, iView converted the code 9 into
Sunny. The Exif standard and Bridge show this as
Fine weather. It's only a standard if it's followed, so shame on you iView for using different text!
When I've been testing with these macros I naturally put all of them into a template to see what information I could get from my camera. As expected some of them returned no value. For example the ImageUniqueID macro is blank in my images. However if used in a catalogue set I get <rdf:li>Exif|ImageUniqueID|</rdf:li> in my sidecar. Ideally I'd like this line to not be there, as it has allocated my image to the second level set and not the third. This could cause problems in a multi camera environment if one provided a value and the other didn't. I'm not sure how you could get around this, as it would be very specific to catalogue sets i.e. if evaluated macro is null then ignore the instruction.
And finally I’ve found a bug! I’ve been editing my ImageIngester template files in an XML editor – I use either Stylus Studio or XMLSpy. To make sure I’ve not made a typo I check that the file is well formed, and I also make sure anything new I’ve typed is indented correctly - this is purely cosmetic for easier reading. The default templates you supply include several sections inside <rdf:description> tags. For example the first few lines of the default template are:
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="3.1.2-113">
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
   <rdf:Description rdf:about=""
      xmlns:Iptc4xmpCore="http://iptc.org/std/Iptc4xmpCore/1.0/xmlns/">
     <Iptc4xmpCore:CreatorContactInfo rdf:parseType="Resource">
When I have validated my file the text becomes:
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="3.1.2-113">
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <rdf:Description rdf:about="" xmlns:Iptc4xmpCore="http://iptc.org/std/Iptc4xmpCore/1.0/xmlns/">
      <Iptc4xmpCore:CreatorContactInfo rdf:parseType="Resource">
The only difference is that the opening <rdf:description> tag is now on a single line. The carriage return and excess white space has been removed.
When such a template is used for an ingestion the XMP files produced are corrupt, as they are badly formed. The namespace section is missing, including the closing
>. A sample of what I get is:
<rdf:Description rdf:about=""
<mediapro:CatalogSets>
<rdf:Bag>
The code you are using to handle the XML appears to not be robust enough to handle variations in white space. I'm a Windows XP SP2 user, in case it works on a Mac!
Many thanks for implementing thumbnails for Olympus ORF files. Along with the new selection methods a great product has just got a whole lot better.
Ian
Author
