RSS/Atom feed Twitter
Site is read-only, email is disabled
  1. Chat
  2. Useful links
  3. Polls

Featured content

Motion blur strange behavior

This discussion is connected to the gegl-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

2 of 3 messages available
Toggle history

Please log in to manage your subscriptions.
20121227073823.45c6e4ee@scr... 27 Dec 22:59
  Motion blur strange behavior Victor Oliveira 27 Dec 22:58
   Motion blur strange behavior Alexandre Prokoudine 28 Dec 08:36
Victor Oliveira
2012-12-27 22:58:29 UTC (almost 12 years ago)

Motion blur strange behavior

On Thu, Dec 27, 2012 at 1:38 AM, Pavel Roschin wrote:

Hello, I noticed two strange things in using gegl's motion blur:

1. Opencl and normal versions are different - try to use ImageMagick's compare

This is because the OpenCL path doesn't support the new abyss policies, so it just uses a (0,0,0,0) pixel outside the geglbuffer boundaries, while the "normal" version is probably using clamp.

2. I have to insert node "crop" because filter produces too big buffer (bigger than initial image)

I attached test images and source code.

I see too much bugs in filters, that must work with neighborhood pixels, it seems that this is due to complicated tile nature of gegl...

Yeah... it seems some of the filters are broken, I have to dig up what is the problem, probably some of the recent changes in GEGL.

And so, some tests:

1. OpenCL version of motion-blur: 1.0 s (GeForce GT 430, year 2012) 2. CPU version of motion-blur: >10 s (Pentium 4 3.0GHz, year 2003) 3. GIMP's old version motion blur: ~2 s (faster, much faster gegl's)

10x times faster. But my CPU significantly slower and older than GPU.

In this case I hope GIMP will keep his fast (even if 8bit-per-color) filters, sometimes speed is the main thing in image processing. Or may be GEGL will have faster operations for 8-bit data?

But that's the point of using the GPU! We can have good and awesome floating-point precision and speed :)

--
Pavel

Alexandre Prokoudine
2012-12-28 08:36:47 UTC (almost 12 years ago)

Motion blur strange behavior

On Fri, Dec 28, 2012 at 2:58 AM, Victor Oliveira wrote:

And so, some tests:

1. OpenCL version of motion-blur: 1.0 s (GeForce GT 430, year 2012) 2. CPU version of motion-blur: >10 s (Pentium 4 3.0GHz, year 2003) 3. GIMP's old version motion blur: ~2 s (faster, much faster gegl's)

10x times faster. But my CPU significantly slower and older than GPU.

In this case I hope GIMP will keep his fast (even if 8bit-per-color) filters, sometimes speed is the main thing in image processing. Or may be GEGL will have faster operations for 8-bit data?

But that's the point of using the GPU! We can have good and awesome floating-point precision and speed :)

Since your reply landed to my inbox before the original mail, how was CPU version measured?

Alexandre Prokoudine http://libregraphicsworld.org