Separate names with a comma.
Discussion in 'Nikon DX DSLR Forum' started by Iliah, Jul 1, 2005.
For some reason when you embed images from pochtar.com they never show up for me. Since all I can see is a little red X can you explain a little bit what you're referring to?
Shows fine here Iliah..
Interesting file dump.. Wish I could remember all that stuff from over 35 years ago :>)))
You circled the number at the bottom right. Could you expand a bit more.
He seems to be indicating that ACR saw a temperature of 3800, but the file stored 10000? Which seems an odd number. Also, if the WB is encrypted, a hex editor will not display it.
Not sure what he is viewing the file with there. A hex editor?
In any case, I am finding the lastest ACR does not read Nikon's WB. It appears to guess it. I see completely different results between ACR and NC in virtually every NEF I have tried on both.
Yup, it still has that problem even with ACR 3.1. I'm learning to use NC 4.3 and i'm finding decent results from that. You could add NikonView in your workflow and port the NEF from NV to CS2 which should correctly adjust the picture to where CS2 should see it accurately. I haven't tried it, after this post i'll go and try it myself.
I am having a look at the open source code called "dcraw." This RAW decoding code is used in many apps - including ACDSee, Picasa, etc.
And the fella that wrote it figured out Nikon's WB encryption months ago. He even goes so far as to state that lots of other RAW meta data is encrypted. Doesn't seem to see why the rest of us are making a fuss. I guess because Adobe decided to make some racket.
Anyway, I am thinking about using that source to create a simple app that very quickly tells me the stored WB information for a given file. One could then use that in ACR.
Trouble is, I am finding that ACR's demosaic isn't as good as NC's. Certainly for tough detail like dark hair with highlights.
Comon Nikon, make NC better. And spruce up your CS RAW plugin while you are at it...
Camera was manually set to different colour temperatures, ranging from 2500 to 10000K. In all cases the colour temperature was recorded by the camera as plain text in NEF files (yes, what you see is dump, program called FAR, pressed F3 key) - in the tag 0x5. In all cases ACR completely ignored that value, substituting with its "auto"-determined one. The real colour temperature was 5700K, btw - so the guess of 3800 ACR made is completely off base, and the colours are all wrong.
In the same group of data camera recorded sensor assembly serial number (tag 0x1d), also as plain text. ACR recognized that number, passed to Photoshop, and Photoshop was showing it in File Info. This looks to me like ACR is going down the route of intentionally crippling D2X support.
Iliah, you should post this in the Photoshop forum on the Adobe website and see what they have to say. If your assumption is correct, i'm sure this is going to startup a flury of discussions which Adobe will eventually have to address. I don't know what would be gained by them doing this except getting back at Nikon and trying to drive their DNG standard which might be the play.
It would be interesting to see what kind of BS statement they would make as a response to what you've found.
We made sure that Adobe is informed. Frankly, I'm not much interested in why they did that, but rather in fixing the issue.
Just out of curiosity, did you do a conversion with any other dcraw based tools, or even dcraw itself? I'd be interested to see what WB any of the others manage to come up with.
dcraw will provide the values in this case.
Please consider disabling your ad blocker for our website.
We rely on ad revenue to pay for image hosting and to keep the site speedy.
Or subscribe for $5 per year to remove all ads and support our efforts.