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?

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

Attached is the first shot at a patch that approximately output black only.

Hub

On Wed, 2008-07-23 at 04:10 +0100, Øyvind Kolås wrote:

On Mon, Jul 21, 2008 at 2:13 AM, Hubert Figuiere 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