[ptx] Adobe DNG format SDK

[JD Smith]

On Mon, 2006-04-24 at 14:53 -0700, Daniel M. German wrote:
> 
>  Kai-Uwe Behrmann twisted the bytes to say:
> 
>  Kai-Uwe> Am 24.04.06, 21:23 +0100 schrieb Bruno Postle:
>  >> Apparently 16bit integer data isn't considered 'HDR', most applications that
>  >> manipulate 16bit files just treat them as finer grained versions of 8bit data
>  >> - These tools will generally do the wrong thing with the 16bit linear data as
>  >> produced by dcraw (as they would with linear 8bit data).
> 
>  Kai-Uwe> You can specify a gamma for dcraw. The newer dcraw version has a good 
>  Kai-Uwe> white/blackpoint behaviour. Images look bright out of dcraw. Just 
>  Kai-Uwe> colour saturation has to been handled. 
> 
>  Kai-Uwe> regards
>  Kai-Uwe> Kai-Uwe Behrmann
> 
> Actually, this got me thinking. 
> 
> If I could use the RAW data in hugin, then I could apply the panorama
> transformations and RAW->whatever format is needed, so if I want very
> high res pictures HDR or low res JPGs then I flip a switch and voila.
> Thennn I don't have to create a different project for every resolution
> I need to generate.

We had a long discussion about the possibility of doing this on the
PanoTools list (actually in the context of stitching three exposures
into a 16bit "medium dynamic range" HDR image):

http://thread.gmane.org/gmane.comp.graphics.panotools/38135/

I too really like the concept of fully stitching and blending at 16bit
or higher, linear HDR images, and then applying the camera
curve/tonemapping/white balance/etc. later.  This would in principle
allow you to create a "panoramic digital negative", to be manipulated by
all the HDR tricks later on.  If a year later a better HDR local
tonemapping algorithm arrives, you could just run it on all your
"panoramic negatives" without starting all over.  

The general consensus was this was doable, but probably not a good idea,
since working in linear space has some undesirable properties (which I
could never get a good feeling for).  In principle, you could even edit
masks for Enblend, etc., all while in a linear HDR space.  The only
thing it would require is a display setting of gamma=1, so you could see
anything, and I don't believe Hugin currently respects any embedded
curve or gamma information.  You'd also need to run autopano-* on an
8bit version of the files (any chance of incorporating autopano-sift
algorithms directly into the Hugin codebase to work on arbitrary typed
image data?).

JD