Agreed on the caching to a a point. But if the user doesn't hit reload, and leaves the thread, then comes back, I think the images are called like a hard refresh. pulling them from the server instead of using a cached image. Not completely sure this is true, but my browser acts like it is.
With the advent of firefox, and IE 7 due out in a few months, a css version might be worth a try.
I'd be willing to do it, if i could get copies of the necessary files.
Here is an example of vbulletin skinning... Its an xml file and you then must include all the images to go along with it...if I had some sort of tutorial on the subject, i could be alot better at it but nobody has bothered to set forth on such a huge project since it can get so complex.
The caching point you make is a valid one because a server can set a certain time period when caching timeouts for the client thus telling the browser to request it again but im sure Boss and them have already addressed that (i would assume). The client can also set a time for all images to be redownloaded or to compare the cached copy with the server copy (with filesize I assume) and redownload if different.
I think most of what TRF was talking about though, was setting the images as <td background=*> elements rather than <img> tags.
Im not sure how that would help limit the bandwidth the images would take though. The image would still need to be downloaded at first impression and when the cache is renewed. Taking the verbeage off the image and making it css positioned text wont make a very big dent overall.
I just dont think its the forums images that is causing the increase in bandwidth.. maybe some, but nothing that would give Boss huge breathing room.
I think it had to do with how browsers handle background images. They only pull them once for the entive page and then cache them. He didn't say it would definitely make a difference, just threw it out there as something to try.