|Background images, layers and file sizes|
How do I get a quality image with a small enough file size?
| 5:34 pm on Jul 15, 2009 (gmt 0)|
So, I decided to make this really great background image. It seemed like a good idea at the time. Size is 1300px x 1200px and comprises 15 layers. All but two of those layers hold a small image with a drop shadow. Before starting, I did reduce each image to 72dpi.
File size is, unsurprisingly, huge!
How best to get this to a more practical file size, and in what format?
Thanks in advance...
| 6:57 pm on Jul 15, 2009 (gmt 0)|
Can you describe the image and application?
Once you get it the way you want it, flatten the image. That alone will cut down quite a bit of the size-but it's still going to be pretty large, unless there are a lot of "empty" areas. If it has subtle gradients and no transparency, your best bet is a JPEG (IMO) somewhere between 60-80% quality. If there's no gradients or feathered edges, a selective gif might be your best bet.
| 8:33 pm on Jul 15, 2009 (gmt 0)|
I was originally hoping to use transparency in a png file, but the file sizes just seem to be too big. Instead, I've gone for a low (25) quality jpg and have discarded the notion of the transparency.
Doing that gives me an image size of 60 KB. That seems still too large. Not only that but I'd really prefer a bit better quality.
The 'master' psd file is 3.4mb, and comprises 12 images of 275x275px at 72dpi. What I'm wondering, I suppose, is if there's anyway of making the master file smaller in size and still retain the quality. That way 'save for web' will get me a smaller file size with the quality I want.
Is 60 KB too big for a background image? I've been looking at an unrelated site that has the basic design principle I'm looking to recreate with this and the background images there are around 275 KB. To me that seems huge!
| 8:56 pm on Jul 15, 2009 (gmt 0)|
Are the 275x275px images identical? if so, you could tile them and save a lot. If they are unique, than I don't think your design will allow for small kb page sizes, without undue quality compromise. A 25 quality jpeg will usually be pretty ugly. Anything less than 60 tends to show considerable loss.
What's more important to you? Bandwidth/page loads or sticking to the design?
One thing I wouldn't do is try to get both by making the images too small to display with very good quality, because then you've got slow AND ugly, instead of just one ;-)
| 9:25 pm on Jul 15, 2009 (gmt 0)|
All the images are unique. One saving grace is that the original scans these images come from are high quality. Hopefully then I've managed to avoid ugly! :-)
Still, I would have liked smaller files and better images.
| 5:17 am on Jul 16, 2009 (gmt 0)|
Blurring all of it some or just edges or certain areas will lower KB.
Also, lower contrast and saturation can lower KB.
Sharpening increases KB.
Reducing noise helps also.
| 7:43 am on Jul 16, 2009 (gmt 0)|
I'd looked at blurring, but hadn't considered the other 'tricks'. Will give them a try.
| 9:33 am on Jul 16, 2009 (gmt 0)|
Ok, in the end I settled for reducing opacity - to 35%. Not only did this reduce file size to 30KB, but means its impossible to tell that the jpgs are low quality.
Not only that, but the new, reduced opacity image works much better on the background that the original one. Hurrah!
| 2:08 am on Jul 18, 2009 (gmt 0)|
|Before starting, I did reduce each image to 72dpi. |
Irrelevant for monitor display or file size. A 300px X 300px image is exactly the same image whether it's 72DPI or 1000DPI . DPI sets the scale for printing on a physical surface.
|How best to get this to a more practical file size, and in what format? |
Depends on the content of the image. For photograph type images with a lot of color or gradients .jpg
If the image has large blocks of the same color, lines, or text then .gif is preferable. For example if you took a screenshot of this webpage not only would .gif produce a substantially smaller file size but it would also preserve the text, borders and lines perfectly without any halos or artifacts.