Re: [Plplot-devel] Index order for our internal images

[<jca...@in...>]

On Friday 30 November 2001 21:12, Alan W. Irwin wrote:
| 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=3D0; i<width; i++)
|     for (j=3D0; j<height; j++)
|      =09img_f[i][j] =3D 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=3D0; j<height; j++)
|     for (i=3D0; i<width; i++)
|      =09img_f[j][i] =3D 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.

You have done a good research, and everything you said implies that=20
we must change plimage internals now. Also because plimage() does not=20
yet support any of the difilt() standard transformations, it is=20
better to change now (or never!). In the next week I have no time to=20
make the changes, so please go ahead.

Alessandro, are you hearing? What is your opinion?

Have you tried a very large image to notice the page faults? Or are=20
you speaking just theoreticaly?

I used to have such performance concerns, but with the faster=20
processors and cheap memory I noticed that the time spent improving=20
code was really wasted, as no noticiable difference was noticed in=20
program execution. But of course this is my experience, otherwise=20
ATLAS would not be developed.

Joao

|
| Alan