Forums | MacLife

thank you for the help. is there maybe a website that compares the image quality/loading time or somehting anything like that?

On an unrelated note, do not use lossy formats such as JPEG for editing. Use PSDs or TIFFs (uncompressed) at the highest quality you can get, then downsample for the final product when you've finished and keep the high qualities copies around somewhere (layers and all) in case you need them for something in the future.

We have a whole forum here on the MAF called Web Design & Development. Check it out, and read the FAQ sticky thread at the top.

What are the pixel dimensions of your images?
Generally speaking an 800x600 jpeg looks decent enough on the web at 50% to 60% quality setting and ought to be between 35k and 50k.

Egress wrote:

Pariah wrote:

What are the pixel dimensions of your images?
Generally speaking an 800x600 jpeg looks decent enough on the web at 50% to 60% quality setting and ought to be between 35k and 50k.

Damn, dude-- just give it all away... Aren't these supposed to be hard-won lessons?

It's bad enough that some programs will automatically set the compression according to the file size...

You're making it sound like Macs are easier to use. Cut it out, or everyone will want a Mac.

Bah, I will not be rebuffed by a cat person   

registered_user wrote:

bigger images take longer to download

-roo

Bigger images do not always have a higher file size

Fireworks is better.  (just in general, but specifically for web images)  Better quality/compression.

PNGs are great for non-photo images, and can be much smaller than gifs.  Gifs are the suck.  Also selective area compression for jpegs can generate excellent size/quality images.  (though I am not sure if photoshop can do that)

A tip for PNG users: make 'em even smaller with PNGCrusher. Might just be because of Photoshop's "inefficient" exporter, but I can often trim 10-20% off "Saved For Web" PNGs using the crusher.

(Before anyone gets pedantic, I know it's just the front end for OptiPNG.)

Are png's fully supported yet on all major browsers.

Last I remember Explorer choked on 24bit pngs.

RTFM, noob. It only helps when the file hasn't been fully compressed. Sometimes they already are. Running it through to check never hurts.

And light speed, IE just doesn't do alpha transparencies. 24bit is fine, but your translucency will be screwed unless you use Sleight (see the FAQ), which uses hands the transparencies off to some IE extension. It's crappy.

All browsers support 24bit pngs.

WinIE doesn't support the alpha channel (often called a 32bit png).  Though it will support a 1 bit alpha channel.  You can easily make transparent pngs work on WinIE through the IE specific attribute (easy if you have your view abstracted with smarty, rails or some other templating tool) or careful planning and the 1 bit channel.   IE7 does support it natively.

Sleight is ass.

If you have a good image handling tool (fireworks), your pngs will almost always be smaller than gifs, and depending on the type of image (gradients for example) pngs flat out kick ass.  Nothing can touch them.   And as Miles mentioned, they are standard and open source.  They are also highly extensible and flexible.

reefdog wrote:

RTFM, noob. It only helps when the file hasn't been fully compressed. Sometimes they already are. Running it through to check never hurts.

What manual?

But, yeah, the creator makes no distinction between 8 bit and 24 bit png files. By reading about the OptiPNG base that it uses and by running a few tests I'd only really bother with that program if you're working with 24 bit png files since most of what it likes to do seems based on the color table and the compression of that color table.  Since 8 bit PNG files already have an optimized color table then this program doesn't seem to be helpful on it.

It just helps to know what you're dealing with, that's all...