Nikon NEF format

Archived from groups: rec.photo.digital (More info?)

"Vicki" <nonspam@nonsperm.com> writes:
> I have a web design client who is asking me to manage his digital
> photos, taken on the Nikon D100 and the Nikon D2X.
>
> A large number of the photos he submits to me are taken in the "NEF"
> format which are unreadable to me (Photoshop 7, PSP8, Fireworks MX).

NEF is Nikon's proprietary RAW format.

It can't be read by Photoshop 7 without the ACR plugin (which is no
longer available from Adobe). It can be read by the ACR included in
Photoshop CS and CS2. You may want to upgrade.

PSP9 has support for NEF files from the D100, but not (AFAIK) the D2X.

Don't know Fireworks MX.

If you're using Windows, there is also a very good free converter from
Pixmantec that handles NEF from both cameras - RawShooter essentials:
http://www.pixmantec.com/

Another popular processor for NEF is Bibble, from Bibble Labs.
http://www.bibblelabs.com/

> I found a lot of controversy on the internet as far as Nikon
> supplying or allowing 3rd party plugins for this software, but no
> resolution as to how these files can be handled. Should I ask my
> client to provide me with his original camera driver disks to
> install the supportive features on my computer, or must one purchase
> extra software from Nikon?

Nikon sells extra software to handle NEF files. It is called "Picture
Project" and opinions about it are mixed. My opinion is that it is
not very good compared to the three alternatives I mention above
(Photoshop CS2 ACR, RawShooter Essentials and Bibble).

I wouldn't upgrade to PS CS just for the ACR module, but there are a
lot of other good reasons to upgrade. Bibble has the best workflow.
And of course, the price of RawShooter Essentials is right.
--
- gisle hannemyr [ gisle{at}hannemyr.no - http://folk.uio.no/gisle/ ]
------------------------------------------------------------------------
Kodak DCS460, Canon Powershot G5, Olympus 2020Z
------------------------------------------------------------------------

Archived from groups: rec.photo.digital (More info?)

On 31 May 2005 07:15:23 +0200, in rec.photo.digital Gisle Hannemyr
<gisle+news@ifi.uio.no> wrote:
>Nikon sells extra software to handle NEF files. It is called "Picture
>Project" and opinions about it are mixed. My opinion is that it is
>not very good compared to the three alternatives I mention above
>(Photoshop CS2 ACR, RawShooter Essentials and Bibble).

Picture Project is included with the cameras. NikonView can be downloaded
from the Nikon Tech support sites. Either will install a rudimentary plugin
which will allow PS to open the NEFs albeit without much control over the
process. If you want to use PSP8 you need to use the PP plugin and not the
NV one.

Nikon also sells Capture with is their full control NEF conversion and
remote control software.
----------
Ed Ruf Lifetime AMA# 344007 (Usenet@EdwardG.Ruf.com)
See images taken with my CP-990/5700 & D70 at
http://edwardgruf.com/Digital_Phot [...] index.html

Archived from groups: rec.photo.digital (More info?)

Vicki wrote:
> Thanks to all of you for your helpful pointers.
>
> It seems like there are many generous souls who have written excellent
> utilities for the conversion of these NEF files. It certainly doesn't bode
> well for Nikon's credibility - or for any sense of "generosity" of the human
> spirit in terms of their protective and small-minded stance w.r.t. their
> hallowed "NEF" format.
>
> The Pixmantic RawShooter looks like an excellent little app - it has an
> absolutely wonderful interface; nice intuitive design. With regard to
> UFRAW, it doesn't seem clear as to whether this is purely a Gimp plugin, or
> whether there is a standalone Windows utility as well. I downloaded the
> compressed file, but there was no exectuable.
>
> thanks again for some excellent pointers and links...
>
> Vicki
>
>

As a Linux and Mac user I'm very happy with dcraw. It's free and you can
easily script it to convert whole folders full of .NEF's to JPEG. This
is what I use for web photo galleries and my personal archive which is
quickly growing out of all control. Luckily dcraw saves me the chore of
converting every file into something web-readable. The results of the
conversion are often even better (sharper) than what I get from Nikon
Capture 4.

Archived from groups: rec.photo.digital (More info?)

"Vicki" <nonspam@nonsperm.com> wrote:

> It certainly doesn't bode
>well for Nikon's credibility - or for any sense of "generosity" of the human
>spirit in terms of their protective and small-minded stance w.r.t. their
>hallowed "NEF" format.

On the contrary. The "encryption" issue is a tempest in a teapot
created off by Adobe that lasted about a week. In response Nikon
announced that they were releasing a free software toolkit available
for developers that need to access this data in programs like
photoshop.







Scott Peterson

--
It's not hard to meet expenses...
they're everywhere.

272/612

Archived from groups: rec.photo.digital (More info?)

"Scott Peterson" <scottp4.removethistoreply@mindspring.com> wrote in message
news:119t8d7hr2vr249@news.supernews.com...
> "Vicki" <nonspam@nonsperm.com> wrote:
>
>> It certainly doesn't bode
>>well for Nikon's credibility - or for any sense of "generosity" of the
>>human
>>spirit in terms of their protective and small-minded stance w.r.t. their
>>hallowed "NEF" format.
>
> On the contrary. The "encryption" issue is a tempest in a teapot
> created off by Adobe that lasted about a week. In response Nikon
> announced that they were releasing a free software toolkit available
> for developers that need to access this data in programs like
> photoshop.
>
>
> Scott Peterson

Actually, the software kit was available long before Adobe started the
fight. Still stupidity on both parts, though

Archived from groups: rec.photo.digital (More info?)

Scott Peterson wrote:
> "Vicki" <nonspam@nonsperm.com> wrote:
>
> > It certainly doesn't bode
> >well for Nikon's credibility - or for any sense of "generosity" of the human
> >spirit in terms of their protective and small-minded stance w.r.t. their
> >hallowed "NEF" format.
>
> On the contrary. The "encryption" issue is a tempest in a teapot
> created off by Adobe that lasted about a week. In response Nikon
> announced that they were releasing a free software toolkit available
> for developers that need to access this data in programs like
> photoshop.

The encryption issue started with Thomas Knoll explaining to Photoshop
users, in an Adobe forum, why Photoshop wouldn't attempt to decrypt the
D2X WB. Adobe, as a corporate body, didn't say anything. Adobe didn't
issue a press release, nor did they take part in the debates, as far as
I know.

Thomas's simple, factual, statement was then picked up by Nikon users,
and commentators of digital photography. It was Nikon's users who
generated all the heat. They are still doing so - it is lasting much
longer than a week! Have a look at the OpenRAW website. This was never
a matter of Nikon versus Adobe. It was/is always a matter of Nikon
versus Nikon-users.

The SDK just gives access to the equivalent of TIFF data, (colour
interpolated data), not the original sensor data. Hence useless for Raw
processing purposes.

There is only one reason for encrypting data like that. To coerce
people to use to use the software that can decrypt it. In other words,
to buy Nikon Capture. It was a lock-in, pure and simple. And Nikon's
users spoke, and continue to speak.

Nikon is probably at one extreme. At the opposite extreme is Leica,
which is releasing a digital back (DIGITAL-MODUL-R) on 15th June that
uses DNG as its Raw format. Hence, openly published, without
encryption. That is the future.

--
Barry Pearson
http://www.barry.pearson.name/photography/
http://www.birdsandanimals.info/

Archived from groups: rec.photo.digital (More info?)

Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote:

>No. The toolkit may be available at no charge ("gratis" ) to those who
>Nikon determines to be "bona fide software developers" who sign
>ridiculous agreements with Nikon, but it is not free in the sense of
>having freedom ("libre" ):
>
Haven't seen any comments on what Nikon is requiring for developers or
if it's ridiculous, or whatever. If you want to change 'free' to 'no
charge' that's fine with me, but they're certainly not going to be
under a GNU license so let's avoid philosophical issues.

>
>In particular the only way to write something like dcraw (which is
>distributed in a way that precludes using the Nikon toolkit) is to
>reverse engineer the Windows application. That in fact turns out to
>be possible with the D2X, but it is likely to become much more
>difficult with future cameras.

I understand it only works this time because Nikon used a fairly
trival encryption scheme. What if a firmware upgrade suddenly changed
this to a PGP level encryption? Better to have a documented
methodology for third party developers to follow in place to protect
the end user.

>This is a very serious issue and not a
>tempest in a teapot. The only cure is to publish the format so
>everyone can implement it, not make opaque toolkits available only
>t

That's not the only answer. In fact I can't think any major camera
manufacturer has done that. The closest is Leica committing to using
Adobe's DNG format directly, but how many thousand Nikons and Canons
are going to be sold for every Leica?

So let's look at the situation now. There are a number of companies
out there marketing products that process RAW files. Each one of
these has gone though the same process of having to crack the format
and then write a program to process the results. Right now, if Nikon
wants to change anything, they'll break every one of those programs
and have a lot of people mad at them.

One answer is to agree to a standard format like DNG, but camera
manufacturers have not been very receptive to that.

I think the better answer is to have a commitment from the camera
companies to do what Nikon has done and provide a tool like this one
that will transparently process the image and return the information
through a documented interface. Then, if Nikon wants to change
anything, all they have to do is distribute an updated toolkit to
everyone who has a copy, hopefully far enough in advance that when new
cameras come out, the toolkit has already been out for long enough to
gotten to everyone and it's a non-issue.

Certainly whatever the answer, not everyone is going to be happy.
Linux users, for example, as I'm sure Nikon won't support the platform
without a lot more demand and I don't have a good answer for that.
Fortunately Linux users (including me) are a fairly small segment of
the market.



Scott Peterson

--
Lead me not into temptation
(I can find the way myself).

266/612

Archived from groups: rec.photo.digital (More info?)

Scott Peterson wrote:
[snip]
> So let's look at the situation now. There are a number of companies
> out there marketing products that process RAW files. Each one of
> these has gone though the same process of having to crack the format
> and then write a program to process the results. Right now, if Nikon
> wants to change anything, they'll break every one of those programs
> and have a lot of people mad at them.
>
> One answer is to agree to a standard format like DNG, but camera
> manufacturers have not been very receptive to that.

Any camera manufacturer that wants to use encryption to coerce its
users to use its own software will not like DNG, which won't allow
that.

I suspect that the other manufacturers simply haven't thought it
through properly. What have they to lose if they offer DNG, either as
their native Raw format or as an option? If the next Canon wrote DNG,
and the corresponding upgrade of DPP read DNG from that camera, what
problems would that cause for Canon? (And they would get some good
publicity from it!)

> I think the better answer is to have a commitment from the camera
> companies to do what Nikon has done and provide a tool like this one
> that will transparently process the image and return the information
> through a documented interface. Then, if Nikon wants to change
> anything, all they have to do is distribute an updated toolkit to
> everyone who has a copy, hopefully far enough in advance that when new
> cameras come out, the toolkit has already been out for long enough to
> gotten to everyone and it's a non-issue.

First, why expect Nikon to make such a commitment, if they cannot be
expected to do the other sensible things? Here is an article by someone
who has lots of experience of trying to use SDKs. It shows what a poor
"solution" SDKs are to this problem. And this person wasn't even trying
to provide a full Raw processor:

http://www.openraw.org/comments/?id=1

Second, SDKs don't provide the right information. They don't give the
sensor data, enabling a Raw processor to use them. They do the colour
interpolation (de-mosaicing) internally, so you get about the
equivalent of TIFF from them. So photographers don't get a choice -
just Nikon's way.

> Certainly whatever the answer, not everyone is going to be happy.
> Linux users, for example, as I'm sure Nikon won't support the platform
> without a lot more demand and I don't have a good answer for that.
> Fortunately Linux users (including me) are a fairly small segment of
> the market.

Users of photographs, such as asset management systems, and magazines
such as National Geographic, will not be satisfied with less than a
common Raw format. Currently DNG is the only game in town. Anyone
wanting confidence that they will be able to read and process their Raw
files in decades time should also want a "self contained" common Raw
format that can be processed without sepcific knowledge of the camera
that took the picture, or access to that camera manufacturer's
software.

Camera manufacturers that intend to be cooperative with their users,
and with users of photographs, should use a common Raw format, and at
the moment that means DNG. Camera manufacturers that don't intend to be
cooperative can't really be trusted with an alternative either.

--
Barry Pearson
http://www.barry.pearson.name/photography/
http://www.birdsandanimals.info/

Archived from groups: rec.photo.digital (More info?)

"Barry Pearson" <news@childsupportanalysis.co.uk> wrote:

>
>First, why expect Nikon to make such a commitment, if they cannot be
>expected to do the other sensible things? Here is an article by someone
>who has lots of experience of trying to use SDKs. It shows what a poor
>"solution" SDKs are to this problem. And this person wasn't even trying
>to provide a full Raw processor:
>
>http://www.openraw.org/comments/?id=1

I can hear the frustration. Hopefully all involved will try to work
together to get around this kind of problem and, in fact, I think that
if Nikon doesn't do that, they will be cutting their own commercial
throats. Heck, I go back to the old DOS isn't done till Lotus won't
run days. Didn't like it then, don't like it now.


>
>Second, SDKs don't provide the right information. They don't give the
>sensor data, enabling a Raw processor to use them. They do the colour
>interpolation (de-mosaicing) internally, so you get about the
>equivalent of TIFF from them. So photographers don't get a choice -
>just Nikon's way.
>

Don't know, but I thought the whole point of the updated toolkit was
to provide developers access to this information.


>Camera manufacturers that intend to be cooperative with their users,
>and with users of photographs, should use a common Raw format, and at
>the moment that means DNG. Camera manufacturers that don't intend to be
>cooperative can't really be trusted with an alternative either.

Unforutnately, I think the last thing camera manufacturers agreed on
was lens in front, film in back.

Scott Peterson

--
Never test the depth of the water with both feet.

539/612

Archived from groups: rec.photo.digital (More info?)

Scott Peterson <scottp4.removethistoreply@mindspring.com> writes:
> >Yes, the correct methodology is for Nikon to document the file format
> >and stop using encryption, instead of pretending it owns the user's
> >pictures.
>
> Nikon has never said it owns the users pictures or taken any action
> that would imply that.It's a meaningless, inflamatory argument.

If they aren't pretending to own the data they should stop trying to
prevent me from doing what I want with my data.

> There are hundreds of companies that store data of all kinds in
> proprietary formats without being accused of wanting to own the data.

I'd be interested to hear if you can name a few other companies that
use encrypted file formats to prevent the user from accessing his own
data, but don't make any claim to owning the data themselves.

> >Kodak?
>
> OK....1. I really don't know. Where does Kodak rank among digital
> camera manufacturers anyway?

"Kodak takes number one sales spot in US"
http://www.dpreview.com/news/0505/ [...] ak_no1.asp

> ...and probably more importantly to this
> discussion, where do they rank among pros and amateurs who are the
> major users of raw files?

The Kodak DCS pro series for a long time were the top pro DSLR's, and
still are the best in some regards, but Nikon and Canon have certainly
overtaken them in sales volume. I don't know if Kodak's non-DSLR
offerings support RAW.

> >1) the current Nikon tool doesn't transparently process anything. Whatever
> >processing it does is opaque.
> I don't know anyone who has even seen the tool yet. Do you? ...or
> are you just speaking from predjudice?

It is clear that the SDK is a binary library that does secret
operations on the RAW file contents. That is opaque.

> FWIW, I mean transparently to
> the application program and that's exactly what the toolkit should do.

Ah, the humpty dumpty approach, where a word means what you want it to mean.

Transparent means the user can see what it is doing, which means its
operations aren't secret. It also means that the application can get
at the RAW file contents, that is, the sensor reading at each pixel
without any interpolation, color adjustment, sharpening, or anything
else. By every report I've heard, the SDK does not provide that.

Of course I haven't seen the actual SDK myself, since it's only
available to those willing to agree to Nikon's notions of what "bona
fide" software developers can do with it, i.e. more lack of
transparency.

> FWIW, Nikon has already announced that it will work with Microsoft to
> incorporate NEF into Windows XP and follow on products. I could not
> find anything in the announcement about it but hopefully that means
> full access to the encrypted data.

It means that Windows XP will be able to convert RAW files into TIFF,
JPG, etc. There's no indication at all that the SDK will provide
access to the raw sensor data. If it did, that would defeat the
encryption.

> >Fortunately for who? And how big a segment of the market do you think
> >Windows XP users will be in the year 2050?
>
> Bad choice of words on my part. I meant that a very small number of
> people are affected. I imageine that Nikon like any other practical
> vendor will support the OS's where there is sufficient demand. Right
> now there isn't.

If Nikon stops existing, then it will cease supporting *any* OS's
regardless of the demand level. There are no guarantees whatsoever
that Nikon will still exist in 2050.

> No. You're obsessed that a published format is the only possible
> answer. It's not. I want the applications and/or operating system to
> handle the matter without my getting involved. That requires
> cooperation between the various vendors and developers. If they do
> that, I don't have to worry about it.

Nonexistent vendors and developers can't cooperate to do anything.

Archived from groups: rec.photo.digital (More info?)

Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote:

>
>If they aren't pretending to own the data they should stop trying to
>prevent me from doing what I want with my data.
>
>> There are hundreds of companies that store data of all kinds in
>> proprietary formats without being accused of wanting to own the data.
>
>I'd be interested to hear if you can name a few other companies that
>use encrypted file formats to prevent the user from accessing his own
>data, but don't make any claim to owning the data themselves.
>

Note that I didn't restrict this to encrypted but to proprietary
storage methods, trying to mean that the data can only be accessed
using the access methods provided. As the web site you posted pointed
out there is a lot more to this than just the encrypted data. It
includes markers and oddball EXIF data and other things.

Quicken and MS Money both come to mind as great examples.

Quicken


>> >Kodak?
>>
>> OK....1. I really don't know. Where does Kodak rank among digital
>> camera manufacturers anyway?

>The Kodak DCS pro series for a long time were the top pro DSLR's, and
>still are the best in some regards, but Nikon and Canon have certainly
>overtaken them in sales volume. I don't know if Kodak's non-DSLR
>offerings support RAW.

The Kodak DSLR's have pretty much vanished. But it brings up another
good one, Fuji. Their RAW format is only available through their
program.


>
>It is clear that the SDK is a binary library that does secret
>operations on the RAW file contents. That is opaque.
>
Who cares as long as the picture and needed information comes out the
other end?

>> FWIW, I mean transparently to
>> the application program and that's exactly what the toolkit should do.
>
>Ah, the humpty dumpty approach, where a word means what you want it to mean.
>

Absolutely. No more, no less.


>Transparent means the user can see what it is doing, which means its
>operations aren't secret. It also means that the application can get
>at the RAW file contents, that is, the sensor reading at each pixel
>without any interpolation, color adjustment, sharpening, or anything
>else. By every report I've heard, the SDK does not provide that.
>

And that's where we disagree. But I really don't know that it's
certain exactly what it provides. I would certainly think that it's
in Nikon's best interest to provide the best possible picture to the
end user. I hope they are listening.


>If Nikon stops existing, then it will cease supporting *any* OS's
>regardless of the demand level. There are no guarantees whatsoever
>that Nikon will still exist in 2050.

....and there are no guarantees you will either. Of course, I've
actually run code written for DOS 1.1 on XP. None of the code from my
256k Mac will run under OSX, nor do I think any of the early Unix code
will run well under the current systems. Of course that's because the
processors no longer exist.


>
>Nonexistent vendors and developers can't cooperate to do anything.

If all you're going to do is argue that Nikon isn't going to exist,
I'd suggest you'd better move to a different platform where you can
get that assurance. I don't think the 50 year argument is any more
valid that a lot of the other stuff you use to make your point.

I'd be much more concerned with how the next couple of years work out.

Scott Peterson

--
Men are from earth.
Women are from earth.
Deal with it.

238/612

Archived from groups: rec.photo.digital (More info?)

Scott Peterson wrote:
> "Barry Pearson" <news@childsupportanalysis.co.uk> wrote:
>
> >But I have not seen a credible statement that the SDK does supply the
> >full sensor data, and the words used imply otherwise. Most people
> >advocating use of the SDK don't demonstrate that they even understand
> >the importance of obtaining the Raw sensor data. It would so easy for
> >Nikon to make a simply statement to clear this up, but instead they
> >obscure things.
>
> Just an afterthought but the only unavailable data is the white
> balance data which applies to the whole picture. Seems to me you
> should be able to use the SDK to retrieve that information and then
> retrieve the rest of the data any way you want to.

It is more complicated than that, and it differs depending on the
company:

Nikon: their view is that Raw files should only be accessed via either
their own applications such as Nikon Capture, or via the SDK. That
means they really want to be the only ones doing the Raw processing,
and other companies should be processing the equivalent of TIFF 6.0 or
JPEG. They don't publish the Raw formats, and encrypt the WB for the
D2X.

Dave Coffin & "smaller" Raw processing companies: they know how to
decrypt the WB, and the NEF format has been reverse-engineered, so they
just access what they need. They shouldn't have to go to any of this
trouble.

Adobe: they also know how to decrypt the WB, but Thomas Knoll says the
DMCA may be used against them if they try it, and Nikon haven't said
they won't do so. Use of an SDK in ACR is wrong from a software design
perspective, so they don't use it. Most experienced photographers
probably expect to fine-tune the WB themselves anyway.

Asset management & viewer packages: these find it painful to handle
SDKs. Partly from the same design perspective as Adobe, partly because
of poor support from the camera manufacturers.

Publishers of photographs: as they start to accept Raw images, they
want just the Raw files, and not have to take extra software to handle
them.

Heritage archivists: rather like a combination of "Asset management &
viewer packages" and "Publishers of photographs". But these will
probably need more formal standards.

Even if SDKs were supported properly, they would still the wrong way of
solving this class of problem. A common Raw format is the right way. We
have common editable-formats such as TIFF 6.0, and common final-form
formats such as JPEG, and the concept works well. Leica accept that,
and all the above types of company, except Nikon and other major camera
manufacturers, accept it.

--
Barry Pearson
http://www.barry.pearson.name/photography/
http://www.birdsandanimals.info/

Archived from groups: rec.photo.digital (More info?)

"Barry Pearson" <news@childsupportanalysis.co.uk> writes:

> Nikon: their view is that Raw files should only be accessed via
> either their own applications such as Nikon Capture, or via the
> SDK. That means they really want to be the only ones doing the Raw
> processing, and other companies should be processing the equivalent
> of TIFF 6.0 or JPEG. They don't publish the Raw formats, and encrypt
> the WB for the D2X.

And that means, even if you have the SDK, you are chained to windows
and will be dead once bill descides you need to upgrade to his latest
magot pile.

And example is the D30, the fiel format has never been documented, and
the Canon SW will not run on currently availabel versions of
windoze...

--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.

Archived from groups: rec.photo.digital (More info?)

prep@prep.synonet.com wrote:
> "Barry Pearson" <news@childsupportanalysis.co.uk> writes:
>
> > Nikon: their view is that Raw files should only be accessed via
> > either their own applications such as Nikon Capture, or via the
> > SDK. That means they really want to be the only ones doing the Raw
> > processing, and other companies should be processing the equivalent
> > of TIFF 6.0 or JPEG. They don't publish the Raw formats, and encrypt
> > the WB for the D2X.
>
> And that means, even if you have the SDK, you are chained to windows
> and will be dead once bill descides you need to upgrade to his latest
> magot pile.

As I've being saying in this thread, SDKs are the wrong way to go.
There are no ifs & buts & may-bes, they are the wrong way of trying to
solve access to Raw files.

The codec scheme being proposed for Longhorn doesn't pretend to be
proper access to the Raw data. It simply allows some "ordinary" actions
to be performed on the files at the operating system level. All you
will get from it is the RGB data, equivalent to TIFF 6.0, or less.

The only satisfactory solution will be a common Raw format. At the
moment, DNG is the only game in town.

> And example is the D30, the fiel format has never been documented, and
> the Canon SW will not run on currently availabel versions of
> windoze...

Hm! My reading is that the D30 is not supported by DPP, but is still
supported by older Canon software. I think there has been some
exaggeration here.

http://www.robgalbraith.com/bins/c [...] -6461-7395

Also, you can convert D30 Raw files to DNG, and so they will be
supported for a long time.

--
Barry Pearson
http://www.barry.pearson.name/photography/
http://www.birdsandanimals.info/

Archived from groups: rec.photo.digital (More info?)

Tom Scales wrote:
[snip]
> Actually, the software kit was available long before Adobe started
> the fight. Still stupidity on both parts, though

Nikon started the fight, by trying to screw its users and coerce them
to buy its software. The fight was always between Nikon and its users,
never between Nikon and Adobe.

The SDK doesn't provide access to the Raw sensor data, but instead to
the RGB, or TIFF-like, conversion. It was never a relevant solution to
this issue.

--
Barry Pearson
http://www.barry.pearson.name/photography/
http://www.birdsandanimals.info/

Archived from groups: rec.photo.digital (More info?)

prep@prep.synonet.com wrote:
> "Barry Pearson" <news@childsupportanalysis.co.uk> writes:
>
> > The only satisfactory solution will be a common Raw format. At
> > the moment, DNG is the only game in town.
>
> It is not the answer. Consider for a minute two identical cameras
> that differ in the colour filters used over the CCD. DNG has no
> way to convay this difference.

Why not? Surely that is at most a matter of colour calibration, and DNG
handles that with ease.

Adobe's DNG code already offically supports about 77 cameras, and
unofficially supports more. That limit is just what Adobe have
calibrated, not an inherent limit with DNG. Remember that DNG already
supports many Bayer cameras, plus Foveon sensors, Sony 4-colour
sensors, Fujifilm SR sensors, and probably lots of others. Any
particular DNG file can have 2 calibration values, for 2 different
colour temperatures, that help interpret the sensor values for that
camera model.

Surely a camera manufacturer could, if they chose, provide specific
colour calibration values for the actual camera concerned? Those values
in the DNG file would "correct" any deviations for that specific
camera. If my Pentax was naturally warmer than yours, the DNGs from
each camera would have different colour calibration, and both would
then yield identical results in identical conditions. If a camera
manufacturer wants to have very consistent results, this is surely the
way to get it?

(This colour calibration within the DNG file is how recent cameras such
as the D2X, 350D, D70s, etc, can be converted to DNG by the 3.1 DNG
Converter, and then be supported by ACR 2.4 under Photoshop CS, which
was coded long before those cameras existed. ACR 2.4 extracts what it
needs for camera calibration and white balance handling from the DNG
file, rather than having to have it built in).

--
Barry Pearson
http://www.barry.pearson.name/photography/
http://www.birdsandanimals.info/