Possible solution to much of the LAG and cpu/gpu overwork?

I have posted previously about my growing awareness of the increase in bandwidth usage, (higher download per hour rate) and how my cpu/gpu seems to be working harder... I do believe I found the solution to MY problem, and wish to share it in case it might help OTHERS too =)

my son and his fiance recently joined the SL community, which has been a blast, they are both very very artistic and creative, and my soon to be daughter in law is extremely good with textures and photoshop.
thus we embarked on a building project together, building castles... she made all of the textures, some of them hand drawn... we were so excited! everything looked beautiful too... and then I began having my download issues, noticed that I was downloading 3 times as much as 'normal' (granted for a given value of normal in SL lol)

after many days of frustration hammering at my ISP technicians it suddenly dawned on me... were we paying ANY attention to FILE SIZE on those textures? OMG we weren't!
we resized every single texture, for the textures that did not require an alpha channel we resaved them as high compression jpg files, and the alpha channel textures we resized pixel wise as small as possible while keeping the texture usable for what it was made for.
we cut approximatly 30 megs worth of image files down to 7 megs.... then re uploaded every texture concerned, re textured both builds completely and dropped our bandwidth usage by 2/3rds... AND cut the lag....

I wonder if anyone else pays attention to the actual file size in kb of the textures they upload? I have gone from downloading an average of 60 megs or more an hour in my own sim/build to 13 megs an hour....and you can actually fly again ...

food for thought. if more people used jpg files for the textures that didnt need alpha channels perhaps a lot of the bandwidth demands across the grid would be reduced. they look JUST as good, they load TONS faster and are extremely small in actual file size compared to their tga versions.

Regardless of the format of uploaded file, they are all stored as JPEG2000 images. You are quite right that image dimensions are relevant, and since the Q factor of the JPEG2000 images is not known, it is possible that a lower-quality JPEG upload might result in a smaller texture size as the source might be more compressible (maybe).

However, image dimensions are the real cost, for as you allude to, a 50% reduction per side is 1/4 reduction in image size. Finally, regardless of your upload format, image dimesions that are not powers of 2 are resampled by SL before storage. Thus, 128x256 will not be resampled, but 129x256 will and you certainly have more control over the resample if you do it yourself.

If you have a texture that has sides that are not in {32, 64, 128, 256. 512} you should force your resample to one of those dimensions and then apply it to a prim with the proper aspect ratio.

Yes, many people do know about the texture size issue but many do not and these forums reach but a small fraction of the playerbase.

If someone wanted to make a changing texture. It would cost less to upload one huge version that they could shift across, then to upload the separate textures.

Yes but the huge version is much more likely to be subject to LOD adjustments - SL has to fit all textures in scene into video memory of the graphics card and if the textures don't fit it will display a lower resolution version (so if you have many 1024x1024 textures SL could/will display the 512x512 versions of them and you'll lose detail - you can actually see it in action in the texture stats window)

Simple rules based on many threads that have discussed this topic in the past:

1. Always use TGA - No advantage in using BMP or JPG because the client will compress your image before uploading, plus neither supports alpha channels, and JPG drops some quality.
   
2. Always use 24-bit when you do not need an alpha channel.
   
3. Always size your artwork to powers of 2 before uploading - PS/PSP/gimp do a better job of this than the SL client does. If possible, start your design in powers of 2.
   
4. Use the lowest resolution you can to achieve the desired quality - but don't worry about file size at all; after JPEG2000 compression it becomes irrelevant.
   

well it certainly helps to know this stuff... I was not aware that SL compressed things at all... however I noticed such a drastic reduction in download rates once we did make the files as small as possible and make most of them into jpegs that I am wondering if SL's compression is working at all... maybe it used to work but doesnt anymore? it wouldnt be the first thing that got broken in the latest ... er ... upgrades.... yeah upgrades... sure, thats what they are right?
I will pass the above info over to my daughter... she is the texture slave...er artist!
thanks ! =)

Given the way JPEG compression works, it would not surprise me if for high Q values on the server side, that small JPEG source -> SL JPEG2000 would likely yield smaller JPEG2000 files as you've already stripped the less compressible bits out of your source image.

But, that's kinda picayune. Ben summarized it well; follow that.

On a side note to Mystic's problems I wanted to say that when we redid all the textures I didn't not resize the actual dimensions of the image but simply resaved it as a jpg with full quality, dropping the file size substantually. If they are truely supposed to be all compressed on upload I think, like Mystic said, that there is something wrong with the compression. We'll contiue to keep an eye on it and I will keep testing, but so far that's what it seems to me!

usually the artifacts in a jpg image cause jpg2k to produce a larger (filesize) image becuase theres sooo much more crap in the image to mathmaticly compress

... and another one (learned the hard way)

5) - Maybe once or twice in years of working in SL do you EVER have to use a texture bigger than 512 x 512.

If you are using a 1024 texture for almost anything, you are making a mistake no matter how you try to justify it to yourself and you are part of the great lag problem.

Thank you for saying it Diane...Thank you, thank you, thank you.

So many texture users out there swear that you lose detail when you use a smaller file. I don't think it's that noticeable in SL and I see better than 20/20...

I challenge clothing designers especially. Drop your file size and let us not be fuzzy to ourselves and others, PLEASE?

No need to challenge me. I am a fashion designer in SL and do graphic design in RL and I agree completely. The only difference between a 1024 and a 512 is the fuzzy longer load time on an outfit made with a 1024 texture. I started out with 1024's simply because that was the size of the templates and i didn't know better. I noticed a longer load time and thought i would try 512. I found it loaded immediately and was just as crisp and detailed upon rez as the 1024.

I want my clients wearing my designs, not melted smeary versions of them. I upload a 512 texture. Period. I never understood the big controversy.

Some very good points here! As a texture designer myself, I applaud all of you for making this thread and contributing to it!

SL bakes all its clothing textures at 512x512, even if the originating texture size is 1024x1024... which is why you're not noticing much difference between the two (your original 1024 was being auto-converted to 512 the moment you wore it...)

In short, anything bigger than 512x512 for clothing is pointless, as SL will squash them down to that resolution anyway.