headers
Michael Schumacher | 1 May 2008 22:21
Picon
Picon
Gravatar

LGM 2008 - rooms are booked, all is well

Hi,

just wanted to let everyone know that the rooms are booked now (May 7th 
to May 13th; Joao: please contact me for 14th and 15th, I have asked for 
a single room as well but haven't booked it yet).

We're staying at http://www.nathansvilla.com/wroclaw.html in two nice 
and cozy 8-bed rooms (I did ask on IRC and everyone who did reply was ok 
with it :) ). The hostel itself does have some nice features, check out 
the web site.

I'll arrive at Wroclaw on the 7th at about 13:30, and plan to go 
directly to the hostel. My mobile number is available on request.

Looking forward to meet you there,
Michael

--

-- 
     GIMP > http://www.gimp.org      | IRC: irc://irc.gimp.org/gimp
     Wiki > http://wiki.gimp.org     | .de: http://gimpforum.de
Plug-ins > http://registry.gimp.org |
Permalink | Reply | 1 comment |
headers
David | 5 May 2008 02:31
Picon

GEGL compile problems

Hi,

trying to compile GEGL on my system (Debian/AMD64) yielded an error
during the generation of the example files (output from clones.txt):

babl-format.c:438 babl_format()
        babl_format("B'aG'aR'aA u8"): not found

This seems to indicate that the babl extension library "gegl-fixups.so"
wasn't found (not the best error message ;).
Digging through the codebase i found the following line
in babl/babl-extension.c:

#define BABL_PATH              LIBDIR BABL_DIR_SEPARATOR BABL_LIBRARY

The problem here is that on my system LIBDIR was not set to PREFIX/lib
which led to the extensions not being found.

Some additional info:
autoconf (GNU Autoconf) 2.61
automake (GNU automake) 1.9.6
command used to build: ./autogen.sh --prefix=/home/david/.local

I ended up defining LIBDIR by hand, after which gegl compiled happily.

hope this info is of use to somebody, David.
Permalink | Reply | 0 comments |
headers
Zhang Junbo | 13 May 2008 18:37
Picon

gdb messages

Hi,

I'm just starting to write my code for gegl, I spent the whole day to
debug but failed. My code(svn 2287) can be found on
http://svn.gnome.org/viewvc/gegl/branches/branch_zhangjb/ . Here is
some messages from gdb.

(gdb) > run
Starting program: /home/bear/GSoC2008/workspace/gegl/tests/frequency/gegl_test
[Thread debugging using libthread_db enabled]
[New Thread 0xb7f67940 (LWP 9228)]
[Switching to Thread 0xb7f67940 (LWP 9228)]

Breakpoint 1, main (argc=1, argv=0x0) at hello-world-fourier.c:34
34				gegl_node_process(display);
(gdb) > s 1910
1462	  pad = gegl_node_get_pad (node, pad_name);
(gdb) > s
1464	  if (pad &&
(gdb) > s
1478	}
(gdb) > s
gegl_node_set_operation_object (self=0x8060d90, operation=0x804f2c8)
    at gegl-node.c:1064
1064	    gegl_node_disconnect_sources (self);
(gdb) > s

Program received signal SIGSEGV, Segmentation fault.
0x45b3bc8e in ?? () from /usr/lib/libfftw3.so.3
(gdb)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sven Neumann | 14 May 2008 09:14
Picon

speeding up GEGL operations in GIMP

Hi,

currently the GEGL operations in GIMP are very slow. I have done some
basic profiling yesterday and it appears that the main problem is the
conversion from floating point to 8bit. Here is where the most time is
being spent. So it doesn't really make much sense to optimize the
operations in GIMP or the point filters in GEGL. We need to look at the
babl conversions first.

Here's an interesting paper that outlines how to do conversion from
linear light floating point image data to 8-bit sRGB using a relatively
small lookup table:

 http://mysite.verizon.net/spitzak/conversion/sketches_0265.pdf

That is exactly the conversion that the tile sink executes. It would
help us a lot if someone could implement this. The file
extensions/gimp-8bit.c would probably be the right place to put this
code. I am afraid I am not going to find time for this. Is anyone else
interested in working on this?

Sven
Permalink | Reply | 7 comments |
headers
Jan Heller | 14 May 2008 11:02
Picon
Favicon

Re: speeding up GEGL operations in GIMP

Hi Sven,
 I can give it a try. If I understand it correctly,
 gimp-8bit.c only implements u8->float conversions, which
 seem to be picked up by BABL correctly, so the problem lies
 in the float->u8 conversions that are computed by
 ReferenceFish. Is that correct?

 Regards, 
  Jan

On 09:14, Wed 14 May 08, Sven Neumann wrote:
> Hi,
> 
> currently the GEGL operations in GIMP are very slow. I have done some
> basic profiling yesterday and it appears that the main problem is the
> conversion from floating point to 8bit. Here is where the most time is
> being spent. So it doesn't really make much sense to optimize the
> operations in GIMP or the point filters in GEGL. We need to look at the
> babl conversions first.
> 
> Here's an interesting paper that outlines how to do conversion from
> linear light floating point image data to 8-bit sRGB using a relatively
> small lookup table:
> 
>  http://mysite.verizon.net/spitzak/conversion/sketches_0265.pdf
> 
> That is exactly the conversion that the tile sink executes. It would
> help us a lot if someone could implement this. The file
> extensions/gimp-8bit.c would probably be the right place to put this
> code. I am afraid I am not going to find time for this. Is anyone else
(Continue reading)

Permalink | Reply | 5 comments |
headers
Richard Kralovic | 14 May 2008 11:19
Picon

Re: speeding up GEGL operations in GIMP

Hello,

>  I can give it a try. If I understand it correctly,
>  gimp-8bit.c only implements u8->float conversions, which
>  seem to be picked up by BABL correctly, so the problem lies
>  in the float->u8 conversions that are computed by
>  ReferenceFish. Is that correct?

I just had a short look into the babl code; it looks like there is a
float->u8 conversion implemented using the 16bit lookup table in
extensions/gegl-fixups.c. In fact, it looks like the same algorithm as
described in the pdf paper. I do not have much time to look at it now, I
just noticed that the function gggl_float_to_index16 (line 130) is not
inlined, but I guess it should be. Could you try to check if that helps?

Greets
	Richard

> 
>  Regards, 
>   Jan
> 
> On 09:14, Wed 14 May 08, Sven Neumann wrote:
>> Hi,
>>
>> currently the GEGL operations in GIMP are very slow. I have done some
>> basic profiling yesterday and it appears that the main problem is the
>> conversion from floating point to 8bit. Here is where the most time is
>> being spent. So it doesn't really make much sense to optimize the
>> operations in GIMP or the point filters in GEGL. We need to look at the
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jan Heller | 14 May 2008 17:36
Picon
Favicon

Re: speeding up GEGL operations in GIMP

Hi,

On 11:19, Wed 14 May 08, Richard Kralovic wrote:
> I just had a short look into the babl code; it looks like there is a
> float->u8 conversion implemented using the 16bit lookup table in
> extensions/gegl-fixups.c. In fact, it looks like the same algorithm as
> described in the pdf paper. I do not have much time to look at it now, I
> just noticed that the function gggl_float_to_index16 (line 130) is not
> inlined, but I guess it should be. Could you try to check if that helps?

The gegl-fixups.c code deals with gamma corrected RGB u8
conversions, so the inlining would affect RGBA float -> R'G'B' u8 conversion.
However, after loading a jpeg file into gimp-2.5 and 
the using a color tool, conversions from RGB u8->RGBA float
and RGBA float -> RGB u8 are requested, that is non-gamma
corrected RGB u8. Is there a simple way how to make gimp
request conversions from/to R'G'B'u8 space?

> > On 09:14, Wed 14 May 08, Sven Neumann wrote:
> >> Hi,
> >>
> >> currently the GEGL operations in GIMP are very slow. I have done some
> >> basic profiling yesterday and it appears that the main problem is the
> >> conversion from floating point to 8bit. Here is where the most time is
> >> being spent. So it doesn't really make much sense to optimize the
> >> operations in GIMP or the point filters in GEGL. We need to look at the
> >> babl conversions first.

As you correctly pointed out on IRC, there is currently no
speedup code to conform to 0.0001 default BABL error
(Continue reading)

Permalink | Reply | 3 comments |
headers
Sven Neumann | 15 May 2008 10:06
Picon

Re: speeding up GEGL operations in GIMP

Hi,

On Wed, 2008-05-14 at 17:36 +0200, Jan Heller wrote:

> The gegl-fixups.c code deals with gamma corrected RGB u8
> conversions, so the inlining would affect RGBA float -> R'G'B' u8 conversion.
> However, after loading a jpeg file into gimp-2.5 and 
> the using a color tool, conversions from RGB u8->RGBA float
> and RGBA float -> RGB u8 are requested, that is non-gamma
> corrected RGB u8. Is there a simple way how to make gimp
> request conversions from/to R'G'B'u8 space?

Changing this in GIMP is not feasible. What needs to be done is to
implement shortcuts for the conversions that GIMP actually uses.
Eventually he gimp-8bit extension should provide shortcuts for both
gamma-corrected and linear 8bit <-> double conversions.

The lookup tables in gegl-fixups are rather large, btw. As pointed out
in the paper, a much smaller lookup table would be sufficient to cover
the range from 0.0 to 1.0. I guess that adding a clever range check and
reducing the size of the lookup tables would yield a performance
improvement due to better cache coherency.

Sven
Permalink | Reply | 2 comments |
headers
Sven Neumann | 15 May 2008 10:28
Picon

Re: speeding up GEGL operations in GIMP

Hi,

On Thu, 2008-05-15 at 10:06 +0200, Sven Neumann wrote:

> Eventually he gimp-8bit extension should provide shortcuts for both
> gamma-corrected and linear 8bit <-> double conversions.

8bit <-> float conversions, of course.

Sven
Permalink | Reply | 0 comments |
headers
Jan Heller | 16 May 2008 16:57
Picon
Favicon

Re: speeding up GEGL operations in GIMP

Hi,

On 10:06, Thu 15 May 08, Sven Neumann wrote:
> Changing this in GIMP is not feasible. What needs to be done is to
> implement shortcuts for the conversions that GIMP actually uses.
> Eventually he gimp-8bit extension should provide shortcuts for both
> gamma-corrected and linear 8bit <-> double conversions.

attached is a patch that adds RGBA float->RGB u8 conversion
using code already present in gggl-lies extension based on
lookup table. I can try to move the code to the gimp-8bit
extension, although I don't think there is a point to doing
so, since this would only introduce duplicity and whould
increase memory footprint of BABL. However, for this
conversion to be selected, BABL_ERROR must be set at
least to 0.0005.

> The lookup tables in gegl-fixups are rather large, btw. As pointed out
> in the paper, a much smaller lookup table would be sufficient to cover
> the range from 0.0 to 1.0. I guess that adding a clever range check and
> reducing the size of the lookup tables would yield a performance
> improvement due to better cache coherency.

The lookup tables for float->u8 conversions are rather quite
large and it is indeed possible to add a range check to size
them down. However this range check would have to be
present in the inner loop of a conversion, which would
rather slow things down. Further, it wouldn't IMHO improve cache
coherency much, since the pixels already are in the 0-1 range
most of the time meaning only approx. 2.5% of the lookup
(Continue reading)

Permalink | Reply | 0 comments |

Gmane