Hello Øyvind, thanks for the reply.
On 17 April 2011 14:24, Øyvind Kolås <pip...@gimp.org> wrote:
> On my c2d 1.86ghz laptop I get 105s real 41s user with default settings.
> Setting GEGL_SWAP=RAM in the environment to turn off the disk swapping
> of tiles makes it run in 43s real 41s user.
I found GEGL_SWAP=RAM, but on my laptop the process wandered off into
swap death before finishing. Is there some way to limit mem use? I
only have 2gb.
> Loading a png into a tiled buffer as used by GeglBuffer is kind of
> bound to be slow, at the moment GEGL doesnt have a native TIFF loader,
You can work with tiled tiff straight from the file, but for sadly for
striped tiff (as 90%+ are, groan) you have to unpack the whole file
>> babl converts to linear float and back with exp() and log(). Using
>> lookup tables instead saves 12s.
> If the original PNG was 8bit, babl should have a valid fast path for
> using lookup tables converting it to 32bit linear. For most other
OK, interesting, I shall look at the callgrind output again.
>> The gegl unsharp operator is implemented as gblur/sub/mul/add. These
>> are all linear operations, so you can fold the maths into a single
>> convolution. Redoing unsharp as a separable convolution saves 1s.
> For smaller radiuses this is fine, for larger ones it is not, ideally
> GEGL would be doing what is optimal behind the users back.
Actually, it works for large radius as well. By separable convolution
I mean doing a 1xn pass then a nx1 pass. You can "bake" the
sub/mul/add into the coefficients you calculate in gblur.
> It is useful, but it would perhaps be even more useful to see similar
> results for a test where the loading/saving is taken out of the
> and measure raw image data crunching.
Yes, good point, it should be easy to instrument it for this kind of
test. I'll have a go.
Gimp-developer mailing list