2B JPG or Not 2B

Should I change GIFs to JPGs before uploading?

You can't upload GIFs, so the answer would be YES.

-Ghoti

Thaks (I think)

So - anyone know of a MAC app that will load 100 gifs - convert them to JPG and not have me do save as for therest of the week

Thaks (I think)

So - anyone know of a MAC app that will load 100 gifs - convert them to JPG and not have me do save as for therest of the week

NO.

You should upload TGA files or BMP's.

Everything is converted to jpeg on the server, but garbage in garbage out.
You dont want a jpeg of a jpeg of a jeg, you want a crisp, optimised bitmap that is only converted to jpeg *once* by the asset server.

And you dont want to *work* in jpeg ever, use TIFF or PSD, but that is obvious.

Just use Photoshop actions and batch it. Pretty simple - just record saving one file out once as a jpg, and apply it as an action to a batch.

OK - so these files are GIFs (with some transparencies apparently) and I didn't create them so don't have much say

So you are saying if I upload them as GIFs the servers will converte them for me? How bad/good will that be?

I have every football teams badge/emblem Attached example (manchester united because of audience)

What would be the outcome of uploading them as is.

You're half right. Everything in SL is converted to Jpeg2000, not jpeg. Huge difference.

The part you're right about is that TGA is the format to use, and jpeg really should be avoided. Jpeg is a poor choice because it is a low quality, lossy, highly compressed format. Every time a jpeg image is opened and closed, it loses a little bit. Upload it to SL, and it's even worse because it ends up getting compressed twice. You end up with the "copy of a copy" effect, and your images look terrible. Also jpeg doesn't support transparency. Jpeg is intended for the web, where speed is much mroe important that image quality. Using it for any other purpose is highly inadvisable.

TGA on the other hand is the number one most commonly used format for 3D graphics applications. It is uncompressed, and offers superb control over coloring and transparency. I never use any other format in my on-screen work, and I have yet to meet a 3D artist who says anything different.

As for the other formats that have been metioned:

GIF - Like jpeg, this is a web format, highly compressed, and very lossy. Unlike jpeg, gif does support transparency, and animation, but its image quality is atrocious. Don't use it for non-web applications. As has been mentioned, SL does not read gif anyhow.

BMP - Like TGA, this is an uncompressed format, so its image quality is good. However, bmp does not support transparency, making it a poor choice for SL.

TIFF - This is a great format for images intended for print. It is uncompressed, supports layers, and CMYK. It is ideal for print, but not well suited for the screen. TIFF is not a great format to work in for images itended for SL.

PSD - This is Photoshop's native format. For screen images, it's best to work in PSD until the final output to TGA. For print images, PSD is good, but TIFF is better, so if an image is intended for print, it's best to work in TIFF right from the start.


Edit: I almost forgot to post my standard word of caution. When outputting to TGA, do not save as 32 bit unless you need transparency in your image. Use 24 bit TGA formatting, always, unless you need to be able to see through part or all of the image. It's common among those new to texturing to assume that more bits must somehow be better than less bits. This is not the case. Images for the screen are made up of color maps known as channels, each of which constitutes 8 bits. Grayscale images have 2 channels, black and white, for a total of 16 bits in the image. Color images have three channels, red, green, and blue, for a total of 24 bits. Images with transparency have 4 channels, red, green, blue, and Alpha. Never give an image an alpha channel unless it needs one. Unnecessary channels increase file size, cause problems with the way textures interact with eachother, and restrict some functionality in SL (like shine, for example).

SL will only allow you to import TGA, BMP or JPG. That's it. If you have a GIF, you'll have to convert it to one of those formats before you import.

If you're intending on a Transparency, your options are even more limited. 32-Bit TGA is the only format that works for transparencies.

-----

Dianne - Question - I didn't realize it was better to import as BMP/TGA first, and let the server convert to JPEG. I was always under the impression that BMP files were WAY bigger - and would add to lag if the clients had to download these huge files. Or is that wrong?

I use Animated textures on my dancefloor that are 256 x 256 JPG filmstrips. I think if I imported a 256 x 256 BMP the quality would be much better - but wouldn't that be a much bigger filesize for the client to d/l?

Inquiring minds want to know


Edit: Chosen - I was still typing when you posted your response. What say you about 'texture lag'? My goal - is to have the best quality textures with the least amount of lag

Well the images are already shite - so no problem. They are meant to be small shirt badges or emblems for things so they are pretty small. In the case of the ManU badge - it makes most English people puke anyway (Americans think of the NY Yanks and you'll get the idea - all money not style)

Thanks for all the information - big help

The answer Travis, is that the source file size becomes almost completely irrelevant after upload to SL. Once SL converts it to a jpeg2000, it's a jpeg200, regardless of what it started out as. You're correct that your filmstrips will be better quality if you start them out as BMP (TGA is even better) than if you start them as Jpeg. You won't notice any difference in inworld rez time, just the initial upload time, which obviously only happens once. Remember, the client is viewing the jpeg2000, not the BMP, TGA, or Jpeg.

Woo, fast moving thread. You're welcome. Always happy to help.

EDIT: Looks like I missed one of your questions. It must have appeared while I was typing. Like I said, fast moving thread.

The answer to what would happen if you upload them as is, is nothing because SL doesn't import GIF. The answer to what would happen if you batch convert them to jpeg, as Panda suggested is they'd all end up with a white background. To preserve the transparency, you'd need to create an alpha channel for each one, which will take time. No getting around that. You could try to record a universally applicable action for creating the alpha by magic wanding the white area in one image, selecting inverse, and paint bucketing the slection white in the alpha, but I'm not sure it would work out well for every image.

Well AFAIK the lag is caused on the download to the client, not the upload of the textures.

Soo.. since the server (I think) converts everything to jpeg 2000, the only real issue is the initial quality of the image and keeping it as pristine with as much information intact as possible before this dirty deed of conversion is done.

I suggested BMP, TIF, and TGA as good formats to work or upload in as they are "just the bitmap" no compression. If you save as jpeg, then you are compressing the file and throwing out information, then linden labs converts it again, and again possible compression-related loss of (some) information may occur. Most times this loss is hardly noticeable, but it is a good rule to follow anyway.

Needless to say, if you work on a jpeg and then save it as a jpeg and do this several times in a row, you are just making things worse. I always convert all jpegs and gifs to tiff or psd as the very first step, then you can work.

The other side of it is keeping them small. There is hardly *ever* a reason for any texture to be over 512 or even 256. Somethign that needs to be that big inworld is often constructed out of several prims anyway and the best bet is slicing the image up for each prim leaving several smaller textures, each under 512.

Disclaimer: Most of this I taught myself or "heard from someonone" in the three months I have been here, so I may have it totally wrong!

.

Thanks, guys! Incredibly helpful info!

Dianne, you're right about a good many things, but just a little off on some others. Let me explain:


Correct.


Mostly correct. As I'm sure you know, you can't upload a TIFF into SL, but even if you could, I'd still recommend not using it for SL purposes. As I said earlier, TIFF is ideal for print, but it's not the best suited for the screen. BMP is a simple on-screen format suitable for output as things like wallpaper, but it's not very practical for a working document since it doesn't support layers or transparency. For screen stuff, I always work in PSD and then output to TGA.


Correct, although I'm not sure why you'd want to start with a jpeg and then convert it to PSD unless it's an image you didn't make. Nobody in SL steals images off the web, now do they?


Your advice about keeping textures small is right on, except for the part about slicing large textures into smaller ones. A single 1024x1024 is 16 times the size of a 256x256. Using 16 individual 256x256 images takes exactly the same amount resources as one 1024x1024, so slicing up the big one into little ones doesn't change a thing except to add extra work.

To add a bit to your good advice about keeping things small just so everyone understands, one of the reasons frame rates in SL are so awful is because most users are bone headed about texture management. Go to any mall and look at the amount of 1024x1024 textures used on little 2-meter signs where a 128x128 would do just fine, and you'll see what I'm talking about. Every time someone does that, they're needlessly hogging 64 times, that's right, SIXTY FOUR TIMES the amount of resources they should be. Multiply that by a few dozen stores, each with tons of posters, and you'll understand why malls are so laggy. There are terrabytes worth of textures where there should be only a few hundred megabytes.

SL is amazingly good at blowing up small textures with no discernable pixilization. There's almost never any reason to use big canvas sizes. Don't take my word for it though. Make a 256x256 texture, and put it on a cube. Zoom your camera in so the cube takes up the entire screen. If you've got a 1024x768 monitor, you're now viewing your texture at 16 times the size it was created at. Notice how it looks just as good as if it were created at that size? That's one of the areas where SL really shines. Because of that, there's almost never any need to make big textures. The only exceptions would be on the rare occasions that you have to display small text or other minute details on your texture that would end up blurring or disappearing on a smaller canvas.

Good texture management consists of about 85% of the time using 256x256 or 128x128, 14% of the time using 512x512, and 1% of the time using 1024x1024. (Always work in powers of 2 if you haven't guessed that by now.)


Nah, you don't have it totally wrong. You've got mostly correct information with just a touch of misinformation here and there. You're doing great.

Yes. Check out GraphicConverter (http://www.lemkesoft.com/en/graphcon.htm). It is the best Mac shareware app ever made, and comes bundled with Mac OS X. There is a batch convert command that will do exactly what you want.

Wow,
Great advice!

I especially like the detail about the resource load and the (probably under-rated) drawing abilities of SL.

I think you kind of misunderstood me on a couple of points though so, for clarification I have to say that I suggested BMP, TIF, and TGA as good formats to work or upload in (and that's a direct quote).

As in, I work in TIFF but I dont upload in it of course.



Well here I just meant the obvious which is if your source is a jpeg then dont work with it in that format but work in PSD or, (my choice sometimes) TIFF format.



Again, here my point was the reverse, that if you *needed* to slice up a large image that stretched across several prims, that those pieces should be 512 at most. I did not imply that slicing textures into pieces would make them smaller overall or anything of that nature, at least I hope I didn't. thats crazy!


Well I wont get mad about this part, cause I am sure you just used the wrong word here and this *is* a "pat on the head" after all. ?!

Mis-information is the deliberate spreading of false rumours, which I am sure you dont want to accuse me of. You probably meant something closer to misunderstandings or misaprehensions I think.

All good advice from all quarters anyway, I wish I knew this stuff months ago.

.

I think you missed MY point, which is that there is NO point in slicing up a texture. You can stretch a single texture across as many prims as you like simply by doing the math on the repeats and offsets. For example, when I laid out the schematics for my USS Defiant, which is about 120 meters long and 80 meters wide, I laid a single 1024x1024 texture across seventy 10x10x.01 cubes. I simply set the repeats per face to .08 so that 12 instances of the texture would equal one complete whole from nose to tail at a size of 120 meters. After that, I just progressively increased the offset on each one by the same amount, so that the whole thing fit together to form a contiguous image.

Attached is an image showing how it was broken down. The black & white mechanical drawing is the actual texture I used, just reduced in size here. The light blue lines show how the prims were arranged. Each prim displayed 1/144 of the total image, but it was one image, not 144 small images.

There's no need to slice an image into pieces prior to upload because you can slice it into as many pieces as you want once its inworld.

http://forums.secondlife.com/attachment.php?attachmentid=18167&stc=1
Defiant-top-breakdown.jpg


I believe you're confusing the words "misinformation" and "disinformation". Misinformation simply means any information that happens to be incorrect. Disinformation means information that is deliberately misleading. Since I knew you were not deliberately spreading falsehoods, I used the correct word. In any case, yes, it was a pat on the head.

Okay, ... well I guess I could respond to this in detail, and then you might not listen to that, and then maybe you would find some other way to be smarmy and condescending about it back, but I dont really want to.

Besides which, your method is sloppy. You are so busy assuming you are right, you fail to actually check to see if you *are* right. And while all of your points are factually correct, you argue against straw men. For the most part, I dont really *have* the opinions you attribute to me, just before you so brilliantly(?) knock them down.

To me this seems a waste of my time.
I only answered because I wanted to offer help to a *respected* fellow SL'er.

(that person is not you)



*dianne reaches for mute... *

WHAT?!!!

I'm trying to help you. I'm sorry you feel the need to interpret that as "smarmy and condescending". I thought we were having an intelligent discussion here. I've complimented you, I've pointed out where you've given correct information, and I've offered help where you've appeared to need it. I really don't understand what you're upset about.

And believe me, there's nothing "sloppy" about my methods. If I haven't explained something in a way that you can best understand then I apologize, but I build and texture only in the ways that are most efficient. If you'd care to explain what exactly you think the "sloppy" part is, I'd be happy to clarify. If it turns out you know something I don't, then please explain, and I'll thank you kindly for the helpful information, exaclty as you had been thanking me up until this last post of yours.

Once again, I must repeat I am very confused here. I appologize if I inadvertantly offended you somehow. That was not my intent.