Image format theory
Originally posted by HankyTheXmasPooh with additions in brackets by Michael Wolf
 
- TIFFs can produce smaller files when there are contiguous horizontal bands of the same color, due to the way in which LZW compression works (this is also present in GIF).
 
- PNGs use [zlib/huffman compression which is a lot like LZW in TIFF], and produce smaller file sizes than TIFF/LZW on complex, noisy or textured (e.g. photographic) images, which tend to lack contiguous horizontal bands of the same color.
 
However, LZW is very processor efficient for both encoding and decoding, whereas PNG requires between 5 and 10 TIMES more processing for encoding, and closer to 5 times more decoding.
 
- JPEG, baseline optimized, at 100% quality is (for all intents and purposes) lossless; produces smaller file sizes across a wide range of image types (complex photographic textures, vs flat areas, vs smooth gradients); and is extremely processor-efficient for both encoding and decoding.

 

[JPEG is lossy (i.e. not 100% pixel accurate) even at 100% quality, unless one of the encoding steps is completely skipped (a scheme used by Matrox for their lossless compressing M-JPEG codec). I wouldn't use it for any kind of imagery within the pipeline, only at the end (input or output).]

If it is a complex, high-contrast, noisy, photographic-type b68 texture, then PNG may be able to produce a smaller file size compared to JPEG at 100% quality -- but if you can compromise even slightly (say, 90-99%) then you're likely to see a dramatic savings in file size.

 

[- (JPEG2000) is extremely cool. Not only does it offer true lossless compression, but it also allows for more than 8 bits per component as well as partial decompression. (Either only decompressing a certain area of the image, or only lower resolution). Unfortunately JPEG2000 is also a more complex then vanilla JPEG, and takes longer to en-/decode.

 

However, on current machines, I think you only really "feel" a difference in encoding algorithms when working with extremely huge images (4K and above).]
 
(...)
 
If you HAVE to have alpha channel integral to the file, then sure, PNG or TIFF or Targa are all decent options, and if file size is of primary importance, and you're working with complex, textured images (rather than flat areas of contiguous horizontal bands of color), then PNG is probably the best option.
However, if you have the option of breaking up the RGB and alpha information into two separate files, then recombining them elsewhere -- for example, Shake, After Effects, Photoshop, a custom imaging/compositing application (like the ones I used to develop ;), or modo -- then JPEG is totally an option; you just need to use two of them: one RGB JPEG for the paint/texture information; and one grayscale JPEG for the alpha information.

 

(...)

 
Of course, if you're concerned about quality of the textures, and you don't want even that 0.0002% degradation that comes with encoding a JPEG at 100% quality, perhaps another file format is for you.
In the context of modo, though, there will be plenty of sitautions (at least for me) where processing power is at a premium. So I'm not going to want to spe 5af nd 5-10 TIMES more processing power on encoding painted textures as PNG -- if this happens on-the-fly when you're working/previewing in modo. If modo's smart enough to keep that work in RAM, or in an application scratch file -- which could then be used to reconstruct missing data if a crash occurred -- then this wouldn't be a drawback. I guess we'll need to wait and see how this works.
 
I know that the 512x512 and 1024x1024 textures I've seen in the videos aren't even in the ballpark of what I'd expect to be creating. I'm used to creating and using fairly massive textures, über-high polycount models (I love EIAS :D ), etc. so when it comes to the difference in encoding times for PNG vs TIFF vs JPEG, then -- as in other situations -- size really does matter ;)

 

Image formats in practic use
Originally posted by Isurus¹ and grafikimon²
 
¹ I find that if I use JPG at 95%~ on photo-like images it will produce a much smaller size than a PNG. Only reason I would use a JPG at 100% is if I'm putting a photo into Flash and then would re-export it from there to my liking.

 

I have a large wallpaper (1660x1050), link below:

I opened up my PSD in photoshop and tested out different compressions and formats.

 

JPG: 95% = 727.3K
JPG: 100% = 893.5K
PNG: non-interlaced = 1.875M
PNG: interlaced = 2.368M

 

So you can see there is a major difference when you have an image that is very busy and doesn't have a big area of flat color.

 

Now the next test is the same image but right half of the image is black.

 

JPG: 95% = 396.7K
JPG: 100% = 483K
PNG: non-interlaced = 1M
PNG: interlaced = 1.268M

 

The PNG will be completely lossless but the JPG even at 100% still has some jpg artefacts. At the border of the black and the full-color image, you couldn't detect it but it was there. If you brightened the image you could see red, green, blue and grey pixels.

 

² Jpgs compress the colors, smoothing out similar colors in an image but the luminance is compressed almost like a gif. So if you want to compress an image beyond the usual % you can go into curves flatten out the tone of the image (kind of removing contrast) and save a huge amount of space. Using that kind of tweak I was able to get 1600x1200 wallpapers for a test site down to 10-12k and the change in contrast also removes alot of the artifacts unless you push way down in compression.