Hubert Figuiere
Thu, 24 Jul 2008 08:15:45 -0700
On Wed, 2008-07-23 at 04:10 +0100, Øyvind Kolås wrote: > On Mon, Jul 21, 2008 at 2:13 AM, Hubert Figuiere <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I'm writing on RAW support for GEGL. I was wondering a few things: > > > > 1/ what is the best pixel format I should use for the CFA data. I chose > > "Y u16" because it is 16-bits (from 10 to 14 actually) and just the > > luminance. But it there something more suited? > > You could create additional new data types, that included the min/max > properties, that would still be 16bits wide but only use a limited > subset. Using u16 is probably a good route to take though. > Defining new additional formats would have to end up being a form of > fixed point perhaps calles something like f4.12 indicating a fixed > point format with with 12 bits allocated to values [0.0-1.0> OK so I was not off-chart. I'd rather stick to a standard u16 all the time, and carry over the white and the black values (min and max). There are plenty of reasons, including that some provide a Gamma LUT. > > 2/ how do I propagate metadata? I need to specify the CFA pattern, the > > min and max values and other things need for the proper interpolation. I > > have no idea how to do that from the GeglOperation > > At the moment there is no way to propagate such auxiliary information > with the buffer, the existing demosaicing operations in GEGL take the > bayer layout as a parameter. We could add some special non grayscale > format that encoded which bayer pattern the grayscale data is stored > according to, this wouldn't allow babl to do the conversion but it > would allow specifying information about how the format is encoded. > > An approach that might be better than abusing babl by extending it > with additional models would be allowing to register additional > dynamic data in new dynamically allocated babl formats. Such a > capability will probably be needed when integrating with a color > management system that allows use of for instance ICC profiles, using > for instance littlecms for conversions. The problem for RAW data is that it is required. A CFA is meaningless if you don't have the pattern associated. Also I need to carry the min-max, eventually a LUT, the cam to xyz matrix / WB etc, eventually even a color profile, etc (I probably miss some more, including rotation for Fuji-CCD). Today, I need to open the file twice, once in GEGL, once out of GEGL for the metadata, to build the processing pipeline.[1] And I will not hide it: my ultimate goal is that GEGL be the defacto framework to deal with RAW files with libopenraw as the base, and the processing done in GEGL. Hub [1] or do it differently _______________________________________________ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer