Home Products Download Order Contacts


Subject: Re: OpenRAW article: "DNG is not the answer"!

nunatak, what is the contradiction between "being a totally self contained
format" and "it's processor side dependent"?

i've given this question some thought and will preface my response by stating it's really limited to my understanding of what is or isn't possible within the DNG format.

with that caveat in mind, the contradiction i see is a totally self contained format might have sufficient data to resolve anomalies (i.e. self heal), while a processor side dependency simply flags them. one contains a solution, the other signals that an external solution is required.

Whether a raw converter can support particular cameras becomes a matter
of how many of the DNG parameters it has been coded to support.

then i would ask, if an in-camera DNG is responsible for colo(u)r, why couldn't it also have algorithims embedded for sufficently unfolding it against a known standard? don't we already know which attributes are most relevant, and couldn't this be appropriately handeled inside the private maker tags?

perhaps i'm over simplifying, but I see this similar to what ICC profiles offer. they contain information to calibrate a particular device so that it is brought into a relatively known colo(u)r state. why couldn't a camera profile be designed to supply transformation matricies that also bring unknown cameras into a relatively known state?

processor side dependencies are one way of dealing with raw data. however they work best with raw processors that are sufficiently advantaged to recognize the sensor technology--and the sensor data. is this any different from what Nikon Capture does? are we simply displacing one format for another, or are we advocating a truly portable file format with self contained matricies that can bring the raw camera data into a relatively known state for all raw processors? aren't we advocating inter-vendor compatibility?

Just remember that ACR 2.4 supports more than 50 cameras via the DNG route
that it doesn't support via the native raw route.

i'm now curious if this is because ACR 2.4 was resourced to handle all currently known sensor technologies at the time -- or because it can transform unknown sensor technologies to a relatively known state? does the ACR 2.4 engine contain the code to anti-alias Modul-R files? what about new sensor technologies?

don't get me wrong, i'm totally in support of a portable raw format. yet without a stronger comprehension of the way DNG works, i sometimes find myself in the untenable position of advocating by way of blind faith. hence my question: is it possible for DNGs to be totally self contained?


View All Messages in adobe.digital.negative

OpenRAW article: "DNG is not the answer"! =>


Copyright 2006 WatermarkFactory.com. All Rights Reserved.