Nikon View now supports XMP, and perhaps they just ignore IPTC data embedded in the IPTC file. CaptureNX does not (yet) support XMP (apparently), but may in the future. Perhaps they recognize IPTC in the NEF, still.

I try to get some answers from Nikon for weeks now, but to no avail. I would, for example, like to know if it is now "safe" to embed XMP inside the NEF. Because the new NikonView does it. But all my emails and postings on several forums on the net have been unanswered by Nikon. And since they have no official developer support forum or email, I'm a bit at a loss.

IMatch writes IPTC to NEF files in the same way for three years now. There was once a Capture version which could not read it, but Nikon fixed that problem within a couple of months.

I'm not sure what PhotoInfo does different than IMatch. IMatch writes IPTC according to the latest IIM IPTC standard, and complies to all the requested alignments and stuff. I regularly test IMatch and the IPTC data with all major applications, and I know that it works and that the info written by IMatch can be read and updated by these applications.

So far, Nikon View could always read the IPTC information embedded in NEF files by IMatch...

I made some experiments with NikonView NX and I found several problems.
All these are my findings from playing around with this software today, there is no much other documentation about this.

1. It ignores embedded IPTC data in NEF files.
Capture (NX) see this information, as does Photoshop CS/3.

2. If a NEF has a sidecar XMP file, Nikon View NX also ignores the information contained in this file.

3. Nikon View NX can read/write XMP data to/from NEF files only. There seem to be no option to use XMP sidecar files for reading/writing.

4. When I set IMatch to load/store XMP information in NEF files (embedded), it can see the information written by Nikon View NX, and View NX can see the information embedded by IMatch in the NEF file.

But this information is then not visible for any of the Adobe software products, or for Nikon Capture.

Also, Nikon View does not display all the XMP information correctly, e.g. the label color name is displayed correctly, but they map the wrong display icon (5 Cyan) on the image in the thumbnail View.

All this strikes me a bit as odd. Nikon View seems to support only XMP data embedded in NEF files. This is an undocumented method to store the data, and I could so far get no comment from Nikon about this.

Embedded XMP in NEF file is apparently supported only by Nikon View, but neither by Capture NX nor ny of the other software products I have tested.

To stay compatible with Adobe and others, IMatch will need to write XMP sidecar files for NEF files. But to make this data visible in Nikon View, it has to be embedded. But then changes are invisible for other applications who do not support the undocumented embedding of XMP in NEF files.

Hum. I'm not sure where Nikon is heading.

Ain't life grand?

I posted a notice about the issue on the d1scussion website. If any of the Nikon software people who lurk there answer, I'll let you know.

cheers,

cd

Hi, Chris

I'm a member of this list myself, so I will see the replies.

I've made some more experiments, and I now know that Capture NX (current release) does only read/write standard (what Adobe calls legacy) IPTC data in NEF. Like the Capture versions before. IMatch is fully compatible with that.

Nikon View NX writes IPTC and XMP, but both embedded. Data in external sidecar files is ignored.

I have enabled an experimental "embedded XMP for NEF / CR2" feature for the next service pack. This allows IMatch to store XMP data inside the NEF files, in the same way Nikon View NX does it. BUT this is (again) based on the current state of what Nikon software is doing, and by no means official or documented/supported by Nikon.

I tested this with about 50 NEF files from different cameras and it worked quite well. I was able to (somehow) damage a NEF file by constantly switching between Capture NS and View NX, doing meta data edits in both applications

IMatch can open and display the file still. Nikon View NX rejects the file as an unsupported format. Nikon Capture NX crashes and closes when trying to load the file.

As I'm certain you have seen, there has been no response to my inquiry on the d1cussion forums.

It's interesting that you were able to damage a file. I've seen some comments on dpreview that a new version of CaptureNX will be released when the D300/D3 hits the street. Maybe it will be fully compatible with ViewNX.

Thanks for your efforts

I'm sure Nikon will add the "embedded XMP" feature to Capture soon. Otherwise there will be no real workflow between View and Capture, because XMP can hold data which cannot be mapped to IPTC.

But, if your workflow also includes Adobe applications, you're at a loss. Photoshop, Brige, LR whatever do not work with embedded XMP data inside the NEF file (yet). They will continue to write the XMP file, so when you add meta data in LR, Capture will not see it, and vice versa.

Put perhaps Adobe will pull the old "white balance encrypted" trick again.
We all recall when Nikon started to encrypt the white balance information in NEF files, and what a huge buzz Adobe made about this. They let out press releases, complained everywhere until Nikon finally gave in. They released a new small developer toolkit which allows other applications to read the white balance stored in NEF files.

Hum, I really hope XMP will not end in the same "mess" we see with EXIF these days. I have seen so many variations of XMP already...

I got a response (if you want to call it that) from Google

"Hi Christopher,

Thanks for your note. We apologize for our delay in responding to your
mail. We've taken note of your request and we'll pass it along to our
developers. We appreciate your taking the time to send us these files and
suggestions for reading IPTC data. We strongly feel these types of
suggestions help us improve new versions of the program and we'll keep
your thoughts in mind for the future.

Regards,
The Google Team"

h'mmm, that's definitely clears things up!

Hi,

canned answer, unfortunately.
But I guess the Google team gets thousands of emails per week.

Anyway, if a Google developer looks into this, and contacts me, I'm sure we can sort this out.
Since relevant applications can read the IPTC records without problems, I reckon is not much that needs to be changed to make Picasa read the info.

An update to this problem: If I set the IPTC Caption in iMatch (3.6.0.52), it is not seen in Picasa (2.7). However, if I change an unrelated field in ACDSee 10 (such as the EXIF copyright field), then the IPTC Caption appears in Picasa. This implies to me that iMatch isn't closing something right (or something similar.) You should be able to reproduce this in other programs (Exifier, etc.)

Right now I can work around this by batch setting information on the pictures using ACDSee, which repairs my IPTC information. It's not really the workflow I was looking for, though.

-ken.

When you look at the image which fails in Picasa, can you see the IPTC information in ACDSee and Exifer? The problem here are not other programs which all happily see the data. Only Picasa fails. I know that a file that can be read by Exifer, ACDSee, Photoshop, LR, Bridge, IMatch and others fails only (!) in Picasa!

But nobody at Google seems to care enough to check for the problem, or let me know what specific thing they need. I would be happy to support. But Google has ignored my questions, and also the questions sent in by other users. They just don't care.