[Plplot-devel] Index order for our internal images

[Alan W. I. <ir...@be...>]

I noticed both for x20c and my modifications to it that the index
order of the array required for plimage is not the same as either
lena.pgm or the array produced by libgd.  Thus, such constructs as

for (i=0; i<width; i++)
    for (j=0; j<height; j++)
     	img_f[i][j] = img[(height-j)*width+i];

have to be used to copy from one form to another.  In this case img must be
stepped through every width pixels for the innermost loop which will cause a
lot of page faults on low-memory systems.  In the interests of minimizing
page faults for our users dealing with large images (and astronomers and
other scientists routinely deal with images that are sometimes a lot larger
than a 1000 on a side and the historical trend on image size is always
increasing) I would like to see this code fragment (and the equivalent code
fragment when I am using libgd as input) changed to something like the
following:

for (j=0; j<height; j++)
    for (i=0; i<width; i++)
     	img_f[j][i] = img[(height-j)*width+i];

Note the two "for" loops have been switched, and now img is stepped through
one pixel at a time for the innermost loop.  However, to also make sure that
img_f is stepped through one pixel at a time, note that img_f has to be
reorganized with swapped indices, and the internals of plimage.c and xwin.c
also have to be modified the same way with swapping of for loops, etc.

Clearly, plimage was put together with the interests of keeping page
swapping to a minimum for the current internal arrangement of images, and it
would be a fair amount of work to switch over to the opposite scheme.
However, for two distinct external image formats (pnm [which really stands
for pbm, pgm, and ppm] and libgd [which stands for both jpeg and png]) we
have images organized with the the column index changing most rapidly over
the width of the image while our internal image format used for plimage now
is arranged with the row index changing most rapidly over the height of the
image.  This incompatibility forces page faulting, and the only way to avoid
this is to change our internal format so that the column index changes most
rapidly.  (I don't care whether a given index is accessed in order or
reverse as in the above modified example. It is the page faults I want to
eliminate by making sure the pixel step is just one unit for the innermost
loop.)

Discussion?  In particular I have only looked at two external libraries, and
I am interested if anybody has found some external image libraries that are
*not* organized with the column index of the image changing most rapidly. If
there is no clear predominance we should stick with what we have, but if
most are organized the way that libpnm and libgd are, then I think we should
organize our internal images in the same way to avoid the page faults
as much as possible.

Note if everybody here thinks this index swap is a good idea, I am willing
to do the necessary conversion work on x20c, plimage.c, and xwin.c.  If a
change is required it is best to do it now rather than later when changing
the plimage api will hurt our users.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________