Created attachment 125813 [details] [review]
adds gegl-sampler-nohalo.* and inserts references in gegl-sampler.c, gegl-buffer.* and gegl-buffer-access.c, and patches gegl-sampler-yafr.* and gegl-sampler-linear.c. 

I'll triple check tonight that this does not introduce bugs and post and "all clear" message when I'm done.

I appear to have forgotten to apply the patch to gegl-sampler-linear.c (which, in its current version, actually runs more slowly than the brand new nohalo). Will fix ASAP.

Created attachment 125817 [details] [review]
fixed patch which adds gegl-sampler-nohalo.* and inserts references in gegl-sampler.c, gegl-buffer.* and gegl-buffer-access.c, and patches gegl-sampler-yafr.* and gegl-sampler-linear.c.

Quick and dirty timings (resizing four images through xml script):

Linear before patch:

7.266 + 8.947 + 0.969 + 44.793 = 61.975s

Linear after patch:

7.041 + 8.911 + 0.900 + 44.364 = 61.216s

For comparison:

With nohalo:

6.925 + 8.965 + 0.898 + 44.215 = 61.003s

With yafr:

8.103 + 10.061 + 1.003 + 49.839 = 69.006s

(Bicubic and Lanczos are even slower.)

The fact that nohalo is still the fastest suggests that I could still
speed linear up, because nohalo (even at this lowest quality level) is a considerably more complex method. But I have
other "cats to whip" (pardon my French) for now.

Nicolas Robidoux
Universite Laurentienne

Apparently, I did not add bugs, so this is a "go."

Nicolas Robidoux
Laurentian University

I need to double check again.

n

Ahrgh! Forgot to fix what creates the makefiles so it knows about nohalo!

Manana!

Created attachment 125820 [details] [review]
adds gegl-sampler-nohalo.* and inserts references in gegl-sampler.c, gegl-buffer.*, gegl-buffer-access.c and Makefile.am, and patches gegl-sampler-yafr.* and gegl-sampler-linear.c. 

Had forgotten to fix gegl/gegl/buffer/Makefile.am so that nohalo compiles.

Created attachment 125822 [details] [review]
adds gegl-sampler-nohalo.* and inserts references in gegl-sampler.c, gegl-buffer.*, gegl-buffer-access.c and Makefile.am, and patches gegl-sampler-yafr.* and gegl-sampler-linear.c. 

Eliminated a compilation warning.

Apologies:

Submitted my path too early.

Will make sure all is hunky dory.

Created attachment 125879 [details] [review]
adds gegl-sampler-nohalo.* and inserts references in gegl-sampler.c, gegl-buffer.*, gegl-buffer-access.c and Makefile.am, and patches gegl-sampler-yafr.* and gegl-sampler-linear.c. 


Fixed Makefile.am (had missed one line).

Finally, it's a go: I'm pretty sure the patch is good this time.

-----

Fixed quick and dirty timings (resizing four images through xml script):

gegl-sampler-linear before patch:

7.266 + 8.947 + 0.969 + 44.793 = 61.975s

gegl-sampler-linear after patch:

7.041 + 8.911 + 0.900 + 44.364 = 61.216s

Other methods:

gegl-sampler-yafr:

8.103 + 10.061 + 1.003 + 49.839 = 69.006s

gegl-sampler-nohalo:

9.479 + 10.813 + 1.060 + 51.466 = 72.818s

gegl-sampler-cubic:

9.159 + 11.584 + 1.079 + 55.193 = 77.015

(gegl-sampler-lanczos is even slower.)

The fact that cubic is slower than yafr suggests that the code could be sped up considerably, given that yafr is a substantially more complex method (on the other hand, the current cubic actually implements a two parameter family of bicubic methods, which does account for some of the slowness).

Comment about future developments:

I may be enclined to remove yafr from gegl once higher quality level nohalos are programmed, because higher level nohalos should produce better results across the board than all of the other implemented methods. The current patch only implements the lowest level nohalo (quality level 1; think of quality level 0 as being bilinear).

Nicolas Robidoux
Universite Laurentienne

I just figured out a way of making the nohalo code both shorter and faster.

I'll implement this, and submit yet another patch.

Nicolas Robidoux
Laurentian University

Created attachment 126065 [details] [review]
adds gegl-sampler-nohalo.* and inserts references in gegl-sampler.c, gegl-buffer.*, gegl-buffer-access.c and Makefile.am, and patches gegl-sampler-yafr.* and gegl-sampler-linear.c.

This should be the final patch.

Final timings:

cubic:   9.277  + 11.506 + 1.133 + 55.170 = 77.086s (unchanged by this patch)

lanczos: 11.645 + 14.465 + 1.277 + 66.643 = 94.03s (unchanged by this patch)

linear:  7.139  + 8.891  + 0.944 + 44.693 = 61.667s (a little smaller than before)

nohalo:  8.109  + 10.249 + 1.014 + 50.664 = 70.036s (new method)
 
yafr:    8.209  + 10.256 + 1.008 + 50.656 = 70.129 (smaller than before)

Nicolas Robidoux
Laurentian University

Sorry: the nohalo line in the last comment was incorrect:

nohalo: 8.378 + 10.536 + 1.024 + 50.367 = 70.305s

Apologies,

n

Yet another speedup for nohalo is coming down the pipeline.

Apologies for the bandwidth.

Nicolas Robidoux
Laurentian University

Created attachment 126202 [details] [review]
adds gegl-sampler-nohalo.* and inserts references in gegl-sampler.c, gegl-buffer.*, gegl-buffer-access.c and Makefile.am, and patches gegl-sampler-yafr.* and gegl-sampler-linear.c. 


Final ;-) revision.
78.266
Timings:

cubic:    9.179 + 11.656 + 1.082 + 56.349 = 78.266s

lanczos: 11.576 + 14.300 + 1.270 + 65.793 = 92.939s

linear:   6.988 +  8.840 + 0.910 + 44.009 = 60.747s

nohalo:   8.300 + 10.361 + 1.016 + 49.839 = 69.516s

yafr:     8.130 + 10.038 + 1.001 + 49.949 = 69.118s

Nicolas Robidoux

Created attachment 126250 [details] [review]
adds gegl-sampler-nohalo.* and inserts references in gegl-sampler.c, gegl-buffer.*, gegl-buffer-access.c and Makefile.am, and patches gegl-sampler-yafr.* and gegl-sampler-linear.c. 


I don't quite know if I should put my name in the copyright for the changes of bilinear. I don't particularly care, but wonder if "licensing issues" make that mandatory.

n

(Apologies for the bandwidth.)

Following a discussion with my colleague Minglun Gong of Memorial University who
is putting together a (non GEGL, of course) GPU version of this scheme for video enlargement, I clicked on something, and consequently there will be yet another version of the patch.

Nicolas Robidoux
Laurentian University

Created attachment 126406 [details] [review]
adds gegl-sampler-sharp.* and inserts references in gegl-sampler.c, gegl-buffer.*, gegl-buffer-access.c and Makefile.am, and speeds up gegl-sampler-yafr.* and gegl-sampler-linear.c. 


Given that nohalo will actually be two families of schemes: nohalo-sharp (implemented here at its lowest quality level, unless one counts bilinear as level 0) and nohalo-smooth (future programming: it's quality level 0 will correspond to quadratic B-Spline pseudo-interpolation), I figured it may just be better to call the method "sharp" and call the future quality level 1 nohalo-smooth plain "smooth."

So, gegl-sampler-sharp is what I've been calling gegl-sampler-nohalo up to now.

I should be done for quite a bit.

Nicolas Robidoux
Universite Laurentienne

I've commited these changes, have you got plans for how decimation should be done for these resamplers, as the resampling framework in GEGL only handles interpolation...


2009-01-14  Øyvind Kolås  <pippin@gimp.org>

        Applied patch from Nicolas Robidoux that adds a new sampler
        (gegl-sampler-sharp) building on the existing YAFR resamplers.

        * gegl/buffer/Makefile.am:
        * gegl/buffer/gegl-buffer-access.c:
        * gegl/buffer/gegl-buffer.c:
        * gegl/buffer/gegl-buffer.h:
        * gegl/buffer/gegl-sampler-linear.c: (gegl_sampler_linear_init),
        (gegl_sampler_linear_get), (set_property), (get_property):
        * gegl/buffer/gegl-sampler-yafr.c: (gegl_sampler_yafr_init),
        (catrom_yafr), (gegl_sampler_yafr_get):
        * gegl/buffer/gegl-sampler.c:
        (gegl_buffer_interpolation_from_string),
        (gegl_sampler_type_from_interpolation):

Øyvind:

> I've commited these changes, have you got plans for how decimation should be
> done for these resamplers, as the resampling framework in GEGL only handles
> interpolation...

I am not sure that I understand your question.

Do you mean how downsampling should be done with these resamplers?

If so, downsampling with these resamplers will be done just like they are done with, say, bilinear, which means that it, like bilinear, bicubic, yafr and lanczos, will give results which resemble nearest neighbour when the transformation downsamples a lot.

If you remember an email exchange we had with Alex Prokoudine and Sven Neumann, my opinion is that either we should have a resampler which is custom made for
downsampling, or the resampler should use information about the local gradient of the transformation---possibly approximated with finite differences---to select whether an "scheme for upsampling" or a "scheme for downsampling" should be used near the pixel under consideration. This leads, for example, to a box filtering scheme with "radius" which depends on the gradient of the transformation (and which in my opinion should be smaller than the "exact area" one).

I am of course open to be corrected or improved on with respect to this vision, which unfortunately will not see my programming input soon (unless an angel swoops in with enough money to buy me a leave from my job, or to allow me to hire competent student programmers, at the price such programmers deserve).

I hope that I make sense, and that I answered your question.

------

Thank you for merging my patch.

Nicolas Robidoux
Universite Laurentienne