Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

Best format to save a pic for uploading?

oliver Prototype
Registered User
Join date: 19 Jul 2004
Posts: 96
07-26-2004 01:17
Hi what is the best format for saving something on paint to upload onto sl?
Siobhan Taylor
Nemesis
Join date: 13 Aug 2003
Posts: 5,476
07-26-2004 01:45
if it uses transparency, .TGA
if not, .BMP

Under No Circumstances use .JPG unless that's all you can use... and in that case set the quality options to maximum... SL will recompress to JPEG2000 and the last thing you want is two rounds of lossy compression on your file.
_____________________
http://siobhantaylor.wordpress.com/
Loki Pico
Registered User
Join date: 20 Jun 2003
Posts: 1,938
07-26-2004 02:27
I never have problems uploading .jpg files. Thats all I upload, they are much smaller files than .bmp and load faster. I dont know Siobahn means about double compression, they look and work fine for me. You have a more in depth explanation about this?
_____________________
Siobhan Taylor
Nemesis
Join date: 13 Aug 2003
Posts: 5,476
07-26-2004 02:35
Loki, jpg is a lossy compression algorhythm ...

Therefore, when you save a file as a jpg after editing, some data is lost. You can adjust the amount of degradation in most graphic editors so it still looks ok.

When you upload, it's reformatted into another lossy compression format, and recompressed. This time, you have no control over the quality...

Effectively, if you upload a .jpg, you get two lots of say 20% degradation in the image. Whether it's obvious to you when you see it or not, I wouldn't know... it's going to be different for everyone...

Hope that helps,

Sio.
_____________________
http://siobhantaylor.wordpress.com/
Loki Pico
Registered User
Join date: 20 Jun 2003
Posts: 1,938
07-26-2004 02:41
Thanks Siobahn, I get it. I guess the difference is very marginal in my case and I have never really noticed much of a difference. The digital camera files I upload originate as a .jpg, so I guess the first step of conversion loss does not apply since I dont specifically convert to .jpg to upload.
_____________________
Adam Zaius
Deus
Join date: 9 Jan 2004
Posts: 1,483
07-26-2004 03:06
Keep in mind however, the doubly compressed image will load quicker for SL viewers. I use 80-93% quality JPG from Photoshop for all my texture work, unless an alpha channel is required, in which case 32bit TGA is chosen. :)

-Adam
_____________________
Co-Founder / Lead Developer
GigasSecondServer
oliver Prototype
Registered User
Join date: 19 Jul 2004
Posts: 96
thanks
07-26-2004 04:05
thanks guys that helped lots.
Azelda Garcia
Azelda Garcia
Join date: 3 Nov 2003
Posts: 819
07-26-2004 06:46
Kindof off topic but...

How are the images streamed over the WAN? I assume it's some sortof wavelet algorithm? Are there libraries available to do this?

Azelda
Kurt Zidane
Just Human
Join date: 1 Apr 2004
Posts: 636
07-26-2004 12:42
Could some one correct me if I'm wrong... But this is my view on bmp vs jpeg.

To me there are 3 types of image files. Losses, lossy, and raw. Lossy and loss less are two different styles of compressing an image. While a raw file contains little or no compression. Raw files are the most basic of image files. Usually a raw file consists of the images dimensions, followed by a pallet of colors, and then finally the image. Each pixel being store separately.

bmp's, also known as dib's, is a raw format. It is typically confused as a lossy format because it has a bit labeled compression. Witch really should have be labeled image format. Because it refers to four possible state of formating inside a bmp file. The four styles of formating in a dmp are 0,1,2 and 3. 0 stand for no compression. 1 stand for 8 bit run length encoding, 2 stand for 4 bit length encoding, and 3 stand for RGB bitmap with mask.
Can you guess what a bmp file consists of? I'm going to tell you. First the image size, witch is part of the file header. Then a pallet of colors, followed by the image. The image is store one pixel at a time, each pixel being stored separately.
I guess you could call it lossy, because it uses no compression, and thus dose not corrupt the image over multiple saves. But it is possible to lose data, say if your saving from a photo shop file, witch can contain more information. If people would stop referring to bmps as it as loss less, that maybe other people would stop thinking bmps use compression.
btw weird factoid bmp start at the bottom of the image, and end at the top. So if you read the file by hand. you would find the image is upside down.

While it is true that saving a bmp to a jpeg causes degradation. The opposite is not true, at least it shouldn't be. Saving a jpeg as bmp should cause no degradation. But it will still contain the distortion of the original jpeg file.

There are some advantage with jpegs. They take less server space, they also take less time to re transmit. Witch benefits the user. It means linden lab dose not need as much server space, or band with. Witch lower their cost of bossiness. It also means people playing sl get more image at a faster rate. Witch is why it dose not make sense for the server to convert jpegs to bmps. Especially when the client can convert the images after they down load the jpeg.

When to use jpegs, and when to use bmps. My personal view is this. Small images should be automatically save as bmps by the user. I'm talking really small textures. Basic image like a stop sign, an icon, should be saved as a bmp, because the distortion in jpegs would be noticeable. Jpegs compression is designed for complex textures. Any thing that's going to be stretched, has complex little details that is important, or need to have crisp text should also be saved as bmp.
Large images file, photos, some textures, and gradient maps can be usually be saved through photo shop as gifts with out any visible distortion. With will allow your area to load faster. Causing less lag.


if there really is some distortion happening. It's probable a bug. Unless it's some thing going on between the converted bmps and the build in compression possible with modern video cards.
Chip Midnight
ate my baby!
Join date: 1 May 2003
Posts: 10,231
07-26-2004 13:49
The format you choose to upload really doesn't matter as far as file size once it hits SL. The files are compressed as jpg2k on upload and the original file is discarded.

Personally, unless I need an alpha channel, I always upload jpgs saved at maximum quality. While there is some data loss even at max quality it's not enough to notice. You could upload a max quality jpg and a bmp of the same image and you wouldn't be able to tell them apart in SL.
_____________________

My other hobby:
www.live365.com/stations/chip_midnight
Siobhan Taylor
Nemesis
Join date: 13 Aug 2003
Posts: 5,476
07-26-2004 13:54
at max quality, Chip, you're right... but then there's little or no file size benefit either...

but a jpg at say 80% will then be re-compressed to jpg2k at (for sake of arguement) 80%... the texture is now at 64%
_____________________
http://siobhantaylor.wordpress.com/
Lash Xevious
Gooberly
Join date: 8 May 2004
Posts: 1,348
07-26-2004 19:47
the huge difference for me between jpg's and bmp's is their file size in my computer. so far all my files that require no transparency are jpg's. i have never uploaded a bmp. the quality still looks fine but i do notice certain details lost. and i figure i would notice it because i made it. but for someone who just walked into my build and saw the textures, they probably won't tell which is missing or distorted.

but when it comes to providing images for places like in our profile, our land pictures, fave list, i stick to the bitmap pictures i take in SL. The one time i converted a "save to disk" into a jpg was a waste of 10L upon uploading. Once I placed it in the profile box or wherever, everything was fuzzy. So I don't recommend using jpg in those places.
_____________________
Davo Greenstein
Dag from Oz
Join date: 22 Dec 2003
Posts: 150
07-26-2004 20:06
Hmmm

Havent used BMP yet..Jpg seems to give great detail.

I personally save Jpg's at compression 12 (photoshop option)

and make an effort to bring in files at resolutions of the power of 2 (128 X128) (512 X 256) etc as this was recommended in another forum thread.

TGA definately for Alpha.

Harddrive space is so cheap now I dont bother with compression.

But I have a question ..If SL converts files to JPG2 why do they only export as TGA ? I have people send me pics for website and find it time consuming to convert to Jpg before I add them to the website.

Also I guess the purpose of the texture can dictate the quality settings.

If I make a 10m X 10m square and add a texture does it have to be more detailed than If I place on a 1m X 1m square ? I have heard that the display of textures does not have a "native" resolution so it is neither stretched at 10m nor shrunk at .01m ????? i dont get this though.

If I want a crisp image displayed exactly like I see it in photoshop do I need to match the image to the object ???
eg image 128X128 would be crystal clear on object face 1.28m X 1.28m or will it display just as clear on 1m X 1m ???

Also (yipes)

if the template files are say 256X256 if i increase the image resoluion to say 1024X1024 before uploading will I get increased detail ???? I ask this as I want to have more detailed tags on clothing items..I cant read small text on my current ones

*looks at post ..ummm off topic much Davo ???
Adam Zaius
Deus
Join date: 9 Jan 2004
Posts: 1,483
07-27-2004 02:23
BMP, is a compressed (lossless) format actually; not RAW. It uses RLE compression. There are very very very few raw formats, becuase even the most primitive compression can knock huge chunks off the filesize. :)

-Adam
_____________________
Co-Founder / Lead Developer
GigasSecondServer
Carnildo Greenacre
Flight Engineer
Join date: 15 Nov 2003
Posts: 1,044
07-27-2004 22:15
The only thing JPEG2000 has in common with JPEG is the letters J, P, E, and G. Very few programs can handle JPEG2000 files right now, while almost everything supports either JPEG or TGA files.

BMP can be uncompressed or RLE compressed, just like TGA, and most BMP files are uncompressed.
_____________________
perl -le '$_ = 1; (1 x $_) !~ /^(11+)\1+$/ && print while $_++;'
Kurt Zidane
Just Human
Join date: 1 Apr 2004
Posts: 636
07-28-2004 15:13
If they were using jpeg2000 there would be no degregration right?
Mac Beach
Linux/OS X User
Join date: 22 Mar 2002
Posts: 458
07-28-2004 17:56
Point of information:

Compression and lossyness are only related in any way because the primary lossy storage mechanism (JPG) happens to also do compression. There is no TECHNICAL reason for this. They use a floating point algorithm to do the compression and the loss is INTENTIONAL. The idea is that every time you change the image and re-run it through the conversion process the image will get slightly altered (typically made worse, unless your goal is some psychedelic effect). This all has to do with copyright protection etc., otherwise they could have defined the algorithm using fixed point methods and the compression would be completely reversible.

So, if your digital camera only produces JPG files and you are never going to tinker with them fine. Otherwise, any file you are planning to edit, particularly if you are going to edit it repeatedly, should be stored in some format other than JPG.

As stated in a previous post, the format you upload with has no impact on in-world viewing speed etc. (Although, I think the SIZE in pixels of the file you upload may affect in-world viewing). For things viewed up close, the more pixels the better (I don't know what the upper limit is these days), for things only viewed from a distance, smaller is better. One trick that I know (that I haven't seen documented recently) is for low resolution textures, you can actually combine several textures into a single image and use the offset and cutoff values for the object to only display the part of the texture you want (EG: a single file with 4 textures in quadrants can be used by 4 different objects.) The advantage in doing this is that the texture just gets downloaded once and will make subsequent objects using a different part of the physical texture file show up faster.
Carnildo Greenacre
Flight Engineer
Join date: 15 Nov 2003
Posts: 1,044
07-28-2004 23:46
From: someone
Originally posted by Mac Beach
Compression and lossyness are only related in any way because the primary lossy storage mechanism (JPG) happens to also do compression. There is no TECHNICAL reason for this. They use a floating point algorithm to do the compression and the loss is INTENTIONAL. The idea is that every time you change the image and re-run it through the conversion process the image will get slightly altered (typically made worse, unless your goal is some psychedelic effect). This all has to do with copyright protection etc., otherwise they could have defined the algorithm using fixed point methods and the compression would be completely reversible.


Dead wrong.

The floating-point roundoff errors are a very minor component of the quality loss, and are an inevitable consequence of the discrete cosine transform process used by JPEG.

JPEG compression 101:
Step 1: Convert the image from RGB to YUV. This separates the brightness of pixels (the Y component) from the color (the U and V components)
Step 2: Downsample the U and V components to half the original resolution. The human eye is more sensitive to brightness changes than to color changes. This step can be skipped if you want higher quality
Step 3: Break each component of the image up into 8x8 pixel blocks.
Step 4: Perform a discrete cosine transform (related to a Fourier transform) on each block. This converts the data from a block of pixels to a set of cosine waves.
Step 5: Discard the higher frequency waves. The JPEG quality setting determines how many of the high frequencies to discard.
Step 6: Compress the resulting data using a lossless method like LZW or Huffman coding.

Most of the quality loss and compression comes from steps 2 and 5, while what you're describing is the floating-point roundoff error from step 4 -- a very minor component, affecting maybe one pixel in a thousand. Further, an image compressed at 100% quality is visually indistinguishable from the original, even after hundreds of rounds of compression, as roundoff errors tend to settle down after the first few times.
_____________________
perl -le '$_ = 1; (1 x $_) !~ /^(11+)\1+$/ && print while $_++;'
Kurt Zidane
Just Human
Join date: 1 Apr 2004
Posts: 636
07-29-2004 08:54
You two do realise I was asking about jpeg2000 and not jpeg right? They are two diffrent formats.
Mac Beach
Linux/OS X User
Join date: 22 Mar 2002
Posts: 458
07-29-2004 11:36
From: someone
Originally posted by Kurt Zidane
You two do realise I was asking about jpeg2000 and not jpeg right? They are two diffrent formats.
Yes. I agree with earlier posts that Jpeg2000 used internally by SL is lossless (or at least I haven't heard otherwise). So if you have an image manipulation program that works exclusively with JPEG2000 you are probably OK.

Thanks Carnildo for the more accurate description of the process. The point of my message was not so much the "how" of the loss, but the "why", which is that it was designed that way to have the same properties for photos that cassette tapes had for audio, namely to allow modified pictures to be distinguishable from the originals. In other words, the lossyness is a feature, not a bug.

I store my photos in JPG format all the time, because I have no need to modify them, unless once in a while I e-mail a cropped or downsized image to someone, in which case I am always working from the original.

For texturing work for something like SL I would always try and keep an original version of the texture in BMP, TIFF or some other lossless format. If you can't stand the space they take up, burn them to CDs (not a bad idea anyway to have them all backed up in one place).

Here is a FAQ that looks fairly authoritative regarding JPEG:

http://www.faqs.org/faqs/jpeg-faq/part1/

From Item 10: "It would be nice if, having compressed an image with JPEG, you could
decompress it, manipulate it (crop off a border, say), and recompress it
without any further image degradation beyond what you lost initially.
Unfortunately THIS IS NOT THE CASE. In general, recompressing an altered
image loses more information. Hence it's important to minimize the number
of generations of JPEG compression between initial and final versions of an
image.

There are a few specialized operations that can be done on a JPEG file
without decompressing it, and thus without incurring the generational loss
that you'd normally get from loading and re-saving the image in a regular
image editor. In particular it is possible to do 90-degree rotations and
flips losslessly, if the image dimensions are a multiple of the file's
block size (typically 16x16, 16x8, or 8x8 pixels for color JPEGs)."


Also From Item 10: "The bottom line is that JPEG is a useful format for compact storage and
transmission of images, but you don't want to use it as an intermediate
format for sequences of image manipulation steps. Use a lossless 24-bit
format (PNG, TIFF, PPM, etc) while working on the image, then JPEG it when
you are ready to file it away or send it out on the net. If you expect to
edit your image again in the future, keep a lossless master copy to work
from. The JPEG you put up on your Web site should be a derived copy, not
your editing master."

From Item 13: "It's worth repeating that cranking a regular JPEG implementation up to its
maximum quality setting *does not* get you lossless storage; even at the
highest possible quality setting, baseline JPEG is lossy because it is
subject to roundoff errors in various calculations. Roundoff errors alone
are nearly always too small to be seen, but they will accumulate if you put
the image through multiple cycles of compression (see section 10)."

And: "Many implementations won't even let you get to the maximum possible setting,
because it's such an inefficient way to use regular JPEG. With the IJG JPEG
software, for example, you have to not only select "quality 100" but also
turn off chroma downsampling to minimize loss of information. The resulting
files are far larger and of only fractionally better quality than files
generated at more reasonable settings. And they're still slightly lossy!
If you really need lossless storage, don't try to approximate it with
regular JPEG."
Carnildo Greenacre
Flight Engineer
Join date: 15 Nov 2003
Posts: 1,044
07-30-2004 00:03
From: someone
Originally posted by Mac Beach
Thanks Carnildo for the more accurate description of the process. The point of my message was not so much the "how" of the loss, but the "why", which is that it was designed that way to have the same properties for photos that cassette tapes had for audio, namely to allow modified pictures to be distinguishable from the originals. In other words, the lossyness is a feature, not a bug.


The "why" has nothing to do with copyright, and everything to do with the design requirements for JPEG:

1) Given a photograph, it had to produce a file that was practical to transmit over a 9600-baud modem. No lossless compression technique at the time could do this for photographs, just for line art.
2) It had to be computationally inexpensive to compress and especially to decompress.
3) It had to support three-channel color at 8 bits per channel. No compressing by reducing the color palette.

The lossyness is a feature. The lossyness at 100% quality is a side effect of the process.
_____________________
perl -le '$_ = 1; (1 x $_) !~ /^(11+)\1+$/ && print while $_++;'
Ulrika Zugzwang
Magnanimous in Victory
Join date: 10 Jun 2004
Posts: 6,382
08-01-2004 22:00
I prefer to use PNG files (pronounced "ping";). Not only do they support transparency but they employ lossless compression so they are easy on the hard drive and perfectly preserve an image. Additionally, they are compatible with all modern web browsers.

SL won't upload a PNG (yet), you say? Just export it to a tiff file before uploading and then delete the temporary file.

I should also note that the Gimp supports png, jpg, and the nonstandard tiff with the old-style transparency that SL requires. It's also free and runs on all OSs. It's perfect for SL. (Unlike PSP which is an abomination before all of humanity and possibly the animal kingdom as well.)

~Ulrika~
_____________________
Chik-chik-chika-ahh
Ace Cassidy
Resident Bohemian
Join date: 5 Apr 2004
Posts: 1,228
08-01-2004 22:08
From: someone
Originally posted by Ulrika Zugzwang
(Unlike PSP which is an abomination before all of humanity and possibly the animal kingdom as well.)

~Ulrika~


Awww... come on Ulrika... tell us how you REALLY feel about PSP.

- Ace
_____________________
"Free your mind, and your ass will follow" - George Clinton
Carnildo Greenacre
Flight Engineer
Join date: 15 Nov 2003
Posts: 1,044
08-01-2004 23:52
PNG doesn't work too well with photographs -- it usually produces a file 10-20 times larger than JPEG.
_____________________
perl -le '$_ = 1; (1 x $_) !~ /^(11+)\1+$/ && print while $_++;'
Ulrika Zugzwang
Magnanimous in Victory
Join date: 10 Jun 2004
Posts: 6,382
08-02-2004 14:44
From: someone
PNG doesn't work too well with photographs -- it usually produces a file 10-20 times larger than JPEG.

PNG uses lossless compression. It perfectly preserves the image and supports alpha layers at the expense of being larger.

JPG uses lossy compression. It degrades the picture quality permanently and does not support alpha layers, although it is smaller.

It's a trade off.

Most importantly though, once you go to JPG, you can never recover that information lost in the compression. That's why PNG is a great intermediate storage format, especially for SL textures.

~Ulrika~
_____________________
Chik-chik-chika-ahh
1 2