Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

According to my tests that image only contains 3 colors:
255,255,255 
0, 0, 0
204, 204, 204

There is definately no 0,0,153 color.

The image does indeed only contain (display) the 3 colours you mention. The embedded palette however definitly defines 216 colours, as shown by the output of test.php or:
for ( $i = 0; $i < imagecolorstotal( $im ); ++$i )
{
  $c = imagecolorsforindex( $im, $i );
  echo "$i = {$c['red']} {$c['green']} {$c['blue']}\n";
}
Corel Photopaint also shows me a 216-colour palette.

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

The color_index parameter for imagecolorsforindex() can be generated by imagecolorat(). That function can only fetch the avaliable 3 colors of the image, hence all other colors cannot be resolved regardless of the palette.
This works the same way in GD 2.X bundled with PHP as it does with you GD 1.8.4

I fail to see how that relates to this problem. The imagecolorsforindex() function is not behaving unexpectedly: it returns all 216 colours of the palette! Also, as you can see in my first comment, both imagecolorclosest() and imagecolorresolve() do recognize the palette (somewhat): they return a colour index of 215 and 214 respectively, not 0, 1 or 2 (<= no. of used colours). The fact that they return different values also troubles me.

At best this is a documentation bug. The documentation does not differentiate between colours actually used in the image, and colours defined in the embedded palette. As I read it now, the functions ~exact(), ~closest() and ~resolve() should search/walk the palette (like my code snippet does). However it seems as though they can only return colours that are used in the image.

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.

"If you created the image from a file, only colors used in the image are resolved. Colors present only in the pallete are not resolved."