DigitalColor Meter - RGB Values Don't Match?

Question

I've saved a 16 color palette under 'Colors' in the 'TextEdit' application. Each color has been set by directly typing in the values for R, G and B, for example one of the colors is R=68, G=255, B=153.
If however I open the 'DigitalColor Meter' application, which is set to 'RGB As Actual Value, 8-bit' and move the aperture over the same color in the 'Colors' window the DigitalColor Meter reports the RGB values of that color differently to what was set. For the color mentioned above it reads R=73, G=250, B=151.
Why don't the two match as they should? This happens with any color, but not black, white or a shade of grey.
If I save an image from a website by draging the image to the desktop then open the image and use the DigitalColor Meter to compare the RGB values of any given pixel in the saved image to those of the same image displayed on the webpage then again the RGB values between the two will not quite match, but black, white or a shade of grey will.
If however I save the image to my desktop by using >Apple-shift-4 to grab the image then the RGB values do match.
Can someone explain exactly what's going on? Does it have something to do with perhaps OS X applying gamma correction to the screen so that any image displayed on the screen will have its RGB values slightly altered?
If this is the case why isn't the DigitalColor meter affected or does it read a pixel's RGB values directly from graphics memory instead of screen memory where the gamma correction is being applied, not that I know how a Mac's graphics are organized, but I'm assuming anything to be displayed on the screen first has to be fetched from graphics memory.
Powermac G4 Quicksilver Dual 1 GHz   Mac OS X (10.4.10)   1.5 GB SDRAM, 120 GB HD, 23" Cinema Display
Powermac G4 Quicksilver Dual 1 GHz   Mac OS X (10.4.10)   1.5 GB SDRAM, 120 GB HD, 23" Cinema Display

Answer 1

Well this is a day of debugging I'd rather have back.
With a form of Rubber ducking my colleague helped me notice that the number of items being displaced was equal to the number of page zero item I added recently.
These items were placed in my menu region, which happens to be region position 7.
I had commented out a section of my page template
<!--<header id="uHeader">
  <div class="apex_grid_container clearfix">
    <div class="apex_cols apex_span_12">
      #REGION_POSITION_07#
      <div class="logoBar">
        <h1><a href="#HOME_LINK#" id="uLogo">#LOGO#</a></h1>
        <div class="userBlock">
          <img src="#IMAGE_PREFIX#f_spacer.gif" class="navIcon user" alt="">
          <span>&APP_USER.</span>
          #NAVIGATION_BAR#
        </div>
      </div>
    </div>
  </div>
</header>-->
but this content was obviously still being generated.
At some point during the page submission, this disturbed what apex was doing - somewhere these 'duplicated' yet commented field definitions were causing apex_application.accept to store the values in locations offset by the four P0 items.
I often look to page zero for potential causes to strange issues - but this one initially beat me.