Separate names with a comma.
Discussion in 'General Technical Discussion' started by Iliah, Apr 18, 2005.
Thanks Iliah for the info.
I think I read the article wrong. I didn't mean it to sound like it did. I was just going by what I interpreted in the article.
Sorry, but I do not see Nikon doing anything to Adobe. On the contrary, for quite some time already Adobe is promoting an idea that Nikon is "bad guys". That "crypting" wb accusation is just plain funny. No need to decrypt Nikon's wb records. It works in an absolutely different way.
I wish Adobe deals with the problems they have with protection of their own software...
Iliah, thanks, I totally agree with you. This is the second reference to "encryption" that I have seen Nikon accused of, but I know of, I think, 3 groups that have been successful in figuring this out, and it seems that 2 of those groups took quite some time. At least the DCRAW folks categorized it as "weak encryption" but I still have issues with the term "encryption" in this context. This "stuff" that Knoll is stating about the Legal aspects amazes me. If Adobe were not pushing DNG, and I sure don't want to be under the Adobe umbrella of control either, this might have some standing, but when a company pushing their own "standard" is the bunch doing the biggest complaining I just have to wonder.
Somehow Adobe was always able to work around this prior, with all sorts of cameras, but now that they are pushing DNG it has become a very big deal to them. Frankly, I'm not sure I trust any of them :wink:
Nikon provided decryption tool. It is Nikon Capture. If D2x file was saved through Nikon Capture, white balance was recorded in NEF in "regular"place, straight, and "unencrypted".
I guess it is not a big problem to set the camera to different colour temperatures, shoot something, and make a table - original wb field values vs. coefficients recorded back by Nikon Capture. I think this can be hardly called breaking the code.
Moreover, why would Nikon encrypt the settings in original files and decrypt them through Capture, allowing for such an easy decryption? Maybe it was not Nikon's intention to encrypt wb, and all the "issue" is a little hypertrophied?
Well for one, that requires Nikon's software in order to 'decrypt' the white balance. And once Nikon's software is booted, there is no reason to use anyone except Nikon's software to convert the NEF to something editable.
Or so the problem has been presented by TK from adobe. I don't have easy access to D2x NEF files, nor the tools and expertise to 'disassemble' the file's structure to see if the white balance is really encrypted or if it is merely presented in an unusual (for some reason) manner.
All the information in the file is 'encoded' that is, it's binary representations of physical parameters (mostly the brightness of light presented in the form of a value.) What's at stake here is the representation of a particular parameter, the user set or automatic values for the white balance of the camera. Is that data purposely obscured and being guarded by technological and legal means, or not?
This is related to another issue which may be a rumor. Is the white balance of the D2x (and future cameras I would suspect) applied to the linear gamma data prior to the recording of the NEF file? If so, doesn't that make it very difficult for any third party to work with the white balance of D2x NEFs?
The WB in raw D2X files is encrypted (as evidenced by Eric Hyman - the author of Bibble, and Thomas Knoll amongst others). Whilst very small companies such as Bibble who no doubt have very limited funds are not worth sueing (it would probably cost Nikon more to sue them than they could ever possibly recoup) I can understand Adobe's perspective - why risk getting tied down in what would be a very long and arduous law suit for just one file format. The click neutral tool in ACR 3.1 works very well, so provided you have at least a small area of neutral colour in the image you can adjust with one click. Otherwise you have to make your adjustment visually using the colour temp and tone sliders.
I also cannot understand all the fuss about product activation - it is extremely easy to use, it allows you to use it on two computers (eg home/office or office/laptop) and the new version in CS2 is even easier to use in that you can Photoshyop installed on say 4 computers with two copies activated. If you want to work on one of the other computers you simply deactivate on one of the computers thereby releasing one activation - which can then be activated on one of the other systems.
This is how software companies are dealing with software piracy and is becoming more and more widespread. Folk will argue that it doesn't make one iota of difference as a pirated crack will appear within weeks of its release - but ut does make a difference as the activation is not so much directed against private individuals - but more against the multi seat graphics companies who previously bought 1 copy of Photoshop and could have 10 or 20 employees using the same copy. These companies will be more reticent about installing dubious cracked copies which could well carry spyware or trojans etc within the code.
Don't we, as photographers, crack down on illegal use of our images - then we can hardly complain when the company that produces the software which we use to produce and enhance those images does the same. If you don't like it then you have one easy answer - go back to shooting raw trannies and don't use a digital workflow.
One can say that image itself is also encrypted, as one needs to crack Nikon's compression table to get the image out of compressed NEFs.
But Adobe seems to have no problem with that...
We made a series of experiments to get values of white balance - it was not cracking, but just experiments. Varying light colour temperature and making a table of input vs. output has nothing to do with cracking IMHO. It is similar to experiments one needs to plot an H&D curve.
My issue with Adobe activation is RAID level 1. If we have to use activation, it should be bullet-proof.
In D2x white balance consists of two parts - one is applied to raw data before conversion to digital; but the other one - white balance correction for the light out of the "daylight range" - is applied at the stage of converting RAW data to RGB.
I think that Nikon should stand firm.
Raw is not a standard yet as Adobe wishes it
NC will get a speed up.
We are using yesterdays computers on a tomorrows camera.
The future developments in Nikon and Canon Cameras will be largely in the raw.
Oh read this;
Nikon, as far as I can tell, is not even in the debate.
That said though, I do not want the camera manufacturers to be the only option for image conversion. That goes against the entire idea of a Raw format - the idea that these files act like latent images, and can be re-developed in new and different ways by alternative software is what makes them more valuable than JPEG or TIFF files.
Neither do I want a 'digital negative' format that is owned by a multi-company digital media conglomerate such as Adobe/Macromedia. Nikon could take the lead here in providing reasonable access to their technology by supporting a consortium of vendors that support the NEF format. While the NEF market is tiny compared to the market for Canon's Raw format, it is closer to a true digital negative, because less interpretation, ie. preprocessing, has traditionally been done by Nikon's camera innards.
The D2x's NEF file is a, granted small, step away from this position.
(PS: please forgive my spelling - the cow's down.)
By your logic, Adobe should not complain at all about Nikon's "encryption" -- if one can really call it that. Adobe's protecting their software w/ their activation scheme, so why shouldn't Nikon do some of their own protection as well?
Basically, Adobe's position sounds very hypocritical to say the least.
Personally, I think they should spend more time working on ACR to get better default results for the Nikon RAW files instead. The default colors -- even when ACR can see the WB setting on my D70 -- is appalling(!). Maybe they should just pay Iliah for the reverse engineering work that he did for RAWMagick/etc instead.
I tend to agree w/ your last post. And perhaps, that's exactly what Nikon is trying to do. Certainly, pushing for 3rd party developers to use their API for NEF conversion is a step in that direction although they need to do something about their communications efforts at minimum, if that's the direction they're headed. OTOH, they may just stay "closed" to the rest of the world given the way they appear to approach the business.
As for applying WB prior to recording the RAW data. There can be real benefits to doing that depending on what that involves. If they apply WB in the analog stage (and can do it cleanly), that's probably a very good thing for image quality. It would be something I asked about a long while ago back before Iliah was banned from DPR. And it would be similar to applying a color filter on your lens rather than doing it in PP.
Consider this. If you're shooting in very warm light (eg. tungsten) and record the data the same way regardless of WB, then you're gonna be wasting quite a few bits of your red channel doing so (unless you wanted the color biased look) or risk blowing out the red channel badly. You also won't be able to make good use of any in-camera noise suppression techniques that might be desireable before the RAW gets recorded.
As usual, you want the best compromise of all the available techniques, not merely choosing all or nothing of one or the other.
I have no problem with product activation whatsoever - I do have a problem with Nikon encrypting my data to make it difficult for other programs to read my files.
To my mind Nikon Capture does produce the best output from my files - but at a huge price, namely speed and stability. although it is reasonable when working with individual files it is a nightmare if you open more than three images and the Multi Image Window method is very buggy and crashes frequently.
Method used by Nikon to record white balance - why do you call it encryption?
Password: A secret series of characters that enables a user to access a file, computer, or program.
Key: A password needed to decipher encoded data
Encryption: A mathematical procedure for performing encryption on data. Through the use of an algorithm, information is made into meaningless cipher text and requires the use of a key to transform the data back into its original form.
Simply because I know absolutely nothing about coding - so I must be guided by those that do. When Eric (of Bibble) and others who do know what they are talking about (I presume) catagorically state that it is encrypted - then I have to take their word for it.
#1064 - You have an error in your SQL syntax;
I agree with you Paul. Encryption this ain't. 8)
Thank you Paul for leading me to the light
It would appear that there are various people who have an agenda here.
In a thread elsewhere, somebody quoted the relevent portion of the DMCA, and it doesn't explicitly limit itself to encryption, but rather uses a vague term like "protective measure" (don't remember the exact phrasing but it was something to that effect). While most people might agree that what Nikon has done does not meet the mathematical definition of encryption, I do think this area of the DMCA is vague enough to be cause for concern.
If Nikon is so innocent in all this, why don't they just release a statement clarifying their position and intent? To me, their silence on this matter speaks volumes.
About the SDK, that's a red herring and to me is further proof that Nikon is being underhanded here. From what I understand Thomas Knoll is not at all exaggerating when he calls the NEF SDK worthless; it apparenty is a "black box" that offers about as much flexibility as Nikon's NEF Plug-in for Photoshop. The notion that you can create a convertor with the same capabilities and flexiblity as Nikon Capture using the SDK is just not the case. The NEF SDK might be OK to add NEF viewing support to programs like iView, ACDSee, etc, but I think if you ask any of the authors of programs like ACR, Bibble, Raw Magick Light, or Capture One their opinion of the SDK you'd get pretty much the same answer.