Sure thing Terry!
What I'm saying is that for analog output to a CRT (which I was assuming, but I may be wrong if you were using a DVI box or something like that), you have 10-bit DACs at the video card. So if there are adjustments you are making in the PC, such as a gamma tweak or any other settings, you have the bit-depth to do this very cleanly because there is no 8-bit bottleneck at output. The computations can be done in >8-bit in the card, and is output at >8-bit to the CRT. The CRT, being analog, doesn't have any bit-depth limitations, so there is no bottleneck there either where banding/contouring would be introduced as a problem.
Now, if you are going DVI output to the ruby, DVI out is 8-bit, so if there are adjustments happening in the PC, things will have to get output back down to 8-bit which may cause contouring artifacts. Now, the ruby, being digital, may have internal limits (I don't know) that could introduce contouring due to all the processing it is doing, so it is quite possible that this is the cause. However, I'm skeptical of this because I haven't heard this reported about the ruby, but it certainly is possible. There are many lesser digitals that have banding problems that you can't get around, and while I would be surprised at this point if this were a significant issue in the ruby, what with all the gamma processing going on in there it's certainly not unthinkable.
As for a levels expansion to PC levels, especially if this were happening with an 8-bit DVI bottleneck, this would definitely cause some banding issues. You would definitely see this looking at the DEEP ramps patterns on Avia PRO, or the banding-check pattern on Avia PRO. They should be completely smooth, and unclipped.
The banding will cause exactly what you are describing in the image, gradations through smoke will get blocky and unsmooth. You'll see this most of course in large things with smooth gradations such as smoke, skies, underwater, etc. Colors will look "crushed" between the bands as things are smashed into a single code, and then "jump" too far to the next code because the bit-depth is not sufficient somewhere. Expansion/re-mapping of levels can definitely cause this if there is an 8-bit limit, because 8-bit should be *just* enough bits to make smooth transitions, and the moment you try to re-map things WITHIN an 8-bit flow with 8-bit limits somewhere (like DVI) the rounding that happens to find the closest tread will cause some things that should be slightly different colors to be smashed to one code, and then other things that should be slightly different colors to be mapped to "jumps" in code bigger than they should be. This causes the nasty banding and looks like butt.
A CRT can help mask these problems a little bit because they're a little bit softer, but even with an 8-incher you should see banding problems pretty readily (let alone a 9-incher) if it's in the chain. For instance, if you use FFDshow's level feature to re-map things, it operates in 8-bit, and will cause some very nasty banding to the CRT.
Anyway, my point is just that because there is DVI out to the Ruby that could be a bottleneck that could cause banding issues if there is some kind of tweaking going on in the PC, or a levels re-mapping that might NOT be visible on a CRT monitor because the analog output should have 10-bit DACs (AFAIK 10-bit at minimum) which is not likely to have the same problem. If you had a CRT with a DVI input, you would be more able to directly compare because the signal chain is identical, and that way you could see whether it's the chain, or indeed is caused by the Ruby internally.
In any case, the bottom line is banding sucks. :)