The reason it works, (I've done this with other programs, not just EL) is because the client simply looks for the .bmp extension and loads that. It doesn't care "was it saved as a bmp".
Yeah i know ;p the extension is just part of the filename, and the software looks for a particular filename. The idea of extensions dictating the format of the file is traditionally very much a Windows thing. (tho it has bled over to other OS'es now.)
To most everything, an image file is an image file. The extension it was saved in is more of a matter of compression at time of saving than anything else.
Well i have to disagree.
An image file isn't just an image file.
A JPEG renderer cannot process a PNG, a GIF renderer cannot process a TIFF, IE6's PNG renderer cannot handle standard compliant PNG transparency, and a BMP renderer cannot process a JPEG.
The fact you've encountered many softwares that are capable of rendering many different image formats doesn't mean all software will be able to. Software can only render an image it has a library for (whether in-built or otherwise). All these 'non-specialized' formats are still very different.
Your theory would dictate that using jpeg compression anywhere within the client and just renaming to .bmp would work, but it doesn't. For example, try converting some of your meshes to jpegs and giving them a .bmp extension and try to use them... it doesn't work. The software strictly expects 8bit image data for meshes, and anything that's not 8bit renders incorrectly. (i did discover tho that 8bit PNG's can be renamed to .bmp and work).
The reason i ask for Windows users to test is to find out if the EL client
itself does infact have JPEG and PNG decompression in-built or if when i ran it on Linux it was just using my system image rendering libraries... but no matter, i remembered EL uses
SDL_image, which supports at minimum PNG, JPEG and TIFF.