Jump to content

RGB8 or RGB16?


Soul Balazic
 Share

You are about to reply to a thread that has been inactive for 844 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

The file sizes of 8-bit and and 16-bit images are not the same. This is easy to see for example by creating new solid background images in Photoshop:

• 512 x 512 / 8 bits per channel: file size is 0.75 MB (without alpha channel)
• 512 x 512 / 16 bits per channel: file size is 1.50 MB (without alpha channel)

So, a 16-bits per channel image has two times bigger file size than a 8-bits per channel image has. However in Second Life the file size of the texture on your disk has no relevance. The images are used as textures inside SL which your graphics card renders on your screen. The graphics card does not know what a file size is, and the file size on disk has no meaning to it at all. Only thing that matters are the pixel dimensions of the image. The bigger the pixel dimensions are the more it consumes system resources (i.e. SL server resources and  your computer resources).

Texture sizes supported in SL are listed here:
http://wiki.secondlife.com/wiki/Texture_sizes

Use only those supported sizes. If you use any other sizes, then in import SL resizes your texture to the nearest one it supports and some information in the texture gets lost (result: the texture is not any more as sharp as it was originally).

Second Life does not support 16-bits per channel images. So if you created/edited your texture in 16-bit mode, before saving the final file change the mode to 8-bit mode first. Then save the file in lossless file format; either TGA or PNG. There is no reason at all to use lossy JPG format. Second Life uses internally JPEG2000 file format which is lossy format. So if you upload as JPG then your original file gets compressed twice (first in JPG then in JPEG2000). Whereas using lossless format (TGA and PNG) the file gets compressed only once (in JPEG2000).



Ok then, are there any advantages using 16-bit mode instead of 8-bit mode when creating/editing textures?

When creating texture there could be some advantages using 16-bit mode. For example if the image is heavily edited the gradients stay smooth. Whereas in 8-bit mode the gradients may end banded if the image is edited heavily.

More information about 16-bit vs. 8-bit for example here:
http://www.photoshopessentials.com/essentials/16-bit/

 

  • Like 2
Link to comment
Share on other sites

Please note that you cannot upload JPEG2000 files to Second Life (even though it internally stores them as such). And Second Life does not support 16-bits per channel images.

http://community.secondlife.com/t5/English-Knowledge-Base/Uploading-assets/ta-p/700165 says:

"Supported image formats"

"Second Life supports TGA (32-bit supports alpha channel), PNG (24-bit supports alpha channel), and BMP. When you upload an image, the Viewer internally converts it to JPG2000 for optimized future transmission. For best quality, try to avoid uploading JPGs; their already-compressed quality degrades further because of the double conversion."


So for best results in uploading use either TGA or PNG files (8-bits per channel).

PS.
It is possible to upload also JPG files (not JPEG2000), but as said it is not good use lossy file format in uploading.

 

  • Like 2
Link to comment
Share on other sites

  • 8 years later...
On 1/10/2014 at 11:44 AM, Coby Foden said:

Please note that you cannot upload JPEG2000 files to Second Life (even though it internally stores them as such). And Second Life does not support 16-bits per channel images.

http://community.secondlife.com/t5/English-Knowledge-Base/Uploading-assets/ta-p/700165 says:

"Supported image formats"

"Second Life supports TGA (32-bit supports alpha channel), PNG (24-bit supports alpha channel), and BMP. When you upload an image, the Viewer internally converts it to JPG2000 for optimized future transmission. For best quality, try to avoid uploading JPGs; their already-compressed quality degrades further because of the double conversion."


So for best results in uploading use either TGA or PNG files (8-bits per channel).

PS.
It is possible to upload also JPG files (not JPEG2000), but as said it is not good use lossy file format in uploading.

 

Thanks Coby, I always learn the most out of your answers, even if usually too late (after I finished a file with a mistake.. ;) )

I wonder if working in 32 bit format in photoshop, and then save it as 24 bit png (I need to keep transparency, so no tga, right?) will give better results on heavy detailed designs?

And if you can give me advice on the right settings for a big, heavy detailed texture, with text in it, to be used on a near monitor size prim attached to center hud (I'm trying to design a newsletter for our group, but no matter what I try the image get a bit blurred and the text is not clear.

Thanks

Link to comment
Share on other sites

6 hours ago, Loly Sirnah said:

And if you can give me advice on the right settings for a big, heavy detailed texture, with text in it, to be used on a near monitor size prim attached to center hud (I'm trying to design a newsletter for our group, but no matter what I try the image get a bit blurred and the text is not clear.

You need to make your texture as 24 bit - that is RBG 8 -  and not jpeg but apart from that file format doesn't matter for sharpness; png, tga and even bmp are all the same. Working with a higher number of bits only complicates matters. It will never improve the end result and may reduce the final image quality.

What does matter though, is the scaling algorithm. Your best bet for a texture that only contains text is probably not to scale the textures at all, work with 1024x1024 size right from the start (yes, this is one of the very few cases where even I would recommend 1024x1024 textures). The second best option is probably to work with 2048x2048 images - that's the highest resolution the uploader accepts as the input - and let the uploader do the scaling for you. I don't know which algorithm it uses but it's a very good one.

However, if you work on an oversized texture and scale it down before you upload, be careful which scaling algorithm you choose. Which options you have depends on what image software you use but here are examples of five different ones used to scale a 96 pt Times New Roman text down to 1/8th of the original size:

bilde.png.e2e84d50b1385eed494fa2798c74c1f4.png

I suppose you notice the difference. ;)

Fant and super sampling are usually (no rules without exceptions) the best ones but may not be options for you, fant because it's a Microsoft secret and only available on a few image editors, super sampling because it's very processor heavy and rarely found until very recently.

Another factor to consider is the font. A plain sans serif font will always scale better than a serif one and a plain serif better than a fancy ornamental one. Here's the same scaling algorithm illustration with Arial instead of Times New Roman:

bilde.png.70768749b74ca8c63e0e18b7339bc338.png

Much more readable right away.

For the other extreme option, here's a fancy ornamental font (Bodoni Classic Chancery) scaled the same way:

bilde.png.85e65aca8678478d8329c7a779e231cd.png

Hmmm... that actually worked much better than I expected but still, if you want compact but also easily readable text, use simple fonts.

---

With all that being said, keep in mind that no matter what you do, you can only expect to have about 800-900 pixels to play with vertically. This is a hardware limitation so there's nothing we can do about it. No matter how you do the design, if you are trying to squeeze more than 50-60 lines of text onto the screen at the same time, you are asking for trouble. Even 50 is pushing the limit of what many people will find readable.

Edited by ChinRey
  • Like 1
Link to comment
Share on other sites

5 hours ago, ChinRey said:

You need to make your texture as 24 bit - that is RBG 8 -  and not jpeg but apart from that file format doesn't matter for sharpness; png, tga and even bmp are all the same.

I just want to stress this.

All three file formats have lossless compression. All three can handle an alpha channel (a.k.a. a 32bpp image, or RGBA).

There is a persistent myth that you have to save in TGA if your image has an alpha channel because PNG doesn't support it or doesn't save it right. What I think happened is that someone, somewhere, many years ago, used some image software that behaved differently when it exported TGA vs. PNG files, and that morphed into "PNG doesn't work right".

Now, it is the case that some editors will zero out the R, G and B values of fully-transparent pixels during export (mostly because it helps with compression). You usually don't want to do this because it creates artifacts around the borders of the non-transparent parts of the texture in SL. This isn't an inherent difference between TGA and PNG, though, and hopefully your editor has an option to turn it off. (I know GIMP does.)

  • Like 1
Link to comment
Share on other sites

24 minutes ago, Quarrel Kukulcan said:

Now, it is the case that some editors will zero out the R, G and B values of fully-transparent pixels during export (mostly because it helps with compression). You usually don't want to do this because it creates artifacts around the borders of the non-transparent parts of the texture in SL.

This is of course way off topic for this thread but since you mention it.

It's usually a good idea to have a single color for all the 100% transparent pictures but yes, it shouldn't be all black but rather a color to match the neighbouring opaque pixels. Take this traffic sign for example:

bilde.thumb.png.6086c3e85ea625df50793ce29262c993.png

Here it is with alpha set to none:

bilde.thumb.png.ffe2417f8100e43cbe2254eaa9522725.png

As you can see, the black is bleeding onto the visible parts of the texture.

However, if I change the transparent color to the same as the sign frame:

bilde.thumb.png.69d703ada64dd1255cb44daab9e2ea01.png

and of course add some transparency again:

bilde.thumb.png.1b06840873922c3699a1b045632a8d3c.png

Problem solved! ^_^

 

  • Like 1
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 844 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...