On 8/16/06, neota-s8PdfxpoPdHk1uMJSBkQmQ@public.gmane.org wrote:

I've compiled and installed GEGL and BABL, and I just tried to edit drop-shadow.xml,
replacing
with

to test colorspace conversion (test0.png is a 8bit greyscale image). I've tried giving test0.png alpha channel or removing the alpha channel, but in all cases this results:
(from running 'gegl drop-shadow.xml -o drop-shadow.png')

** (process:5857): WARNING **: color type mismatch

** (process:5857): WARNING **: calc have rect of data/test0.png failed

** (process:5857): WARNING **: color type mismatch

** (process:5857): WARNING **: GeglOpPlugIn-png_load is data/test0.png really a PNG file?
Segmentation fault

The only case in which it works correctly is if I convert test0.png to RGB. What is going on here?

The problem is that the png-load operator (gegl/opertaions/file-io/png-load.c) isn't written in a generic enough manner to handle anything but 8bit RGBA images. Ideally it should check what type of image is stored, and use it with the correct pixel format.

If someone sits down and rewrites the png loader to handle the pixel format correctly what you tried to do should work. The loader I used in gggl http://pippin.gimp.org/tmp/gggl-png-loader could probably be mostly reused, but in babl the pixel formats corresponding to the possible PNG pixel formats are:

"R'G'B'A u8" "R'G'B' u8"
"Y' u8"
"Y'A u8"
"R'G'B'A u16"
"R'G'B' u16"
"Y' u16"
"Y'A u16"

Rewriting the png loader to handle 16bit/component would also mean that the fallback mechanism using image magick (with the "load" operation) would be able to handle other 16bpc formats as well, right now the only way to get >8bit data into GEGL is using "raw-load" which is a dcraw wrapper.

/Øyvind K.