[GRASS5] Raster_int()

GRASS GRASS developer
1

Hi developers,

I have a question about Raster() functions.

src/display/devices/lib/Raster_chr.c:
-----
int
Raster_char (int num, int nrows, unsigned char *array, int withzeros, int
color_type)
{
  ...
    i = num ;
    while(i--)
      *(iptr++) = *(cptr++) ;
  ...
}
-----

in the above code segment, we can know that 'num' means the length of 'array'.
However,

src/display/devices/XDRIVER/XDRIVER24/Raster.c:
-----
int
Raster_int(int num, int nrows, int *array, int withzeros, int color_type)
{
  ...

        for (j = 0; j < num; j++) {
            if (*arr == 0) {
                if (width > 0) {
                    for (i = 0; i < nrows; i++) {
                        XPutImage(dpy, bkupmap, gc, grimage, 0, 0,
                                  cur_x + start_col, cur_y + i, width, 1);
                    }
                    width = 0;
                    start_col = j + 1;
                } else {
                    start_col++;
                }
            } else { /* non-zero pixel, put into the image */
                if (get_table_type() == FLOAT) {
                    if ( color_type )
                        XPutPixel(grimage, width++, 0,
                                  (u_long) _get_color_index(*arr));
                    else
                        XPutPixel(grimage, width++, 0,
                                  (u_long) *arr);
                } else if (use_visual->class >= TrueColor) {
    ...
    }
      }
      arr++;
  }
  ...
}
-----

in XPutPixel() calls, we always put pixels in the same row 0.
And if some zero values found, XPutImage() duplicates this row 0 into row
1-(nrows-1).

Supposing this case:

/* image

   00100
   01010
   10001
*/
int *array = { 0, 0, 1, 0, 0,
               0, 1, 0, 1, 0,
               1, 0, 0, 0, 1};

CASE A)
'num' is ncols.
Raster_int(5, 3, array, 0, 1); /* num is width */

produces the following image:

    00100
    00100
    00100

CASE B)
'num' is the number of array elements.
Now,
Raster_int(15, 3, array, 0, 1); /* num is the number of elements */

produces:

    00100 01010 10001
    00100 01010 10001
    00100 01010 10001

CASE C)
So, we should use Raster_int() like the followings:

  for(i=0; i<3; i++){
    R_move_abs(x, y+i);
    R_raster(5, 1, 0, array+5*i);
      /* this func calls Raster_int(5, 1, array+5*i, 0, 1); */
  }

produces:
    00100
    01010
    10001

'nrows' should be always '1' to get a correct result. Why is this needed?

Is this intended?
It's so inconvenient and not easy to predict results.

All modules may be working on 'CASE C)'. I think that this behaviour might
be related to many G_* functions such as G_get_raster_row() which manipulate
raster maps row by row. G_get_raster_row() function reads raster map row
by row. Then we draw this row on a monitor. Then read again, ...
So we have not experienced any trouble drawing raster data.

I think that 'num' should be the number of colums and CASE A) should work
correctly.

Any good idea?

Regards,
Huidae Cho

2

GRASS wrote:

I have a question about Raster() functions.

in the above code segment, we can know that 'num' means the length of 'array'.
However,

src/display/devices/XDRIVER/XDRIVER24/Raster.c:

in XPutPixel() calls, we always put pixels in the same row 0.
And if some zero values found, XPutImage() duplicates this row 0 into row
1-(nrows-1).

CASE A)
'num' is ncols.

Correct.

CASE B)
'num' is the number of array elements.

Incorrect.

CASE C)
So, we should use Raster_int() like the followings:

  for(i=0; i<3; i++){
    R_move_abs(x, y+i);
    R_raster(5, 1, 0, array+5*i);
      /* this func calls Raster_int(5, 1, array+5*i, 0, 1); */
  }

Yes, if you want to display the raster without scaling.

'nrows' should be always '1' to get a correct result.

"nrows" is the number of rows to draw with the specified raster data.

Why is this needed?

So that you draw scaled rasters without having to repeatedly send
identical data.

Is this intended?

Yes.

It's so inconvenient and not easy to predict results.

All modules may be working on 'CASE C)'.

No. Raster operations are normally scaled according to the size of the
monitor window. If the monitor window is larger than the region's
resolution, then R_raster() will frequently be called with nrows > 1.

Look at raster.c and raster2.c in src/libes/display.

--
Glynn Clements <glynn.clements@virgin.net>