The 8 bit paletteized option (PseudoColor in X11 speak I think) is an interesting idea. Last time I used that stuff was late 80s when true RGB displays were much more expensive; I was glad to see the back of it. We did indeed used to use a custom palette depending on what we were displaying: for greyscale images we used some palette with something like 224 greys and the rest for a few "UI colors"; for color images we had to dither to 3 bits red, 3 bits green and 2 bits blue and it still looked terrible. No idea whether Qt supports such customization; documentation at http://doc.qt.io/qt-4.8/qapplication.html#setColorSpec suggests Qt has it's own palette built-in for such purposes. I'd be amazed if anyone was seriously using this sort of palletized graphics display these days when it seems OpenGLES is defines the min.spec graphics for even the lowliest embedded chips.
But if you think the 3:1 or 4:1 reduction in bandwidth moving from a 24/32-bit "visual" to an 8 bit one is all you need, AND most of your bandwidth hogging content is greyscale images, then my instinct would be to just look into displaying the images by sending them to the server (display) side using a single channel OpenGL GL_R8/GL_INTENSITY8 texture, and appropriate GL commands to texture that to a view-filling polygon. This changes the solution focus a bit from messing around with Qt to messing around with OpenGL though.