Subject: Re: OpenRAW article: "DNG is not the answer"!
What is the difference between "raw processing" and "DNG processing"?
precisely. what is the difference? i need to believe it's more than a home team advantage. many are holding out for something more than rhetorical distinctions. don't get me wrong-- standardization is a critical step and DNG is a path to standardization. but somewhere in this discussion i've lost the meaning of inter-vendor compatability within an open and portable architecture. i'm hoping a good discussion/debate might return confidence in that meaning.
take your example of sony's F828. if sony embedded the algorithim to handle it's anomolous sensor configuration--inter-vendor compatability is served. any DNG processor would understand sony's sensor. the embedded code could be used to bring the sensor configuration into a common processing state. should the F828 be a mind-numbing advance in the marketplace--you can bet your boots there would be alternative solutions developed as options to override sony's default. but in my mind, these advanced alternatives are for the market to decide-- not the basic algorithim that is the entitlement inherent to every sony consumer. why should adobe, bibble, or rawshooter design a basic algorithim for anomolous sensor configurations when that's clearly the responsibility of the camera maker or the sensor manufacturer?
You appear to be saying that you want the raw converter to be told what
algorithms to use, instead of being free to choose its own?
eye don't see that as being mutually exclusive Barry. for instance, an advanced raw converter that uses alternative algorithims for processing Leica's no anti-alias filter might offer those in place of Leica's default method. a less advanced raw converter would default to the algorithim embedded by the original DNG converter--be it Leica's, Adobe's, or whomever. choice is good. one does not need to come at the cost of the other. :-)
I think it is unwise to assume that either the camera manufacturer or
Adobe know the best algorithms.
precisely--and a truly open portable architecture would be backward compatible to it's default, and forward compatible using an EDL (edit decision list.)
However, I think that if we want to be able to use "standard" algorithms
instead of having everyone write their own, this can be ADDED to a system
where there is a common raw format.
then we are in agreement? is DNG structured to accomodate such a design? currently it seems to me that it favours processor side dependencies.
One method is to use dcraw, although I think the typical product that
does this is not a full raw converter. Another proposal I've seen would
embed Java routines in each raw file. Or the camera manufacturer could
supply libraries to decode the raw image data, and I think Foveon do this,
as do (perhaps more comprehensively) those who supply SDKs.
clearly there are many pathways. but imo the key is a common, but totally self contained portable file format with an architecture that can handle EDL's, plug'n play, or swop algorithims. my premise is simple. i own the photo. therefore i prefer a portable method of owning my results, rather than depending on any one raw processor to supply that ownership.
Is there such a thing as "the" algorithm for aliasing, Moiré, etc?
eye don't know, but i don't see why not? if Leica wishes to sell cameras, they need to be accountable for their results. once again i need to ask--why should adobe, bibble, or rawshooter design a basic algorithim for anomolous sensor configurations when that's clearly the responsibility of the camera maker or the sensor manufacturer? by shifting it processor side, we get into a "standard format processor arms race" rather than a "better aliasing algorithim" race. the latter serves the consumer, the former the deveoloper. which would you prefer?
Once again - this is nothing to do with DNG!
but in my mind it does barry, because we as consumers-- who like to vote with our hard earned dollars and evangelical energies :-) -- wish to know whether the DNG format is designed to accomodate total self-containment and thereby inter-vendor compatability or whether it's designed to favour processor side dependencies and a DNG arms race. yes--there are Makernotes, DNGPrivateData, and XMP fields. are they robust enough to handle , algorithims, JS, referrants and other forms of guidance? is a DNG processor designed for an open architecture? if so why aren't these fields currently being used in this way? why does Leica only supply an anti-aliasing value and not an algorithim? that approach makes it processor side dependent. will this change with the introduction of the DNG SDK? can you answer these questions with any certainty? imo these concerns are best put to rest.
this is the time when critical decisions need to be made about the future, before we lock ourselves into poor choices down the road. if we don't have a full and open debate about what we want we eventually have those decisions made for us. we are at ground zero and what should those first critical precedents be? enquiring minds need to know ... :-)
View All Messages in adobe.digital.negative
OpenRAW article: "DNG is not the answer"! =>
Copyright © 2006 WatermarkFactory.com. All Rights Reserved.