2011/4/18 Paul Sbarra :

I've tried several times to email the list, but the messages never seem to go through.  Maybe this one will make it. I've implement a load operation to interface with libraw, created a bug report and attached patches.  For some reason I get missing symbols when trying to load the raw-load.so, but I don't get that when I use gcc to create a so that uses libraw.  I had to add -lgomp to the Libs line of libraw.pc.  Is that a gegl build system problem or a libraw bug? Paul

Sounds to me like a libraw bug, libraw.pc should contain the libs that libraw depends on.

Thanks for the patch, but could you also add an automatic test for it please? That way it becomes super-easy to verify that your patch works, and our nightly tests ensures severe regressions in GEGL code that your op depends on are detected early.

Instructions on how to add an automatic test for an op can be found here: http://gegl.org/development.html#_composition_tests

/ Martin

My GIMP Blog:
http://www.chromecode.com/
"Why GIMP 2.8 is not released yet"
_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

On 11-04-17 7:28 PM, Paul Sbarra wrote:

I've tried several times to email the list, but the messages never seem to go through. Maybe this one will make it.

I've implement a load operation to interface with libraw, created a bug reportand attached
patches. For some reason I get missing symbols when trying to load the raw-load.so, but I don't get that when I use gcc to create a so that uses libraw. I had to add -lgomp to the Libs line of libraw.pc. Is that a gegl build system problem or a libraw bug?

libraw being GPLv3, it is not gonna go well with GEGL that is LGPLv3. It will turn it to a GPLv3 package at runtime. I'd be careful of the headache this would cause.

Just sayin'

Hub

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.
http://libopenraw.freedesktop.org/wiki/ (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): http://git.gnome.org/browse/niepce/tree/src/ncr/image.cpp

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).

Cheers,

Hub

On 4/20/11, 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.

The list also mentions rawspeed :) I, sort of, put both there :)

I don't think using libraw gives us any additional functionality over what could be done with dcraw.

Really? :) How about libraries currently being faster due to all sorts of optimizations, like rawspeed being threaded and using SSE2?

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 think houz did a nice description before:

http://sourceforge.net/mailarchive/message.php?msg_id=26372766

This is a view from dt project, but it makes a perfect sense.

Alexandre Prokoudine http://libregraphicsworld.org