Mac Forum / Programming / Mac Programming / December 2005

A week or few ago, I asked about grabbing and/or stuffing a pixel's RGB
value out of/into a pixmap, and got information on Set|GetCPixel().
Great information. Quite useful. Also got advice that it was likely to
be too slow for my purpose (VMD) due to various steps involved in
handing it back to me. Unfortunately (and that isn't a criticism of the
advice... read on...) the advice was just as good as the information
that pointed me at Set|GetCPixel in the first place - it is indeed too
slow for my purposes, seeing as doing nothing more than using those two
routines as the core of a "brute force" copy from one 640x480 pixmap to
another, with no intervening pixel-processing involved, takes nearly 10
seconds. Actually being able to *DO* something with the pixels before
writing them to the output PixMap would be nice, since the whole point
of this exercise it to process the image so taht I can detect motion in
it...

To be more than just a "toy", I need it to be handling *AT LEAST* a
frame every 3-5 seconds, with 1 second or less between frames being much
better if I can somehow swing it.

So I obviously need a better way of "playing on the pixmaps".

Another factor:
Apparently, the method I've been using is creaming something in RAM, as
well as still being too slow to be all that useful. Without the "poking
around where I probably don't belong" code that accesses PixMaps
directly, the program runs flawlessly. With it, I get intermittent
quit-time or shortly post-quit-time crashes. I wonder if I've got a
problem calculating the index into the array of spource values? Doing
the math on "live" pixmaps verifies that the rowBytes value does indeed
match the expected value of 4 * HorizontalPixels, so it doesn't appear
that there's any "weirdness" in the layout of the pixel array. So I'm
stumped as to whats causing the crashes. (Even more stumped since they
aren't repeatable/predictable at a finer resolution than "it sometimes
crashes at or just after quitting when the pixmap accessing code is "in
play", but doesn't when it isn't)

Here's how I'm getting a pixel at the moment:

Note: This routine was designed, tested, and intended *ONLY* for use
with 32-bit direct color PixMaps as implemented for MacOS 9.1/Carbon.
Try using it for any other bit depth, or with an indexed color PixMap,
or with a PixMap that isn't part of an offscreen GWorld, or on MacOS X
(Classic MAY work, but I'm not equipped to test that idea) and I all but
guarantee it'll malfunction. Don't say I didn't warn ya!

RGBColor getpixel(GWorldPtr Source, int H, int V)
 {
   PixMapHandle  ThePixMapHandle = GetGWorldPixMap(Source);
   Ptr           BaseAddress = GetPixBaseAddr(ThePixMapHandle);
   long          RowBytes = GetPixRowBytes(ThePixMapHandle);
   long          Index = 0L;
   PixelStruct   ThePixel = {0, 0, 0, 0};
   PixelStruct   *PixelPtr = &ThePixel;
   RGBColor      ThePixelColor = {0, 0, 0};
   Rect          Bounds = {0,0,0,0};

   Locker(Source); // My conditional version of LockPixels()
   // Sanity-check the H/V values against Source's bounds Rect.
   // (Things get *REALLY* hairy if we trying playing outside it)
   if ((Bounds.left <= H) && (H <= Bounds.right) &&
       (Bounds.top <= V) && (V <= Bounds.bottom))
     {
       // H/V OK. "Fold" them into a linear index into the array of
       // 4 byte RGBColor values and use that to point to the desired
       // pixel's raw RGB value in the array.
       PixelPtr = (PixelStruct *)BaseAddress +
                                 (V * RowBytes) +
                                 (H * sizeof(PixelStruct));
     }
   else
     {
       // H and/or V is/are outside the bounds of this pixmap.
       // Function initialization has already pointed PixelPtr
       // at a known {0,0,0,0} PixelStruct, so just fall through
       // into the exit code to return it to the caller.
     }
   // Convert the pixel values pointed to by PixelPtr (Might be
   // {0,0,0,0} if H or V are out of range) into an RGBColor struct
   ThePixelColor.red   = PixelPtr->Red;
   ThePixelColor.green = PixelPtr->Green;
   ThePixelColor.blue  = PixelPtr->Blue;
   // We're all finished with the pixmap for now. Unlock it.
   Unlocker(Source);
   return ThePixelColor;
 }

The reverse operation, putpixel(), is quite similar, with the obvious
changes that are needed for writing a supplied value, rather than
reading and returning a result.

Obviously, there's a bunch of "gotta redo it every time" overhead -
Getting the handle to the pixmap, the (Un)LockPixels and H(un)Lock
operations, getting the bounds and baseAddr value - But if the pixmap is
kept "permanently locked" - something that the docs seem rather
"insistent" about when they say it isn't a good idea - doesn't that
invite problems with heap fragmentation? And if it's locked for each
access, then unlocked, the values have to be considered volatile between
calls, requiring a fresh cycle of "get PixMapHandle, lock it, get base
address and rowBytes values" before the next access can be done, blowing
performance out of the water.

Is it just me, or does this seem suspiciously like one of those classic
"damned if you do, damned if you don't" situations?

Is there a better way? Seems like there has to be, since programs like
Photoshop manage it, and at a much higher speed.