Go Back   Steve's Digicams Forums > Digital SLR and Interchangeable Lens Cameras > Nikon dSLR

Reply
 
Thread Tools Search this Thread
Old Sep 7, 2005, 4:25 PM   #1
Administrator
 
Join Date: Jun 2003
Location: Savannah, GA (USA)
Posts: 22,378
Default

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:

Quote:
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.


JimC is offline   Reply With Quote
Sponsored Links
Old Sep 8, 2005, 10:03 AM   #2
DBB
Senior Member
 
Join Date: Jan 2004
Posts: 2,483
Default

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
DBB is offline   Reply With Quote
Old Sep 8, 2005, 10:16 AM   #3
Administrator
 
Join Date: Jun 2003
Location: Savannah, GA (USA)
Posts: 22,378
Default

DBB wrote:
Quote:
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? :-)


JimC is offline   Reply With Quote
 
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off



All times are GMT -5. The time now is 3:34 AM.