transparency edge problem

In searching though this forum I found one mention of what my problem is and it was called "the transparency edge problem."

The problem simply stated is that on textures using transparency such as with a low prim tree or a privacy wall designed to simulate trees, the transparent edges have dark artifacts and thus the edge is visible detracting greatly from the realism.

The prims I am using are first made entirely transparent with a 100% transparent texture. Then I apply the texture that has the foilage on it to one (or more faces) as need be.

Even though the foilage line ends well below the top edge of the prim with nothing but transparency running along the entire edge on both adjoining prim surfaces, I am getting a dark artifacting line at the edge of the prim.

I see this on just about every low prim tree I come across in SL as well as the privacy screens being used.

I read someplace (which I can't re-locate) that this has to do with how SL bleeds the textures around the corner a bit from one face of the prim to another as part of the seamless 3D display environment.

If there is anyone who knows a trick to get rid of this transparency edge problem or knows where to find information here in the forums or elsewhere about it, I will be deeply indebted to ya and full of gratitude!

Mahalo,
Chiron Chrzan

Sorry, I have no ideas, but just add that I came here to post a similar question. In this case it's a 1024x1024 PNG I created in Photoshop, and the image is definitely totally transparent on the edge affected. A thin line is clearly visible in-world.

If I then save that texture back to the PC and load the result in Photoshop, there are obvious noisy artifacts, but there is still no edge at all.

Viewer is RC 1.20.13.

It really depends how high of resolution you begin with, and what you end up with. I generally use the 512x512, at 72 pdi, just as a template. Then bump the resolution to about 300-500dpi before I draw even 1 pixel. Just make sure you resample to that size, or it's pretty useless. I cut all my alpha channels at that high rez, make my layer masks, then save to TGA. Then reopen it and resample it back to 72 dpi. I never get any artifacting this way. In fact I would never cut an alpha channel at anything under 300dpi. But there are some oddities as well. I have read about versions of Photoshop just not producing compatable images, and always having artifacting, no matter what one does. Of course you can set your textures to a 99%-99% fill as well, inworld on your prim.

In my case, the image is 512x512, in editing and in SL, and there is absolutely no artifaction on the PNG created by Photoshop (v6). [1]

And, as you say, setting the texturing to 0.999 instead of 1 gets rid of the line, so presumably it's introduced into the texture after application to the prim but before in-world rendering. Very strange!

[1] Edited to add: well, there are artifacts from uploading errors, but not on the edge.

The solution to this is to use a 0.98 repeat in the direction where you have a solid texture on one edge and transparent on the edge opposite. For example, a tree: The bottom of the trunk touches the lower edge. All the other edges are transparent for the full length of the edge. When used to make a 3-prim tree, you end up with a small one-pixel asterisk above the tree - a trace of where the base of the trunk touches the edge at the bottom. Set your vertical repeat to 0.98, and that goes away.

Alternatively, when making such textures, add one or two pixels of transparency along the otherwise non-transparent edges, by deleting the lower one or two pixel rows of that trunk. Then when you use it, the transparent bottom edge is what it tries to tile to the top, and you see no glitch.

Unless you are planning to print the image, the dpi shouldn't make any difference at all. After all, the number of "dots per inch" only makes sense if all people will be seeing the image at the same scale. When you post an image in SL, its apparent size (and thus the dpi) depends on the size of a user's screen and distance from which she/he is viewing the image. The controlling factor is the total number of pixels in the image, so a better strategy for doing what you suggest is to create the image at a large scale --- say 1024 x 1024 -- and then reduce it to 512 x 512 for upload. And then do the 99% scaling when you apply the image to a prim, as you and Ceera suggest. That should take care of the problem.

When cutting alpha maps and using 3D effects, I really do think that a higher resolution will help, that's just me. Try using even the simplest emboss at 72 dpi, then try it again at 300, from where I stand it is a totally different image. I really suppose it depends what you are cutting. Say cutting a tree at 72, is a nightmare. At 300, still a nightmare, but at least you get clean edges. And yes, print rez is 300, but we are talking about pixel editing here. You really do need to be extremely close to get any sort of realistic detail.

But sure, there are many ways to achieve the exact same image, especially in Photoshop. I was just advising on what I do to cut an alpha channel, without any artifacting. If you feel comfortable drawing at screen resolution, go for it. And 72 is a universal standard for video projection, it does not change for different people. It's a hard coded standard in the way your video card draws images.

But I think what you are referencing is that when you upload images you get 3 copies. I think it's 3 anyway. One for preload, one half, and one full. But they are all still 72dpi. Just physically different sizes. It would be technically impossable to change the dpi on a monitor, irregardless who, where, whatever.

Hmmmmm.... I think we're talking about somewhat different things. You are right about the 72 dpi standard for video projection, but that's not the relevant consideration here. If you upload a 512 x 512 pixel image and put it on the screen, there will only be one effective size on your monitor that will have exactly 262,144 pixels in it. That's an image that is 7.11 inches on a side (=512/72). If you back off so that the image has a smaller area, it will contain fewer pixels. If you get really close, so that it fills the screen, you'll use a whole screen's worth of pixels.

The image file doesn't change when you zoom in or out. It still has 262,144 pixels worth of information in it. But your experience of the file changes. That's why a perfectly sharp image gets blurry if you zoom too close. You're viewing less of the information in the image file, and using more screen pixels to do it. If you back off, you don't get to see some of the information in the image file, because you don't have enough screen pixels in the smaller area to view them.

If you make your image 512 x 512 in Photoshop, it doesn't make any difference if you save it with 72 dpi, or 300 dpi, or 1000 dpi. It will still have 262,144 pixels worth of information in it, and it will look the same on your screen. But it WILL look different to different people, depending on how much area the image occupies on their screen at any given time.

So, my basic point was that DPI is only relevant if there is some way to guarantee that all viewers see the image at the same scale all the time. The only time that's true is when the image is printed.

Wow, a LOT of possibilities presented here, TY everyone. When I have time later I will work through all of these and get back with ya all if I need more assistance!

Mahalo, Mahalo,
Chiron Chrzan

Just so you know, it's not bleeding "around the corner"; it's bleeding from opposite edge to opposite edge. In other words, the pixels along the bottom are blended with those along the top, and the pixels along the right edge are blended with those along the left edge. The technical terms are tiling vs. clamping. SL tiles all textures. It clamps none.

To prevent the problem, you've got basically two options, which Ceera explained quite well. Either lower the repeat value a little bit in-world, or else pad the image with a completely transparent border in your paint program. Either way works just fine.



Atom, let me echo some of what Rolig said. Your general idea of working at a high resolution, and then downsampling just before output is good, but so you know, you're going about it in a pretty convoluted way. There are three issues with it. I'll explain.

First, as Rolig rightly pointed out, dpi is completely meaningless for anything but print. When you're working with textures, Web graphics, video, or any other totally on-screen imagery, the only thing that matters, size-wise, is the number of pixels. That's it. How many of them happen to fit into an inch is totally arbitrary.

Even the "standard" of 72 dpi (or more properly, ppi) is just a made up number. I realize they still teach it in Web design and graphic design courses, as if it's somehow relevant, but I can promise you it's not. Most modern LCD screens operate at anywhere from about 80 pixels per inch, to a much as 130 or so. CRT's can be even more variable.

And if you're talking projection, then everything is up for grabs. How big a pixel is will depend on how far away the screen is from the projector. Put the screen a couple inches away, and you might well be able to fit 72 pixels into one inch. But move the screen 50 feet away, and those same pixels might now each be several inches wide. Heck, move it far enough away, and get a powerful enough bulb, and you could conceivably reach 72 inches per pixel instead of 72 pixels per inch.

The figure of 72 barely had any relevance when it was first adopted as a standard, and these days it has absolutely none. It's certainly not anything "hard coded".


Second, regardless of whether or not there's any relevance in the inches (which I repeat, there isn't), you've got a much more important problem. When you go from "300 dpi" down to "72 dpi", you're not dividing evenly. Artifacting will be the inevitable result, even if you haven't been noticing it.

When you upsample that 512x512 from "72" to "300", you're creating a 2133x2133 canvas. Then when you downsize it again, you're dividing by roughly 4.17 on each dimension, or about 23.98 pervent. It's relatively difficult for the computer to decide how to interpolate 23.98 percent of any collection of pixels, as opposed to, say, half the collection, or a quarter of the collection, so the results you get are not as clean as they otherwise could be.

A better way to go is to think the same way the computer thinks, in powers of two, from start to finish. If you were to start your hi-res image at 2048x2048 instead of 2133x2133, then when you downsample to 512x512, you'd be dividing by an even 4, and you'd get much cleaner results.

Think not about pixels per inch. Think instead just about pixels.


Third, I'm a bit puzzled why you'd upsample before downsampling. Why not just start the image at the larger size right off the bat? It would save you a step.



In any case, not of this really has anything to do with the OP's problem. No matter what the image size, SL is always going to blend the pixels across the opposite edges by a few pixels. That happens in-world automatically, and is not at all related to how big or small one might think in image needs to be in order to get the "cleanest" possible alpha mask.

transparency is a 4th layer. Here, in opengl, it is handled as separate texture.
jpg compression makes the 2 textures barely fit.

You need to make the transparent part of the alpha-layer overlap further into the non-transparent part.
You also need to copy the visible parts of the RGB layers into the transparent regions.
There are scripts and plugins for that.

No, transparency is NOT a fourth layer. Transparency is handled in a channel (the alpha channel), not as a layer at all. You can make as many layers as you like -- thousands, if you wish -- and your final image, without transparency, will be a 24-bit file (8 bits for each of the three color channels - R, G, B). If you want to add transparency, you create another channel, thus adding another 8 bits of information to each pixel in the image.

Transparency is not a separate texture, either. It's all part of the single texture you are creating.

A digital image is simply an array of data elements. If you like, think of them as the dots you see on your TV screen if you sit too close, or as the dots in a half-screened picture in your newspaper. Each "dot" -- a pixel, actually -- contains information about its color, separated into three components -- red, green, and blue. It takes an 8-bit number to describe each of those color components. The data array for a pure white pixel, for example, looks like <255,255,255>. Adding transparency is just a matter of adding another "color," making each pixel in the data array have four 8-bit components instead of three. A white semi-tranparent pixel is then a 32-bit element that looks like <255,255,255,0.5>.

Each pixel's RGB numbers are derived by combining the values on all layers in your design. Again, if you think of viewing your design in Photoshop (GIMP, PSP, whatever...) as a huge array of dots, the RGB value for each dot is a description of the color your eye sees when it looks down at the collection of all visible layers. Your eye doesn't see the layers themselves -- only their combined effect on what is visible from a bird's-eye view.

The part that confuses some people is that your eye does NOT see the extra 8 bits of information for each data element that are stored in an alpha channel. To see those extra 8 bits, you have to actually open the channels palette, where the R,G,B and A information is all displayed.



No. JPG compression doesn't have anything to do with it. As Ceera and Chosen have explained, the problem is simply that if your uploaded image fill the entire face of a prim, then pixels on one side of the image blend with pixels on the opposite edge. Essentially, they are trying to tile. You get around that problem by reducing the size of the image slightly so that it doesn't fill the entire face.

It depends on your definition of "as a separate texture", I think, and on whether you're talking from an image creation standpoint or from a final rendering standpoint. In terms of the creation of an image, of course every element of any given image is inherent to that image. Nothing is "separate" in that sense.

But in terms of rendering, it could be thought of differently. I don't pretend to know all the technical ins and outs of it, but my understanding is that transparency requires a separate render pass. So you could in that sense sort of kind of call it a "separate texture" since it does get rendered somewhat independently from everything else. This may be what Ollj meant, although I don't want to speak for him/her.

Yeah, well maybe, although I think it's more confusing to think about the rendering process than to focus on either the creation process or the final product. How the RGBA value for each pixel is loaded during rendering is interesting from a technical point of view, but in the end a pixel array is a pixel array.

Ceera, thanks a lot for this and also Atom, it is what I needed and it definitely gets rid of those ugly lines, now my trees and privacy walls can be beautiful!

For anyone else coming across this thread, be sure to de-select "Stretch Textures" on the prim or this does not work!

Thank you everyone else for the other related and excellent information. My experience is mostly in web design, development, programming etc, so the targa files and their alpha channels is a bit unfamiliar, but seems everything important one eneds to know about that is all right here, so I will be studying and learning from this thread on those!


Mahalo, Mahalo, Mahalo
Chiron Chrzan

I guess the bottom line is my plugins for Photoshop look like crap at 72dpi. They are only really rendered properly at a really high resolution. And yes, I am a graphic designer, so maybe I am just used to working at print sizes. One does what they know I suppose.