[Recovered Thread: 67743]

[JimC]

For those of you that aren't aware of it, Nikon has provided Adobe with an SDK that has the ability to see the White Balance information in the .nef files from the D2Hs, D2X and D50.

If you don't know, Nikon decided to encrypt metatadata related to White Balance in .nef files from these models.

As a result of this encryption, Adobe ACR does not support the as shot White Balance from Nikon models with encrypted metadta (D2Hs, D2X, D50).

But, Thomas Knoll announced that ACR 3.2 will support the as shot WB (since Nikon decided to provide this functionality to allow Adobe to read the White Balance information, while still using their own Demosaic Algorithms for converting the files).

You can see his post about it here:

Thomas Knoll's post on Nikon SDK to read White Balance

I don't know if you need to register to see it or not (I'm already registered so I can read it fine).

Thomas Knoll Wrote:

What this means (so far) is that Nikon has added to their existing SDK (which performs the entire raw conversion as a black box) a new "mini-SDK", which has the sole function of reading the white balance parameters from a NEF file (while still allowing the host application to do its own raw conversion).

The upcoming Adobe Camera Raw 3.2 and DNG Converter 3.2 will use this Nikon "mini-SDK" to provide "as shot" white balance support for the Nikon D2X, D2Hs, and D50.

P.S.

Some Nikon usersseem to think we're back to where we started with this issue (prior to Nikon deciding to encrypt metadatarelatedto White Balance). But, I'd disagree.

Perhaps as far as Adobe ACR is concerned, we'll be back to where we started (since the next release will support White Balance information frommodels impacted by the Nikon's decision to encrypt metadata).

But, the data is still encrypted.

Not everyone wants to sign an agreement with Nikon to use their SDK (if their application for it is even accepted), and Nikon's SDK is not available for many operating systems.

Personally, I think the only reason to encrypt metadata in raw files is to stifle competition, which in the end, increases software costs for all.

So, I'm hoping Nikon will decide not to encrypt metadata in any future models.

[DBB]

My own impression is that far more than White Balance is not available in 3.1.

As best I can determine from your post, the only difference between ACR 3.1, and 3.2 will be the White Balance change.

This means very little in a practical sense unless you do batch processing.

Dave

[JimC]

DBB wrote:

My own impression is that far more than White Balance is not available in 3.1.

As best I can determine from your post, the only difference between ACR 3.1, and 3.2 will be the White Balance change.

This means very little in a practical sense unless you do batch processing.

Well, there are two issues going on here. One was the encryption of metadata related to White Balance by Nikon.

The other is the lack of documentation of the proprietary formats used. You often see maker notes that software manufacturers don't fully support. This data is not encrypted (in Nikon's case anyway). But, you still need to reverse engineer the format to determine what the values included represent, and many developers don't want to spend the time needed to do that part.

It's just too time consuming (taking lots of photos, examining the data to see what changed, in order to try and see what's being stored,and what the values represent).

That time spent reverse engineering formats adds costs to the software for all of us (even if using a different camera model where it's easier for a developer to interpret the data).

I guess more softwaremanufacturers could go with a pricing structure that requires you to pay for specific models supported, depending on the effort needed to add it to their package.

Wouldn't that be fun? :-)