Question

I’m writing in C for OSX, running on a 64-bit machine in 32-bit mode. I’m compiling using GCC for 386. The project is large; I’ve not seen any odd behavior from the compiler (possibly until now.) The application is multithreaded, and this code is meant to be, but is being run single-threaded at this time. I am compiling using the position independent clib, and using posix threads, when threading. This code, btw, acts exactly the same if I do thread it.

The following is a simplified procedure that demonstrates the problem in the simplest form. Basically, I’m moving 16-bit image channels here from one set of three RGB channels (mr,mg,mb) to another set of 3 RGB channels (lr,lg,lb) of exactly the same size. The fragment, as I’m about to dump it, works perfectly:

void lrip_me(   unsigned short *mr, // RIP from source image
                unsigned short *mg,
                unsigned short *mb,
                unsigned short *lr, // into RGB layer
                unsigned short *lg,
                unsigned short *lb,
                struct layer *lay,
                long start,long finish)
{
long xw,yw;
long xf,yf;
long x,y;
unsigned long offset;

    xw = lay->parent->x;
    yw = lay->parent->y;
    xf = xw - 1;
    yf = yw - 1;

    for (y=start; y<finish; y++)
    {
        for (x=0; x<xw; x++)
        {
            offset = (y * xw) + x;
            if (x==0 || x==xf || y==0 || y==yf) // then on edge
            {
                lr[offset] = mr[offset];
                lg[offset] = mg[offset];
                lb[offset] = mb[offset];
            }
            else
            {
                lr[offset] = mr[offset];
                lg[offset] = mg[offset];
                lb[offset] = mb[offset];
            }
        }
    }
}

As you can see, the action at the edge of the image and inside the edges is the same; I’m simply moving the data. And this works — the output of this is an image in the lr,lg, and lb channels.

BUT. If, inside the else clause, I change the lines to read…

            lr[offset] = mr[offset-xw];
            lg[offset] = mg[offset-xw];
            lb[offset] = mb[offset-xw];

…you’d expect the interior of the image to move one scan line, as the data fetches would be coming from a full scan line’s distance away but going to an un-shifted target location. Instead, the output looks completely random. Like the shorts were loaded on the wrong boundaries, perhaps, or from somewhere else. This does the same thing…

            lr[offset] = mr[offset-1];
            lg[offset] = mg[offset-1];
            lb[offset] = mb[offset-1];

…there, I’d expect the image to move one pixel horizontally. No. Same result — purest hash.

I have tried changing to pointer math instead of arrays //*(mr+offset-1)// and get exactly the same result. I’ve compiled it in a library, and inside objc environment. I’ve tried using even offset, thinking perhaps the compiler is confused about the size of the data. I get the same results every time. The offset value can be used as is, but ONLY as is. It can’t be modified inside the brackets, and furthermore, it can’t be modified OUTSIDE the brackets, just being treated as a long.

I have NO idea what is going on here. I would surely appreciate it if someone would help me understand what is.

A little background; this is a RIP (remove isolated pixel) operation, or at least, it will be, if I can get at the 8 pixels surrounding the one the loop is currently looking at. That’s why the edges are treated differently; I don’t want to run the 8-pixel lookaround on the edges, only inside them where I’ll always have all 8 to look at:

ooo
oxo
ooo

In this test case, I’ve removed all the RIP code, as it adds a lot of complexity and doesn’t shed any light on the problem. It’s simply (hah!) a situtation where array and pointer offsets don’t seem to work sensibly.

Answer 1

Your index function assumes the 2D arrays are in row-major order.

offset = (y * xw) + x;

Perhaps they are in column-major order.