The correct is indeed weird. It contains a lot of colors of numbers not divideable by 8. I would like to hear the idea behind that, I am interested 
OK. I'm not sure where to start from - there are lots of ways of explaining this simple (yes, it is simple) thing -, so I'll sort of resume from where I left.
With the simplified RGB555->RGB888 transformation we have seen that a "full" channel in RGB555 becomes 248 = F8 in 24-bit RGB (RGB888 from now on). However, F8 < FF: if we consider full white, it is easy to see that the simplified method does not allow a real full white, F8F8F8 being the maximum possible (which is slightly darker than FFFFFF).
Looking at this from a more practical point of view, hardware issues aside, ideally GBC's full white is supposed to be equivalent to FFFFFF, not the almost-but-not-quite-white F8F8F8.
The same goes for all the other colors, of course.
In other words, RGB555's range should cover RGB888's range - the difference being only the bigger grain.
In RGB888 a channel value goes from 0 to 255 = FF.
In RGB555 a channel value goes from 0 to 31 = 1F.
RGB888's 0 must look the same as RGB555's 0 (and viceversa).
RGB888's 255 must look the same as RGB555's 31 (and viceversa).
This gives us a strong hint about how to do the RGB555->RGB888 transformation: it must sort of "stretch" the 0...31 values to 0...255. To do this, all that is needed is this simple formula (where C5 = 5-bit Channel and C8 = 8-bit channel):
C8 = (C5 * 255) / 31
Not only this converts correctly the extremes (full black and full white), but it also maps proportionally all the values in between.
saimo
