Odd behavior of image quality

When an image is uploaded, it is compressed to cut down on the overall file size. This helps to download images quicker for people who need to see that image on a prim. The problem that I have with this is that I do not have control over this compression for large images. As more compression is applied, the image losses more of its quality.

For smaller images, I am provided with a check box labeled, “Lossy”.  I am either losing a lot of quality, or none at all. This check box for smaller images was made available after people complained about the lack quality of uploaded images being used for sculpties. Sculpties are prims that have their mesh defined by an image. Accuracy becomes a very high priority with sculptured images. Since sculpty images are essentially images of data, the original data is mutated through this compression.

Smaller images are fine now, but larger ones still have problems. “Lossy Compression“, as it is called, is originally meant to be able to allow you to reduce the file size of an image, but still retain the same quality of the original. Often a graphic artist will adjust this by eye until they can start to notice changes. Since the process is automated, I have no control over this.

Most large images are fine for this compression because they are photographs or contain gradients. These work best with Lossy Compression. However, when an image contains text or data, Lossy Compression becomes a nightmare. Imagine if you saved a text document of your thesis for school, uploaded it, and found that the schools website compressed it so that the words were changed into synonyms that didn’t make sense in the context given, or missing a letter here or there just to save space.

The reason behind my problems is just that. I tried in the past to automate uploading large image with RSS data. My attempt was to put 9 pictures on this image and clip the texture to show only 1 picture at a time, thus cutting down on the file size needed to download 9 individual images, and reduced download time swapping between each image. I had everything done. A bot was setup to pull the most recent articles from an RSS feed, compose them into an image, and upload them. The problem came with the quality of the images themselves after being uploaded. The text was very hard to read, and appeared as if it hadn’t finished downloading yet.

Animated Progress Bar

Original Animated Preview

This brings me to my problem from this weekend. I tried to make a progress bar consisting of 100 images within one large image. Rather than have the end-user download 100 individual images as a task progressed, I would show one portion of a larger image. It was a tedious process to create each individual frame to represent the progress. In the end, I had converted it to a GIF animation to verify everything had looked fine before uploading the grid of images. I saved my image as a bitmap file, so that their would be no question on my end that I may have performed some compression before uploading. Even the image preview looked fine. When I went to use the image in-world, I could not make out any of the text in the image. I did wait until the “Loading…” text disappeared in the texture under the texture tab.

I found that when I saved the image back to my hard drive, the image then appeared crisp in second life, and the image on my local hard disc was similar to the original. I could still make out little bits of differences due to compression. This is starting to lead me to believe that the Second Life servers are storing something close to the original images, but choosing to send a highly compressed image instead. This becomes a problem, because people are not going to be looking at my prims, and then saving a copy of the image displayed to their local hard drive in order to see it clearly.

When I first started writing about this, I thought it would be great if we could choose the amount of compression that is applied to our uploaded images. However, it seems that compression may be done on the fly in the back, each time an image is requested. I’m scratching my head over this one. I simply wanted to be able to display a nice graphical progress bar, but the constraints are getting in the way. Why does the Second Life viewer state that a texture is done loading, when it is not? Is it still downloading? Why is the quality so horrible until you save it to your local hard drive?

5 Responses to Odd behavior of image quality

  1. I was having this same problem this week uploading clothes textures with a very subtle tone-on-tone patterning. The uploaded textures were losing all the patterning. I wound up reuploading them the next day, and about half of the new ones were fine, but the other half had the same loss. Its really frustrating.

    I posted some pictures of it in this plurk thread
    http://www.plurk.com/p/20vvlz

  2. Lewis Moten says:

    Yes. I’ve had this same problem on specific portions of avatar skins and clothing, where precision is necessary. The additional problem with clothing/skins is that the client seems to be re-baking them constantly, and sometimes at different qualities.

  3. When you use a second prim anyways to contain the texture of the progress bar, why not make the progress bar a prim itself?you could even sacrifice some fancy look and make the prim-progress-bar in a simple color with no texture – this would speed up the whole rezzing process tremendously.

  4. Lewis Moten says:

    @Peter Stindberg: The idea is to make a 1-prim server. Just sticking with colors only, no images, degrades the quality. I’ve used other methods in the past for my graph charts that I may look into.

  5. OK, then I misunderstood what you said. I thought they were 2 prims already.

%d bloggers like this: