Looking at vDSP_conv

http://developer.apple.com/library/mac/#documentation/Accelerate/Reference/vDSPRef/Reference/reference.html

It looks like this is designed for sound (one dimensional data) and
not images (two dimensional data).

So using it to sample rows will probably be tedious.  (You can do it,
though, by iterating over columns, one by one.  Plus, of course
another instance to sample between columns.)

So, for an 8 by 8 specimen you'd need to call vDSP_conv a total of 5
times.  It might be more efficient (and simpler) to just write your
own sampling implementation.

So here's an untested C implementation:

void sample2(
    pixel *outbuf,  /* preallocated memory for result image */
    pixel *inbuf,   /* memory for argument image */
    int inX,        /* argument image width - twice result image width */
    int inY,        /* argument image height - twice result image height */
    char pickX,     /* 0: pick even columns, 1: pick odd columns */
    char pickY      /* 0: pick even rows, 1: pick odd rows */
) {
    for (int j= 0; j < inY; j++) /* j selects a row */
        if ((1 & j) == pickY) /* j selects a relevant row */
            for (int k= 0; k < inX; k++) /* k selects a column */
                if ((1 & k) == pickX) /* k selects a relevant column */
                    outbuf[(k+(j*inX)/2)/2]= inbuf[k+j*inX]; /* copy
the pixel */
}

Note that 1 & x in C is like 2 | x in J.

Note that x/y in C when x and y are type integer is like <. x % y in J.

Note that I have assumed that pixels are at least one byte wide, and
that you have defined a type named 'pixel'. It's important that pixels
have a type (because the type is necessary to determine what the
indexing operations do) but you might want to spell the type name
differently.

Note that this is untested code and may not work - for example it may
syntax errors which prevent the code from compiling.  (But I think the
basic idea is valid.)

Finally, note that I have not attempted to optimize this code (quite
probably gcc will do a good enough job. And, it's never a good idea to
optimize code without benchmarking it to see if the optimizations
improve anything. All too often, "optimizations" make things worse.).

But we should probably move this subtopic to the chat forum if we go
back and forth about C without involving any J programming.

FYI,

-- 
Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to