[snip]

[snip]

Thomas Knoll told me that no camera of the last year and a half would
have needed a change to DNG, had DNG existed that long ago.

Typically, to support a new camera, it isn't the DNG specification that
needs to change. Instead, what has to happen is that something has to
write, into specified places in the DNG file, specific information
about the camera model. (In addition to the sensor data for the
photograph, of course!) Then the Raw processing software, ACR or
something else, can extract this specific information instead of having
built-in knowledge of the camera.

I believe it works like this. Suppose I launch a new camera tomorrow,
that writes Raw files with a BCP extension. I also release some
software to process those Raw files. The camera has some existing
sensor configuration, such as Bayer, or Fujifilm SR, or Sony 4-color,
or Foveon, and writes just the sensor data to the BCP file. My software
obviously knows what the sensor configuration is, and interprets the
sensor data accordingly. This also includes interpreting the sensor
values according to the colour temperature.

No other software has a clue how to interpret the sensor data. It won't
even know what the sensor configuration is, and that is obviously
vital, even before you worry about the colour temperature and other
things. All Raw processing software will there have to give up on this
BCP file format. Obviously, ACR 2.4 in Photoshop CS has to give up,
because its built-in tables don't cover this camera.

Now Adobe releases a new version of the DNG Converter that knows about
this camera. This DNG Converter writes the sensor data to the DNG file,
of course. And also writes fields that describe the sensor
configuration, and how to interpret the colour temperature, etc. So now
the DNG file is "self contained". Some fields provide the sensor data
for the photograph. Others identify how to interpret that data.
(Metadata).

Now, when ACR 2.4, or any other Raw processor that handles DNG, reads
that file, it doesn't need its own data to tell it how to interpret the
data for this camera. It just extracts that from the DNG file. It can
handle cameras it has never before come across, because the DNG file
itself tells it how to. (I think the DNG Converter writes colour
calibration fields for 2 colour tempertaures, one tungsten and the
other daylight, to the file. This enables ACR to do its white balance
handling).

I'm still hazy about some of the details. But what I've said above is
consistent with everything I've learned and tested so far. I have
converted D2X and 350D Raw files into DNG, and processed them in ACR
2.4 under CS. CS Browser shows thumbnails for the DNG files just as it
would any Raw files that it recognised, and ACR 2.4 can process them.
But it just shows place-holders for the original Raw files, and refuses
to open the latter because it doesn't recognise the format.

It is this concept of being "self contained", with the sensor data for
the image, plus metadata identifying how to interpret the sensor data,
that makes DNG very powerful. Someone could release a photo-editor
tomorrow that only accepted DNG, and it would be able to process all 77
cameras that the DNG Converter could handle. Someone could release a
new camera tomorrow that recorded DNG, and immediately all Raw
processors that handled DNG properly would support that camera. And in
decades to come, DNG processors will be able to handle old DNG files
that have images taken using cameras that no one knows about anymore.

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

I know, it is.  What data do you have, homeboy?

Ohhhhh, I dunno, in order to make a better black level estimate?

Well, maybe your code is making non-optimal estimates.  Oh my.  Oh me.

Your converter can make as many assumptions as it likes, of course.
Maybe you like guessing:  I like knowing.

Take your straw-men and shove 'em.  Now answer the question as posed:
if Canon software can render a better image than a DNG decoder, why use
the DNG decoder?

I am not assuming Canon is doing something:  _I KNOW THEY ARE_.
Remember the "data" that is "good for me"?

Canon's converters will do a better job becaues they have knowledge of
(a) their hardware, but more importantly, (b) specific information in
their CR2 files which directs superior handling of the raw image data.
SHOCK OF SHOCKS:  some of this information may not be encodable in the
DNG file!

What do you mean by "already works"?  How do you know the conversion
couldn't be better?  DNG does not keep all black pixels; it has a tag
that *may* report the difference for each horizontal and vertical black
line from the global blackpoint it writes to the file.

It isn't.

www.google.com:  define:abstract

Nikon (or whoever) has likely has something that is being dropped on
the floor when you convert to DNG.  This is the basic point (that is
apparently lost on too many people):  without specific support for all
features present in a camera, DNG is necessarily lossy.

Because no standard DNG reader will know what to do with it, why
bother?

Why should they?  Instead they can make a special reader which does
know what to do with the "PrivateData" ... but hey, wait a minute ...

The existence of "PrivateData" is the problem, not the lack or presence
of version numbering.

In short:

a) if no DNG standard reader can understand the "private" stuff, why
bother storing it at all?  In this case, DNG offers you nothing more
than what a TIFF file would.

b) if some DNG reader _can_ understand it, it must be a custom reader,
and thus one has just converted the "file format problem" into an
"application format problem".  If you have to keep track of reader X to
best deal with DNG's that come from camera X in order to get the most
out of the images, in what way would this be different from the current
situation?  In this case, DNG has given you nothing but an extra, lazy,
man in the middle that drops bits on the floor.

Note that in both cases the DNG (or OpenRAW or whatever) gives you
nothing.  Why, then, use it?