On Thu, Dec 27, 2012 at 1:38 AM, Pavel Roschin <roshin@xxxxxxxxxxxxxxx> 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 _______________________________________________ gegl-developer-list mailing list gegl-developer-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gegl-developer-list
