Scaling tests for GTK+ & mediaLib

[James Cheng <James Cheng Sun COM>]

Hi GTK+ team,

My name is James Cheng.  I have been helping Brian Cameron from Sun's
Gnome team to accelerate image scaling by using functions provided in
mediaLib, a product developed by our group in Sun (which can be found
at http://www.sun.com/processors/vis/mlib.html ).  To be specific, we
are using mediaLib's mlib_ImageZoomTranslate() and others to speed up
gdk_pixbuf_scale() and others in gtk+/gdk-pixbuf/gdk-pixbuf-scale.c.
Brian had put back a patch for this at:

http://cvs.gnome.org/bonsai/cvsblame.cgi?file=sun-patches%2Fgtk%2B/450-00000-s.d
iff&rev=&root=/cvs/gnome

Brian told me that you are in a process of creating scaling tests for
GTK+, and he suggested that I let you know the issues and experience
we have on this topic.  Hope they can be somewhat helpful to you when
selecting a test method and/or setting criteria of correctness.

In mediaLib, we have different versions of libraries for different
platforms, such as the C version for Solaris/x86, another C version
for SPARC without VIS, and VIS versions for VIS1.0 and VIS 2.0.  We
also have C and MMX versions of a subset for Win32, a C version of
the subset for Linux, mainly for supporting another Sun product, JAI.

For any function in mediaLib, we usually use the result of a simple
C implementation as the reference, and check the results of various
versions of optimized implementations against it.  For imaging
functions, we do pixel-to-pixel comparisons.  But because of rounding
and other differences between any two implementations, some tolerances,
i.e., some "fuzziness" on pixel values, have to be set to let the
comparison tests pass.  Or, the statistics numbers on the differences
between two images, such as mean, max_diff, std_dev, and etc., can be
used to help make the decision.

Like other geometric functions, image scaling is one of those
trickiest in terms of both implementation and correctness testing,
as both coordinate mapping and pixel value interpolation can cause
deviation on the final results.  For example, in the nearest-neighbor
case, a slight difference on the calculation of the coordinates may
result in picking up a totally different source pixel as the nearest
neighbor for some destination pixels.  Therefore, some "fuzziness"
on pixel locations has to be added to the test, or human visual
checking has to be used in cases like that.

To be specific, I have the following concerns on your scaling tests
for GTK+:

1) In current pixops.c, the PIXOPS_INTERP_BILINEAR case is done with
   a table-driven algorithm implemented in pixops_process() with a
   SUBSAMPLE_BITS = 4.  I hope when we replace it with a mediaLib
   function which does BILINEAR interpolation with a better
   subsampling precision, it will not fail the test.

2) In mediaLib geometric functions, pixels are considered to be
   centered at the x.5 coordinate points, i.e., the upper-leftmost
   pixel's center is at point (0.5, 0.5), and the coordinate mapping
   is done by following the following formulae:
   
   	xd = xs * scale_x + trans_x;
   	yd = ys * scale_y + trans_y;

   It seems to me that GTK+ functions are taking the 0.5 into account
   in many cases for calculating the starting point of the source
   buffer, filter offsets, and etc.  I hope they are really like what
   I expected.

3) It seems to me that the pixops_process() function is handling the
   edge pixels in a way of expanding the center part of the 
   destination image by replicating the edge pixels.  In mediaLib,
   there is a mode of edge condition which expands the source image
   in a similar way.  It should have a slightly better effect, I
   believe, but I wonder if that will cause a test failure.

BTW, there seem to be some typos in gtk+/gdk-pixbuf/pixops/DETAILS,
under "Filter computation":

	To compute dest[i,j] we do the following:

	 x = i * scale_x + x_offset;
	 y = i * scale_x + y_offset;

Should the last two lines be ?

	 x = i / scale_x + x_offset;
	 y = j / scale_y + y_offset;

Thanks in advance for taking our concerns into consideration when you
create the scaling tests.  Let us know if you have any comments or
suggestions on what we should or shouldn't do when we try to speed up
the GTK+ code.  Any questions/comments on mediaLib are very much
welcome.

Regards,

-James Cheng
 Sun Microsystems/mediaLib