Subject: Re: OpenRAW article: "DNG is not the answer"!
"but by favouring processor-side dependencies, it sets the stage for shifting
the raw processor arms race from the best damn raw processing system ...
to the best damn DNG processing system."
What is the difference between "raw processing" and "DNG processing"? DNG is a raw file format that holds the original raw image data. If the Leica DMR Back output in some other format, the raw converter would still have to cater for the fact that it didn't have an AA filter. It doesn't matter whether a raw converter handles a Sony F828 via the original SRF or via DNG - it still needs code for a 4-colour CFA, with cyan/emerald. To handle a Fuji offset sensor, it still needs to do combine the values in unusual ways to output a rectilinear RGB array.
"i would like to see a totally self contained format which includes the
hooks and algorithims (or at least a referrant) to successfully process
what barry calls a "sensor's configurations"."
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? Some people with "minority" cameras want this, presumably because they are frustrated because few raw converters have written the algorithms for their cameras. But I think there are more people who FEAR that DNG is already doing this! They fear that it would stifle innovation, and they are probably right.
I think it is unwise to assume that either the camera manufacturer or Adobe know the best algorithms. (Does anyone? Not only is there rarely a consensus, but better algorithms appear year by year). 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. 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.
"thanks to the talents of the adobe engineering team, the ACR engine has
become so powerful, scalable, and adaptable..."
Yes, ACR is powerful, which is perhaps one reason it supports more cameras than most raw converters, (although fewer than dcraw). But the principle it works on isn't so different from the others. They all have some generalised algorithms that are then controlled by their own parameters. They presumably don't write separate code for the 4 Bayer-origins - they parameterise the demosaicing. Does it matter whether they get the Bayer-origin from the DNG parameter, or EXIF, or their own built-in data?
"my point was that if color was the responsibilty of the DNG maker, why
also not algorithims for anomolous "sensor configurations"? as an example
--the absence of an anti-aliasing filter."
Is there such a thing as "the" algorithm for aliasing, Moiré, etc? I suspect not. Raw Magick claim that it is a function of the demosaicing algorithm, and we know there isn't "the" demosaicing algorithm.
"if anomolous "sensor configurations" are not cost-effective to develop
except for the largest of entities--why can't this be the responsibility
of the DNG maker and embedded into the maker notes? wouldn't this take
the heat off of building a mega DNG processor that competes with the walmarts
of the developing world."
Once again - this is nothing to do with DNG! Lack of an AA filter has to be catered for whether DNG is in the path or not. Products presumably handle D70 raw image data, given the D70's weak AA filter, in the same way whether they read it from a NEF or a DNG.
If DNG writers want to put extra data into the DNG as guidance for DNG readers, there are various ways they can do so. Apart from Makernotes or DNGPrivateData, which are often used for special "private" information, information could be added as XMP metadata within some suitably-defined namespace. After all, that is how ACR handles its edits & settings, which are a bit like optional instructions to be read in future. These can supplement the description of the sensor characteristics.
For example, the standard parameters define the default crop, (which I guess is what "Recover Edges" overrides?) Then cropping in ACR adds XMP data to further crop. The colour matrices identify the sensor's colour space, and using the calibrate tab in ACR adds XMP data that further alters that. But few of the ACR settings & edits are really suitable for cross-product use. (Adobe haven't even got ACR & Lightroom synchronised yet). "Crop" and "align" perhaps, but few of the others. And that is a reflection of the problem - there typically isn't a "best" algorithm for many of the sensor characteristics. There is never a consensus that the camera manufacturers provide the best raw converters. (Leica don't even provide their own software for the DMR back - they ship PS Elements!)
But - was there typically a best developer for a film? Or just a range of different companies' attempts, for which photographers had their own preferences? After all, if there isn't even consensus on whether a camera has to have an AA filter, why should there be a consensus about how to cater for whatever it has? Photoshop proves to us that there are typically many ways to handle a given situation:
How many Photoshop users does it takes to change a light bulb?
one to change the lightbulb and 26 to tell him better or faster or more advanced ways of changing the lightbulb
View All Messages in adobe.digital.negative
OpenRAW article: "DNG is not the answer"! =>
Copyright © 2006 WatermarkFactory.com. All Rights Reserved.