On 11-04-19 5:07 PM, Paul Sbarra wrote:

> Regarding the licensing I think we should look at this from a larger
> perspective.  I picked libraw from the todo list because it was there.  I
> don't think using libraw gives us any additional functionality over what
> could be done with dcraw.  operations/common/raw-load.c and
> operations/workshop/rawbayer-load.c already attempt to use dcraw and I don't
> think it caries the licensing problems.

dcraw isn't GPLv3. dcraw has a weird license, but it does not matter as 
the loader actually call the dcraw binary.
But libraw and Gegl will lead to have this disabled, with a good reason, 
by distro maintainers - speaking from experience.

> What's the longer-term strategy for supporting raw files?  The Darktable
> project is _really_ good at developing raw images (non-destructively).  It
> would be great if you could have that same functionality but also include
> the additional image processing capabilities that GIMP provides (blur,
> heal/clone, layers, etc).

I started a couple of years ago with a the openraw loader that use 
(libopenraw was started long before libraw or any of the other alternatives)

This combined with any demosaic op (there is one in gegl)
See as a practical example (using Geglmm):

> In order to have more control over the raw processing we should be working
> directly from the sensor data.  Most sensors use a bayer pattern that needs
> to be demosaiced (http://en.wikipedia.org/wiki/Demosaicing).  IMHO that
> algorithm should be just another operation inputing RGBG and putting out
> RGB.  How would this work with the use of babl?  The demosaic algorithm
> would perform the pixel format converstion, but that's what babl is supposed
> to do for us.  Even if you added an RGBG pixel format to babl how would it
> know how to find a gegl converter to get it to RGB.  I haven't looked at the
> babl code so maybe my limited understanding is off.

Unfortunately I haven't been able to contribute anything in the last two 
years and likely unable for a little while.

Of course, this does not represent any of the Gegl developers but rather 
what I planned on doing (and contributed to Gegl).


Gegl-developer mailing list

Reply via email to