Relationships

What's the relationship between a RL pixel and a SL metre?

In other words how large does a 512 x 512 pixel image appear in SL (without stretching).

This question sort of doesn't make sense. Texture sizes viewed onscreen is dependent on the 'distance' at which you're viewing it from. So, if theoretically, you have a monitor with a resolution of 512 x 512 pixels. And you zoom in close enough to fill your whole monitor (using the HUD attachment for example), then thats what the size is. Actual size.

I see what you mean, but if I wanted a single high resolution image on a 0.5m x 0.5m surface, what is the optimum size of the .jpg? 128 x 128, 256 x 256 or 512 x 512?

The question is still ambiguous. Distance is essential. A 0.5m x 0.5m surface is hardly visible at 100m, but if you get close it becomes larger. If you alt-click on it and zoom in, then it can take the entire field of view. If you zoom in even closer, then a quarter of it takes up the entire field of view. And on and on.

Plus, we don't all run at the same screen resolution. Plus, all images aren't created equal. Some images require more detail to "look good".

The answer to your question depends on a lot of things. There isn't a single answer.

The better question would be, what would be an appropriate resolution for the intended application. Textures that are overly high resolution has a tendency to flicker and cause artifacts when viewed at an acute angle and actually look worse than one that is lower in resolution.

If the intended purpose is to display something that the viewer will likely to zoom in and inspect, then up the resolution. These can be a signage or display for example that requires text.

If its something for a vendor that switches textures to display different products, its better to go for something low ish. Only experimentation can tell.

Hi Eponymous. Welcome to SL.

This post is a little long, but please read the whole thing. You should find it to be helpful. If you have any more questions afterwards, come on back and ask.

First, don't use JPEG ever. It's a lossy format. It's suitable for web pages, but it's not meant for 3D graphics. Use TGA, always.

Second, as others have mentioned, there is no direct correlation between pixels and physical size. Your TV screen us made up of pixels, but you wouldn't measure objects on your favorite show with them. Think of a character you've seen on your TV screen whose height is well known, say, Darth Vader. I believe he's supposed to be 7 feet tall, or about 2.3M. Well, your standard NTSC TV screen is about 500 pixels tall, so when you see a full body shot of Darth, he's slightly less than that, maybe 450 or so. However, when you see a closeup of his face(mask) his entire head might be 500 pixels tall, bringing his total height to somewhere around 4000 pixels. His physical height remains fixed at 2.3M though, no matter how many or how few pixels are used to describe that height at any given time. Again, there is no correlation between pixels and physical size.

I realize this example is not precise to your question since you were asking about source resolution on a virtual object, and for a real object like the real actor in the real Darth Vader suit, source resolution is infinite. Consider that first example to be just a quick warmup demonstration to illustrate how pixels are not a measure of physical size. I'll now move on to explain how this actually does relate to your specific question, and I think you'll see why the above example was a necessary starting point.

To go with your example of a .5x.5M surface, let's say the texture you want to put on that surface is a picture of our good friend, Darth. Well, just like in the above example, the relevant question is how much of the screen is Darth intended to to cover? If the little prim he's on is intended to be viewed close up, so it covers most of the screen, then you'd want to use a fairly high rez picture, maybe 512x512. If it's meant to be viewed from a distance, then it's only going to occupy a small portion of the screen, so it will never be more than something like a hundred or maybe two-hundred pixels tall. In that case, a 128x128 or even a 64x64 would work just fine.

The bottom line, once again, is that there is no relationship whatsoever between pixels and physical size. It's apples and oranges. Pixels are a measurement unit for the screen itself, not for the physical objects that might be represented on the screen. Asking how many pixels a certain size object should be is kind of like asking how many liters is the is the length of your house. The answer is impossible to determine since liters are not a measure of distance. Neither are pixels.

Anyway, the guiding principle is always make textures as small as possible. Every texture uses a certain amount of video memory and it all adds up. The single biggest reason that SL is so slow is because most people use textures that are WAY too big. As I usually mention whenever a discussion like this comes up, malls in SL are a great example. The reason malls are so laggy is that the average one has gigabytes of texture data in it, but the average video card can only process in the megabytes. Cards choke under the pressure, and the visible result is an extreme drop in FPS.

Consider that every time someone uses a 512x512 where a 256x256 would have sufficed, they're consuming 16 times more of your precious texture memory than should be. Yes, you read that right, 16 TIMES! Mulitply that by the hundreds or thousands of textures in a mall, and it's easy to understand what's happening. Malls are just one example though, obviously. The same principle applies everywhere.

You want your textures to be small, small, small. SL is better at blowing up small textures to full screen size than just about any other program I've ever seen. It's truly remarkable how well it does this. For all SL's flaws, this is one area where it really shines. In most cases, you'll find virtually no detectable difference between a 256 and a 512 on the same size surface viewed from the same distance.

Here's the rule of thumb that I always suggest. Keep 75% of your textures at 256x256 or smaller, 20% at 512x512, and only 5% at 1024x1024. 1024's should be so rare that you should be able to count all of them in a single sim on one hand, and they should only be used when there is absolutly, positively no way around it. Almost everything should be 256 or smaller. Go bigger only when you absolutely have no choice, meaning you've got a lot of small text or other fine details that a 256x256 canvas cannot support. Generally speaking, occurances like that are pretty uncommon, so you should be able to stay small almost always.

Its surprising how lossy, the 'non-lossy' TGA format is in SL. Sometimes we need to see with our eyes instead of basing it on theory.

Every image uploaded to SL then gets encoded using the jpeg 2000 format. The only difference between uploading a tga file versus a jpg file, is that the jpg file is already in a lossy format. Both the tga then the jpg are then encoded to another lossy format (jpeg 2000).

If you use tga then you go through one lossy format, if you use jpg you go through two.

Of course if you compare a high resolution jpg with a low resolution tga, the jpg will look better, but comparing same resolution images, the tga should always give a better result.

You remind me of when I was active with synths, peeps used to read out whole lists of specs but the end sound was crap. I was like, "This is MUSIC! Listen with your EARS!"

JPEG2000 isn't lossy (according to the JPEG committee website anyway):

Interesting... though looking around a bit it looks like you can specify the fidelity of the information compression (less fidelity meaning smaller file size), and presumably SL is not using maximum fidelity ("lossless".

If you can stomach a lesson in applied theory for a moment (heavy emphasis on APPLIED), let me explain to you what those eyes of yours are seeing. As others have stated, when you upload any image to SL, it gets converted to JPEG2000. It's that converson that causes the loss you're noticing, not anything to do with the TGA source. TGA is inherently lossless, which is one reason it's the format of choice for most 3D applications, but JPEG2000 can be lossy or lossless, depending on settings. Appearences indicate that SL does not use the lossless option.

So, when you use TGA as your source, Sl is going to make it lose a little bit, yes, and there's no way around that since we don't have control over the JP2 conversion settings. That loss, however, is nothing compared to what you'll lose by using a JPEG as your source. When you use a JPEG, the damage gets doubled. It's the whole copy of a copy effect. The JPEG was already a lossy copy, and then when you convert that to JP2, you lose even more. Because of that, the importance of using TGA is even stronger with SL than with other 3D apps. We have to make the most of what we have.

Anyway, if you want to "see with your eyes" the real difference between TGA and JPEG, here's a simple experiment that anyone can do. Save a photograph in both formats and make sure the image size is such that you can see at least 4 copies onscreen at 100% magnification, say, 128x256 if you've got a small screen or 256x256 if you've got an average size (being able to see 4 onscreen at once will be imortant at the end). Now open the TGA version and save out to a new copy, also a TGA. Open that copy and save out again to another new TGA. Repeat the process 20 more times.

Now try the exact same experiment with JPEG's. Open the first one and save it to new JPEG. Then open the second one and save it to a third. Etc. You'll see that by just a few copies in you've lost a considerable amount of detail. By the 20th generation, the image will look really bad.

Now open TGA # 1, TGA # 20, JPEG # 1, and JPEG # 20, and line them up side by side so you can see them all. You'll see quite clearly that JPEG # 20 looks very different than JPEG # 1, but TGA # 20 looks exactly the same as TGA # 1, even though it's a copy of a copy of a copy of a copy... to the 20th generation. There you go. Concrete proof that TGA is lossless, using nothing more than your eyes. Good enough?


Losslessness is just one setting among many for JP2. Images can range at user discretion from entirely lossless to very lossy. As Seifert said, visual evidence suggests SL is using a high quality, minimally lossy setting, not the lossless setting.

The content of the image is also relevant, at least to download speed. Now, different compression algorithms do vary somewhat but there are some common tendencies that you can consider when you're deciding what resolution to use.

Large areas of the same color compress well. Subtle shadings compress poorly. If you have fully transparent sections, make sure that the FULLY-masked pixels are monochrome... SL may re-encode the image to take care of this, or your paint program may do that (if it's using a 'transparent color' rather than a separate alpha layer this will happen automatically... but it's also easy to produce badly broken textures that way... the sort of things that lead to partially hidden objects "jumping" in front of others).

I have never indicated that the TGA format is lossy. Its already a known fact in the industry, and I am not going to dispute that. I just said that the TGA implementation in SL is, which many have already pointed out, what hoops it runs through. Maybe I should word my english clearly next time.

But whats more important than all the technical diarrhea, is teaching what matters more to someone new to SL and building. Only real reason we have TGA being used in SL in the first place is because it carries an alpha channel, not because of image quality reasons. JPG is also 'convenient' format which anyone can view and sort easily in their folders because most modern OS's can thumbnail these without any plugins. I'm not sure if OS X thumbnails TGA's.

Personally, I find that TGA's are a pain to upload since I do not have the luxury of a stable broadband connection. It normally times out and aborts if the file is relatively big. Which in this case, I can get in a high resolution JPG successfully, which, if it was a TGA, would have to be a few orders lower in resolution if both were the same in file size. Its just a case of using the appropriate tools for the job at hand basically. But I'm sure there are some who like to pick their teeth with a shovel.

Yes, you probably should. Please do. I'm still not sure exactly what your point was.


Yes, and that's why its only appropriate to present methods that are proven principles. The fact that TGA is superior to JPEG for 3D applications in terms of both quality and functionality is such a proven pricniple. I repeat, TGA is the image format of choice for 3D, and has been for many years. There are some very good reasons for that.


I beg to differ. There are a great many formats that support transparency, all of which could be converted to JPEG2000, and so could work for SL. The reason TGA was chosen for SL was, once again, because it's the industry standard format. The reason it became the standard was because of quality, simplicity, and reliability/predictability. That standard has been in place for a very long time, and it's unlikely to change any time soon. For anything to last so long in computing is very rare, and when something does, it's because it just works.


Okay, yes, it's pretty silly that thumnail plugins for TGA do not come with OS's. However, the thumbplugs are easy to aquire and take less than a second to install. Is that "inconvenient"? Well, maybe, but certainly no less convenient that installing Photoshop the first time. Both need to be done once in order to best set up your machine as a canvas for digital art.


Hmm, you're the first person I've ever heard say that about TGA's, but if you search this forum and the Technical Issues forum you'll find a lot of posts from people who experience timeouts when attempting to upload JPEG's. I'm not sure what the reason is, but I'd assume that for those having the JPEG problem it's got nothing to do with file size. I think it has to do with an error in the process of unpacking the JPEG and then repacking it as JP2, but that's just a theory. LL has never offered an explanation on any of the threads in which the problem has been discussed.

In any case, if you're noticing that big files seem to be the culpret on your end, then this is yet another reason to keep texture sizes small. A 1024x1024 TGA will always be a 4MB upload with transparency or 3MB without, but a 256x256 will always be only 256K or 192K, much more reasonable.

If your particular system can't handle a 3 or 4 MB upload without timing out, then I guess for large textures you've got no choice but to go with JPEG. However, for everyone's sake, it shouldn't be very often that your textures are that big, so it shouldn't be an issue that comes up very often. I can see that it would be really annoying though, even if it is not an every day occurance.


Yes, that is the question. What I consider to be "picking teeth with a shovel" is the act of delieberately losing quality while not reaping any rewards from it. For a web application, sacrificing image quality would make sense since you'd get a huge speed benefit. For SL though, there is no such benefit. All you do is lessen the quality and that's it. Do as you like though. How good or how bad you want your stuff to look is up to you. my function here is simply to teach principles and techniques. What people choose to do with that information is entirely up to them.

Guys, guys ... the texture is converted to JPEG2000 by the client before it's uploaded. I don't have this from a linden but all my upload timing experiments suggest it's so. Besides, uploading uncompressed format and converting it on server side makes no sense whatsoever from technical/financial (bandwidth) point of view.

Now that's interesting. Thanks for adding that, Candide. I never thought about it before, but it would make a lot more sense to do it that way. If you're right, and my guess is you probably are, then the 4MB upload thing would never happen. That would make so much sense. It would also remove the last shred of a reason to use JPEG at all since there wouldn't even be a benefit to upload speed.

I'll ask one of the Lindens about this next time I get a chance. Thanks again for bringing it up.

My point being, do not disemminate misinformation. It was only a 2 sentence response said in jest that was far from serious. Long rambling responses to a very short response is a sign of personal insecurity when someone feels that their beliefs are being attacked, which I also suffer from sometimes.

Remember I refer these things here all in the context of SL, not to the general 3D application using masses. Bearing in mind, this is an SL forum, not an off topic forum.

There is no superiority between TGA or JPG formats. They are meant for different purposes. Similarly, the quicktime format was chosen here in SL because it was cross platform. Something thats been long staying in the industry also does not mean its superior. There can be a plethora of other reasons. Also, when you say TGA is the format of choice for 3D, that is a very general sweeping statement. While it is commonly used for some time for rendering purposes, doesn't mean that you have to religiously stick to it. If I need to interchange a texture that preserves layering information for a 3D app, for example. Do I use TGA over PSD?

If you refer to realtime 3D, then something like OpenGL requires that texture information be fed into its own internal format. Its not TGAs that you're looking at.

The act of deliberately losing quality is imposed on us is simply because of economics of running an asset server, regardless of what format we use. The act of a user using a higher resolution JPG over a lower resolution TGA is a matter of practicality.

Thank you for all the rereplies to my original question, which I now understand was not really logical. I should have asked about optimal TGA image sizes which fortunately, Chosen answered at length. Thanks for not treating me like a noob, (although I am).

I think you read into things a bit too much. I did not feel my "beliefs were being attacked" in any way. I find it very suprising that you would choose to interpret an attempt to convey educational information in detail as some sort of defense mechanism. It's nothing of the kind. My interest is simply to make sure that all who are interested in learning will have as much factual information as possible available to them.

I still don't understand what the real intention of your comment was, but the way it read was that you were implying that TGA is not actually a lossless format, and that people shouldn't listen to established facts in that regard. That may not have been your intent, but since that's easily how it could have been interpreted, I felt it was important to set the record straight. That's all. Any assignment of some sort of emotional alterior motive is yours alone. My only duty is to factual truth.

I don't care who said what. If it's true, I'll agree with it. If it's wrong, I'll correct it. If something I've said turns out to be wrong, I'll apologize and make the necessary corrections. That's been my policy since day one. There is no emotion involved on my part other than a sincere sense of duty towards helping others grow to be successful in their endeavors, and a desire to see SL look as good as possible.

Sometimes that requires increasing the level of detail in my explanations so that it's unquestionably clear to the readers. Every once in a while in some such cases, the person who initially made that level of detail necessary starts to feel threatened for reasons I don't fully understand, and then starts to treat the discussion as an argument. When that happens I feel a little sad for that person, but I can't let that stop me from making sure others reading are receiving the proper information. The only way I know to do that is to make sure I pack in so much explanatory detail and so many supporting examples that the underlying principle cannot be disputed.

I've been using this forum as a teaching platform for nearly two years now, and I volunteer considerable time every day for it. I take pride in sharing my knowledge with those who need it and in learning from those who do likewise. I won't stop or slow down just because you prefer to call it "long and rambling".


There is no difference between the general principles of 3D and the principles behind SL. They're one in the same. I don't know why you think they're not. All I can say is I will NEVER teach anything that is not harmonious with the principles behind all 3D applications, including SL. That's as on topic as you can possibly get.


Yes, TGA is the format of choice for 3D applications, and JPEG is the format of choice for website imagery. Since SL is a 3D app and not a website, TGA is "superior" for that purpose. Were we talking websites or digital photography, I would not be pitching TGA at all. In fact I'd be strongly cautioning against it. Since we ARE talking 3D, however, I'm doing what I'm supposed to do, which is explaining why TGA is superior in this application.


No, actually Quicktime was chosen for no other reason than that LL happened to hire someone who happened to be experienced with it. The way they had that person get his feet wet learning the SL code was by starting with what he knew and building a bridge between the two. Had that person never come along, we likely never would not have gotten video in SL at all, let alone Quicktime. It was simply a stroke of fortune that brought us Quicktime, nothing more. Had they been actively seeking a good cross-platform video player, there are certainly better choices than Quicktime available.


First, TGA is used for a hell of a lot more than just output rendering. It's used most commonly for texturing. Its consistent quality and entirely predictable file size make it ideal for all 2D elements of 3D models.

No, you don't HAVE to stick to it, but unless there's a compeeling reason not to, it only makes sense to follow standards, especially if you want to be able to work efficiently with others. That's why standards exist.


It's only very recent that 3D apps can use PSD. Most still can't do it. The common procedure if you need layers is to use a layered shader and to have each layer be an individual TGA or an individual procedural. Recent developments in some 3D apps have rendered that process obsolete in certain instances by incorporating PSD functionality, but since most apps still can't do that, it's best to stick with established procedures, at least for now. When the day comes that all 3D apps can use PSD and when it becomes possible to insert procedural layers inbetween the PSD layers, then it will make sense to change the standard. Until then, layered shaders with TGA's are still the most reliable way to go.


You're comparing apples and oranges. I fail to see how this is related to what we're talking about.


You're missing the point entirely. First, my comment about deliberately losing quality was a reference to using JPEG instead of TGA. Since the asset server uses neither, the only thing sourcing from a JPEG accomplishes is a loss of quality. Therefore, using JPEG means deliberately losing quailty. This has nothing to do with the "economics" of the asset server.

What is relevent to said "economics" is that the file that's actually stored on the asset server will be a JP2, and as I've said several times now, a JP2 sourced from a JPEG will be the same file size as a JP2 sourced from a TGA. It's the canvas size and the bit depth that matter, not the amount of bytes in the source file.

Second, you can't compare a lowres TGA to a hires JPEG in the manner you are attempting. You have to go pixel for pixel. Source file size is not relevant at all. When the JP2 is created, it sees the source image as bitmap, no matter what format it is. It looks at the actual pixels. It then takes that bitmap and applies the necessary math to it in order to repackage it as a JP2.

What that means is that if you're using a large image, you'll end up with a large JP2, whether it was sourced from a JPEG, a TGA, or any other format on Earth. If it's a small image, it will be a small JP2, again without regard to the format of the source. Once again, it's the amount of pixels in the image and the depth of their color that determine how big or how small the file on the asset server will be. That's it.

You're quite welcome, Eponymous. If you have any more questions, don't hesitate to ask. Several of us volunteer our time every day and we're always happy to help.

Here's a situation you might not use TGA - if your source software doesn't output it.

Like Adobe InDesign, for example.

Sorry to hear of your troubles, Zodiakos. Unfortunately it sounds like you're trying to put a square peg in a round hole. InDesgin is wonderful at what it's meant for, but image manipulation is not one of those things. It's meant for layout and publication.

The reason it can output JPEG is because one of its functions is take print material and output in web-suitable format. For example, you could take a sales brochure you've been working on and use it as a source for an E-commerce page without having to do any significant redsign work. It's actually pretty slick.

Unfortunately that won't help you with SL though. You really need a full-fledged graphical editor program, not a layout program with limited graphics ability. If you can afford Photoshop, it's worth every penny, and it will be of great help to you with whatever projects you would have bought InDesign for, since the two are designed to work together. If you don't have the money though, GIMP is totally free, and almost as good. If you use the GIMPshop plugin with it, it will look and work almost exactly like Photoshop. If you're experienced with InDesign already, you'll find that GIMP will be much easier for you to learn with GIMPshop than without.

TGA has so many different knobs and settings that out of all the programs I have that produce TGA only one produces a TGA that is actually usable with SL. It may be high quality but it's neither simple, reliable, or predictable.

Have you ever heard of PNG? PNG is a lossless industry-standard format that supports transparency, and unlike TGA it's simple, reliable, and predictable. (which ) it's actually simple, reliable, and predictable. And it produces smaller files. And it's more widely supported.

Right now my process of uploading an alpha texture to SL involves exporting the layers I want from Photoshop (SE, LE, whatever the "lite" version is called) as a PNG file, loading THAT file into Preview, saving it as a TGA, and the uploading that.

Actually it only has a couple of settings, size and bit depth. It's way too old, and has remained completely unchanged for way too long to have anything more than that. It sounds like the reason you're having trouble is you're using programs that weren't designed for what you're trying to do. Photoshop Elements (that's what it's called) is really meant for amateur digital phtographers to do simple tasks like red eye removal and adding text to photos. It was never meant for anything more advanced than that.

Even so, there's no need to do all that fancy exporting. you're making things way harder on yourself than you need to. PSE can do what you need it to do quite easily, although the how-to is not readily obvious. It lacks a channels palette, but it still does allow you to make alpha channels. You can't see them, but they're there. Robin Sojourner was I believe the first on this board to figure out how to poperly save TGA's with transparency in PSE. Here's her method. It works great:

1. Ctrl-click (PC) or Command-click (Mac) the thumnails for the layered elements you want to be opaque in you final image. If there's more than one layer that needs selecting, hold down shift while you're ctrl-clicking or command-clicking. Shift allows you to select more than one at a time.

2. Go Select -> Save Selection.

3. Go File -> Save as... Name your file, and select TGA as the file type. Then in the dialog that pops up, select 32-bit.

That's all there is to it. Really, really simple.

That of course is assuming that you need transparency. If you don't need transparency, then skip steps 1 & 2, and just save as TGA with 24-bit selected instead of 32. That's it. It really couldn't be any easier.