As probably many people around here I read a few webcomics. Drowtales is my favorite, but that's besides the point.
For a long time a thought has been nagging me at the back of my head: webcomics are drawn pictures. They are not photographs. There should be a lot of redundancy (less colors, more flat colored areas, etc.) and thus they should be easily compressible at quite high rates while still maintaining lossless quality. Still it seems that the best tool to compress them is the same old lossy JPEG.
How so? Are there not better things invented? I'm not an expert in data compression, so my own meager attempts at finding some better algorithm have been fruitless. Best I could find was Pngcrush, but it still is way behind JPEG in terms of compression.
I would like to hear an expert opinion on this. Is this idea of mine foolish and doomed to failure? Or is there perhaps some way that people have found or that I could look into?
This, of course, comes from the selfish desire to decrease load times. :)
Added: Some people seem to miss the point, so I'll clarify:
Webcomic images should have a lot of redundancy in them so they should be easily compressible. Is it not possible to somehow compress them so that they would be both lossless AND smaller than JPEG? Or at the very least compress them better than JPEG while still retaining the quality.
Since they would be for web the specialized compressor should still probably emit PNG or JPEG - just compressed with a modified algorithm for better results.
No question, it's a balancing act between appearance and performance. Barring a custom compression algorithm specifically for comics, I think the best you can do is experiment with JPEG compression levels until you get one that's a reasonable size, but still looks good for the particular comic.
From lbrandy.com
The problem with comics is that a lot of graduated colouring is used. A common technique when colouring a comic on computer using Photoshop, for example, is to start by blocking out areas in solid colour as you mentioned. However, these solid areas are then refined using various techniques, from hand touching using airbrush tools to overlaying graduated fills, dodging and burning tools, etc.
The result is an image which is more like a natural image - which is what comic artists are striving for of course - and thus it compresses better with a lossy algorithm such as that used by JPEG.
A completely different approach would be to render the comic images using a vector format like SVG. That would capture the essence of the drawing (fill here, arc here, line here, etc) without having to try to raster-compress the resulting images.
Your assumptions aren't borne out by my data. My favorite webcomic is already distributed as PNG. Converting a 167K PNG file to JPEG using the default compression quality yields a 199K JPEG file. Break-even is somewhere between -quality 60 and -quality 65, which is quite a low quality for a JPEG. So, Questionable Content is already compressed lossless and smaller than JPEG.
A few things I've picked up on doing images for web use -
Use jpegtran -optimise on JPEGs - it recompresses them losslessly and can shave a good few percent off poorly compressed images.
I run PNG files through pngnq (make them 8 bit) and then optipng -i0 (recompress and remove any interlacing). I know you said you don't like lossy, but pngnq does an amazingly good job of converting images to a palette - best thing to do is try it yourself and see if the output is good enough.
Under certain circumstances, JPEG images will be larger than PNG images.
For example, in cases where there is a very simple image, PNG may end up compressing the image better and giving better image quality.
Here's an example with some Java code:
public static void main(String[] args)
{
BufferedImage img = new BufferedImage(
256,
256,
BufferedImage.TYPE_INT_RGB
);
Graphics g = img.getGraphics();
g.setColor(Color.white);
g.fillRect(0, 0, 256, 256);
g.setColor(Color.black);
g.drawLine(0, 0, 255, 255);
g.drawLine(255, 0, 0, 255);
try
{
ImageIO.write(img, "jpg", new File("output.jpg"));
ImageIO.write(img, "png", new File("output.png"));
}
catch (IOException e) {} // Don't usually ignore exceptions!
g.dispose();
}
The above code produces an image with the dimensions of 256 x 256 pixels, and draws two intersecting diagonal lines in the form on an "X".
The 256 x 256 image was used to keep the image size to an multiple of 8, as JPEG compression performs a 2D DCT transform on 8 x 8 pixel sections of the image. By keeping the image size and location of the line to align within the 8 x 8 pixel section, it will reduce the amount of compression artifacts and improve the quality of the image.
(Choosing 256 x 256 was empirical -- I at first used 100 x 100 and noticed that the JPEG image was horrible, so I tried 64 x 64 and it looked better, so I made it larger to simulate a more realistic image size.)
After drawing the image, the program generate a JPEG file and a PNG file. (The Java ImageIO library uses the default compression ratio of 0.75f for the compression quality of the JPEG.)
Results:
output.png : 1,308 bytes
output.jpg : 3,049 bytes
Taking a look at the image itself, the JPEG has a little bit of artifacting, but it wasn't very noticeable until I zoomed in with an image editor. Of course, the PNG image is lossless, so it was an exact representation of the original.
To conclude, whether an image is smaller with PNG or JPEG is really up to the source -- there are cases where JPEG can be larger than a PNG and yet the PNG can be better quality. Of course, in practice, generally PNG will be larger than JPEG for a given image.
You may want to cut down on how many colours you are encoding in your image. Try saving your comic with only 256 colours and watch the size decrease a lot. Depending on your specific drawing style, that me be enough.
I've drawn a number of large hand-illustrated circuit diagrams which I scan in as grayscale for use in computerized documents; LZW-compressed TIFF always wins hand over JPEG, both in viewable quality and file size, I think because TIFF can take advantages of RLE encoding for whitespace. I'm not sure whether PNG can do this too, or whether RLE can be extended for multicolor images & not just black/white.
edit: I just tried one of my grayscale hand drawings; TIFF can beat PNG by about 2:1 (43K vs. 83K using ImageMagick convert to go from original TIFF -> PNG -> TIFF again to double-check that ImageMagick is producing both file formats and ensure that my original program didn't do a bad job producing the TIFF) but only because TIFF uses 8bits/pixel (grayscale) and PNG uses 24bits/pixel (RGB).
edit 2: never mind, I just was able to use pngcrush -c 0 to ensure the image is grayscale. PNGcrush got the RGB version down to 67K and the grayscale down to 34K. Nice!
edit 3: Just a point of procedure: It seems to me that it would make a heck of a lot more sense to pick a number of different images of this type to choose as standard benchmarks, and just try different techniques across the benchmark set, rather than just a bunch of stack-overfloids pontificating. This seems like a problem that needs a well-tested empirical solution.
No matter how great a lossless compression is, a loss compression will always be better, because it just has fewer limitations.
Imagine that one day they invent some lossless compression better than jpeg for comics, obviously the next day someone will modify it to compress more, even, and probably, if it means that some info is lost.
Between anti-aliasing and gradients, there are probably more colors in the image than you think.
Drawn vs. not drawn, web comics vs. any other type of image... that's not relevant. The specifics of how web comics are drawn or the colors are laid out or whatever is something you're perceiving as different. But you can bet that decades of graphics research and development have that fully taken into account, and the people that do graphics optimizations for a living have pushed the envelope.
If there was a better compression algorithm than JPEG, GIF, PNG, etc. then don't you think it would be in wide-spread use? If you're looking for fairly recent breakthroughs then I think you're probably wasting your time, as 1) you'd have to expend quite a bit of effort to make your front-end compression compatible with whatever viewer people use (like browsers) and 2) if it had significant gains from current formats then it would become wide-spread fairly quickly.
If I'm getting down-voted I must not have explained myself very well.
Thinking that web comics are in some special domain because they're hand-drawn or have lots of color repetition is a bit silly. Finding large blocks of the same color is one of the absolute basics of image compression.
Get yourself a good graphics program, and using your specific image, see which of its export formats yields the smallest image size while retaining the quality you desire. It is going to be different for different images.
For pen-and-inkish images, the compression scheme in GIF can work wonders.
JPEG compression is ill-suited to that kind of image.
As someone who has done a lot of colouring work for cartoons, as well as photo-manipulation work I can safely say that there is often a lot going on inside the average web-comic when compared to a normal photo.
Assuming that the image is done in Photoshop or Painter (usually from a Tablet) there are often a number of filters or layers at work in the average web-comic. Shading, reflection, opacity, background images and far more come into the equation and with many of these being straight from filters or layer overlays there are often many colours in place.
A lot of the time you have to think of your audience. It is really worth optimising your images if you get 20 visitors a day? I'd probably argue that it is completely down to the size and content of your web-comic. If you can get away with PNG then I'd stick with it. More often than not in web-comics there is little going on to warrant using JPG.
I use OPTIPNG to get the best filter (with a sane level) and then I run ADVDEF -4 -z
http://advancemame.sourceforge.net/comp-readme.html (Not Advpng because Advpng removes the filters) to optimize the deflate.
Also you can try pngout http://www.advsys.net/ken/utils.htm
Has a plugin for Irfanview.
It uses the same deflate implementation of Kzip, which is usually even better than 7-zip but much slower.
EDIT:
okcancel20031003.gif What's your favorite "programmer" cartoon? 256 colors 147KB
PNG (Paint) 126KB
PNG (Irfanview) 120 KB
PNG (Irfanview) +
Optipng -o5 120KB (525 bytes smaller) 9s
Optipng + ADVDEF 114 KB 9s+0.9s
PngOut 114 KB 6s
BMP 273 KB
BMP +
7z (LZMA -fb 273) 107 KB
RAR (Best) 116 KB
BMF -S 90 KB 0.3s
Paq8o10t -4 79 KB 35s
I think the missing piece of information here is Image Compression is Tied to the Format. It's certainly possible that someone could come up with a compression algorithm that was/is well suited for the kind of images that web cartoonists create. However, once you took the new uber-comic-image format and emitted a PNG, JPG or GIF, the color information would be subject to the rules of the PNG, JPG or GIF compression mechanism and you'd lose all the benefit of your new image format.
Here's another way to think about it.
Save a photo as a low quality JPEG
Note the file size
Take that low quality jpeg and save-as a 24/32 bit PNG
Note the larger file size
The same thing would happen to this mythical uber-comic-image format.
The alternative would be getting the major browser vendors to support uber-comic-image nativity. I'll leave the reasons behind that not working as an exercise to the viewer.
Related
I have this image (photo taken by me on SGS 9 plus): Uncompressed JPG image. Its size is 4032 x 3024 and its weight is around 3MB. I compressed it with TinyJPG Compressor and its weight was 1.3MB. For PNG images I used Online-Convert and I saw webp images much more smaller even than compressed with TinyPNG. I expected something similar, especially that I read an article JPG to WebP – Comparing Compression Sizes where WEBP is much smaller that compressed JPG.
But when I convert my JPG to WEBP format in various online image convertion tools, I see 1.5-2MB size, so file is bigger than my compressed JPG. Am I missing something? WEBP should not be much smaller than compressed JPG? Thank you in advance for every answer.
These are lossy codecs, so their file size mostly depends on quality setting used. Comparing just file sizes from various tools doesn't say anything without ensuring images have the same quality (otherwise they're incomparable).
There are a couple of possibilities:
JPEG may compress better than WebP. WebP has problems with blurring out of the details, low-resolution color, and using less than full 8 bits of the color space. In the higher end of quality range, a well-optimized JPEG can be similar or better than WebP.
However, most of file size differences in modern lossy codecs are due to difference in quality. The typical difference between JPEG and WebP at the same quality is 15%-25%, but file sizes produced by each codec can easily differ by 10× between low-quality and high-quality image. So most of the time when you see a huge difference in file sizes, it's probably because different tools have chosen different quality settings (and/or recompression has lost fine details in the image, which also greatly affects file sizes). Even visual difference too small for human eye to notice can cause noticeable difference in file size.
My experience is that lossy WebP is superior below quality 70 (in libjpeg terms) and JPEG is often better than WebP at quality 90 and above. In between these qualities it doesn't seem to matter much.
I believe WebP qualities are inflated about 7 points, i.e., to match JPEG quality 85 one needs to use WebP quality 92 (when using the cwebp tool). I didn't measure this well, this is based on rather ad hoc experiments and some butteraugli runs.
Lossy WebP has difficulties compressing complex textures such as leafs of trees densely, whereas JPEGs difficulties are with thin lines against flat borders, like a telephone line hanging against the sky or computer graphics.
My header image, embedded as a png because of the transparency needed for it, at my site http://www.derekbeck.com/1775/ , is the largest thing being downloaded, at 197 kb. Any suggestions on shrinking its size considerably?
Use ImageAlpha to reduce color depth and then ImageOptim to apply maximum compression.
If you're not on a Mac, then TinyPNG and pnggauntlet will do the same.
You can't really compress it too much- It's a "confusing" image, as in, it's not easy to compress in a lossless format because there's no obvious patterns or clear rectangles of color. You COULD split it into about 3 images as it is sometimes a little faster to download that way. Regardless, 200kb isn't that much these days, and it's cached, so it's not too much of a concern.
Not much to do, really. If you posterize it to 32 levels and save with maximum compression (eg with XnView) you get 121kb, but with some degradation.
You might also try pngcrush
I've been experimenting with lossy png compression, inside my PNGJ library, but it's not yet really usable - in case you're interested, here's a result at 95kb http://img221.imageshack.us/img221/9659/1775headerwithimagebw37.png
I need to reduce the file size of a color scan.
Up to now I think the following steps should be made:
selective blur (or similar) to reduce noise
scale to ~120dpi
reduce colors
Up to now we use convert (imagemagick) and net-ppm tools.
The scans are invoices, not photos.
Any hints appreciated.
Update
example:
http://www.thomas-guettler.de/tbz/example.png 11M
http://www.thomas-guettler.de/tbz/example_0800_pnmdepth009.png pnmscale, pnmdepth 110K
http://www.thomas-guettler.de/tbz/example_1000_pnmdepth006.png pnmscale, pnmdepth 116K
Bounty
The smallest and good readable reduced file of example.png with a reproduce-able solution gets the bounty. The solution needs to use open source software only.
The file format is not important, as long as you can convert it to PNG again. Processing time is not important. I can optimize later.
Update
I got very good results for black-and-white output (thank you). Color reducing to about 16 or 32 colors would be interesting.
This is a rather open ended question since there's still possible room for flex between image quality and image size... after all, making it black and white and compressing it with CCITT T.6 black and white (fax-style) compression is going to beat the pants off most if not all color-capable compression algorithms.
If you're willing to go black and white (not grayscale), do that! It makes documents very small.
Otherwise I recommend a series of minor image transformations and Adaptive Prediction Trees (see here). The APT software package is opensource or public domain and very easy to compile and use. Its advantages are that it performs well on a wide variety of image types, especially text, and it will allow you to scale image size vs. image quality better without losing readability. (I found myself squishing a example_1000-sized color version down to 48KB on the threshold of readability, and 64K with obvious artifacts but easy readability.)
I combined APT with imagemagick tweakery:
convert example.png -resize 50% -selective-blur 0x4+10% -brightness-contrast -5x30 -resize 80% example.ppm
./capt example.ppm example.apt 20 # The 20 means quality in the range [0,100]
And to reverse the process
./dapt example.apt out_example.ppm
convert out_example.ppm out_example.png
To explain the imagemagick settings:
-resize 50% Make it half as small to make processing faster. Also hides some print and scan artifacts.
-selective-blur 0x4+10%: Sharpening actually creates more noise. What you actually want is a selective blur (like in Photoshop) which blurs when there's no "edge".
-brightness-contrast -5x30: Here we increase the contrast a good bit to clip the bad coloration caused by the page outline (leading to less compressible data). We also darken slightly to make the blacks blacker.
-resize 80% Finally, we resize to a little bigger than your example_1000 image size. (Close enough.) This also reduces the number of obvious artifacts since they're somewhat hidden when the pixels are merged together.
At this point you're going to have a fine looking image in this example -- nice, smooth colors and crisp text. Then we compress. The quality value of 20 is a pretty low setting and it's not as spiffy looking anymore, but the document is very legible. Even at a quality value of 0 it's still mostly legible.
Again, using ADT isn't going to necessarily lead to the best results for this image, but it won't turn into an entirely unrecognizable mess on photographic-like content such as gradients, so you should be covered better on more types or unexpected types of documents.
Results:
88kb
76kb
64kb
48kb
Processed image before compression
If you truly don't care about the number of colors, we may as well go to black-and-white and use a bilevel coder. I ended up using the DJVU format because it compares well to JBIG2 and has open source encoders. In this case I used the didjvu encoder because it achieved the best results. (On Ubuntu you can apt-get install didjvu, perhaps on other distributions as well.)
The magic I ended up with looks like this to encode:
convert example.png -resize 50% -selective-blur 0x4+10% -normalize -brightness-contrast -20x100 -dither none -type bilevel example_djvu.pgm
didjvu encode -o example.djvu example_djvu.pgm --lossless
Note that this is actually a superior color blur to 0x2+10% at full resolution -- this will end up making the imagine about as nice as imaginable before it's converted to a bilevel image.
Decoding works as follows:
convert example.djvu out_example.png
Even with the larger resolution (which is much easier to read), the size weights in at 24KB. When reduced to the same size, it's still 24KB! Lastly, at only a 75% of the original image reduction and a 0x5+10% blur it weights in at 32KB.
See here for the visual results: http://img29.imageshack.us/img29/687/exampledjvu.png
If you already have it doing the right thing with the Imagemagick utility "convert" then it might be a good idea to look at the Imagemagick libraries first.
A quick look at my Ubuntu package lists shows bindings for perl,python,ruby,c++ and java
I noticed when I saved my menu background image from jpg to gif that gif takes almost one fourth of the size that jpg does.
jpg = 25kb
gif = 7kb
Is there any downsides to using gif?
Its GIF 256 colors BTW. NOT interlaced. Not transparent.
Just want to be sure!
Thanks
If you're not using it for interlacing and transparency, the only real upside would be the compressed file size.
However, you may want to look into using the PNG format. You can find an overview of the three file types here (Surrey University)
Over the past 5 years, PNG has been phased in to the web image standards, developers and designers always knew it handled compression better, but it wasn't fully supported by all browsers - causing it to be overlooked until said browsers were upgraded.
Nowadays, PNG is pretty much the most commonly used file format for images on modern websites.
There are no downsides to this as long as the graphics look good.
For menus and line drawings - in general, any mages with large homogeneous areas, i.e. many adjacent Pixels with the same color -, GIF (or PNG, note musicinmybrain's comment below) is usual the best choice as it compresses stronger, and the results look better (especially because of sharper edges).
For heterogeneous images like photos, GIFalmost always loses in both size, and quality, and JPEG is the better choice.
GIF it's not designed for photographic material, so a big photo comes out better and smaller in JPEG, but tt's probably more than apt for interface elements such as buttons, dividers, borders, etc.
The only caveat that comes to mind are gradients: even on a small area and with 256 colors, GIF will likely show visible banding. This is often very subtle and not a big issue, but you may want to check it, especially if you have lots of gradients and/or hate banding.
I'd second what Daniel May is saying about using the PNG format.
Although if you are solely concerned with image size and don't have a specific reason for using GIF remember that you can tweak the quality of a JPG file to turn a 25kb JPG into a 7kb JPG!
As you say the gif can only handle 256 colors, if you don't need more then that gif will be a good choice.
I would recommend gif over png because there are some issues with color profiles in webbrowsers and pngs. You might end up with png colors not matching the css color.
A few people have mentioned the PNG format. Its worth mentioning there are two different types of PNGs, 8-bit and 24-bit. Both types support transparent pixels, however the 24-bit variant supports alpha transparency.
Generally 8-bit PNGS will be slightly smaller than their GIF equivalents. However large 24-bit PNGs have quite large filesizes if they use alpha-transparencies.
It really all comes down to what is the right format for the image. Some will compress/display better in different formats than others. I wouldn’t try and use one single format, such as GIF for all images and pictures on a website (the original question) unless the images were all IU related.
You really need to understand a little about how these different formats work, rather than choosing one over the other. There is a very good article on the pros & cons of gif/jpg/png formats here:
http://www.websitetemplatedesign.com/oscommerce_tutorials/printer_136.shtml
As far as I am aware, if the image quality looks acceptable then go for the smallest image format you can find. You might find you save even more size using PNG.
To answer your question: NO. It's perfectly acceptable to use GIF files over JPEGs. Each format has its own pros and cons.
You can read about them here: PNG vs. GIF vs. JPEG vs. SVG - When best to use?
I have a very large background image (about 940x940 pixels) and I'm wondering if anyone has tips for compressing a file this large further than Photoshop can handle? The best compression without serious loss of quality from Photoshop is PNG 8 (250 KB); does anyone know of a way to compress an image down further than this (maybe compress a PNG after it's been saved)?
I don't normally deal with optimizing images this large, so I was hoping someone would have some pointers.
It will first depend on what kind of image you are trying to compress. The two basic categories are:
Picture
Illustration
For pictures (such as photographs), a lossy compression format like JPEG will be best, as it will remove details that aren't easily noticed by human visual perception. This will allow very high compression rates for the quality. The downside is that excessive compression will result in very noticeable compression artifacts.
For illustrations that contain large areas of the same color, using a lossless compression format like PNG or GIF will be the best approach. Although not technically correct, you can think of PNG and GIF will compress repetitions the same color very well, similar to run-length encoding (RLE).
Now, as you've mentioned PNG specifically, I'll go into that discussion from my experience of using PNGs.
First, compressing a PNG further is not a viable option, as it's not possible to compress data that has already been compressed. This is true with any data compression; removing the entropy from the source data (basically, repeating patterns which can be represented in more compact ways) leads to the decrease in the amount of space needed to store the information. PNG already employs methods to efficiently compress images in a lossless fashion.
That said, there is at least one possible way to drop the size of a PNG further: by reducing the number of colors stored in the image. By using "indexed colors" (basically embedding a custom palette in the image itself), you may be able to reduce the size of the file. However, if the image has many colors to begin with (such as having color gradients or a photographic image) then you may not be able to reduce the number of colors used in a image without perceptible loss of quality.
Basically it will come down to some trial-and-error to see if the changes to the image will cause any change in image quailty and file size.
The comment by Paul Fisher reminded me that I also probably wouldn't recommend using GIF either. Paul points out that PNG compresses static line art better than GIF for nearly every situation.
I'd also point out that GIF only supports 8-bit images, so if an image has more than 256 colors, you'll have to reduce the colors used.
Also, Kent Fredric's comment about reducing the color depth has, in some situtations, caused a increase in file size. Although this is speculation, it may be possible that dithering is causing the image to become less compressible (as dithering introduces pixels with different color to simulate a certain other color, kind of like mixing pigment of different color paint to end up with another color) by introducing more entropy into the image.
Have a look at http://www.irfanview.com/, is an oldy but a goody.
Have found this is able to do multipass png compression pretty well, and does batch processing way faster than PS.
There is also PNGOUT available here http://advsys.net/ken/utils.htm, which is apparently very good.
Heres a point the other posters may not have noticed that I found out experimentally:
On some installations, the default behaviour is to save a full copy of the images colour profile along with the image.
That is, the device calibration map, usually SRGB or something similar, that tells using agents how to best map the colour to real world-colours instead of device independant ones.
This image profile is however quite large, and can make some of the files you would expect to be very small to be very large, for instance, a 1px by 1px image consuming a massive 25kb. Even a pure BMP format ( uncompressed ) can represent 1 pixel in less.
This profile is generally not needed for the web, so, when saving your photoshop images, make sure to export them without this profile, and you'll notice a marked size improvement.
You can strip this data using another tool such as gimp, but it can be a little time consuming if there are many files.
pngcrush can further compress PNG files without any data loss, it applies different combinations of the encoding and compression options to see which one works best.
If the image is photographic in nature, JPEG will compress it far better than PNG8 for the same loss in quality.
Smush.It claims to go "beyond the limitations of Photoshop". And it's free and web-based.
It depends a lot on the type of image. If it has a lot of solid colors and patterns, then PNG or GIF are probably your best bet. But if it's a photo-realistic image then JPG will be better - and you can crank down the quality of JPG to the point where you get the compression / quality tradeoff you're looking for (Photoshop is very good at showing you a preview of the final image as you adjust the quality).
The "compress a PNG after it's been saved" part looks like a deep misunderstanding to me. You cannot magically compress beyond a certain point without information loss.
First point to consider is whether the resolution has to be this big. Reducing the resolution by 10% in both directions reduces the file size by 19%.
Next, try several different compression algorithms with different grades of compression versus information/quality loss. If the image is sketchy, you might get away with quite rigorous JPEG compression.
I would tile it, Unless you are absolutely sure that you audience has bandwidth.
next is jpeg2k.
To get more out of a JPEG file you can use the 'Modified Quality Setting' of the "Save as Web" dialog.
Create a mask/selection that contains white where you want to keep the most detail, eq around Text. You can use Quick-Mask to draw the mask with a brush. It helps to Feather the selection, this results in a nice white to black transition in the next step.
save this mask/selection as a channel and give the channel a name
Use File->Save as Web
Select JPEG as file format
Next to the Quality box there is a small button with a circle on it. Click that. Select the saved channel in step 2 and play with the quality setting for the white and black part of the channel content.
http://www.jpegmini.com is a new service that creates standard jpgs with an impressively small filesize. I've had good success with it.
For best quality single images, I highly recommend RIOT. You can see the original image, aside from the changed one.
The tool is free and really worth trying out.
JPEG2000 gives compression ratios on photographic quality images that are significantly higher than JPEG (or PNG). Also, JPEG2000 has both "lossy" and "lossless" compression options that can be tuned quite nicely to your individual needs.
I've always had great luck with jpeg. Make sure to configure photoshop to not automatically save thumbnails in jpegs. In my experience I get the greatest bang/buck ratio by using 3 pass progressive compression, though baseline optimized works pretty well. Choose very low quality levels (e.g. 2 or 3) and experiment until you've found a good trade off.
PNG images are already compressed internally, in a manner that doesn't benefit from more compression much (and may actually expand if you try to compress it).
You can:
Reduce the resolution from 940x940 to something smaller like 470x470.
Reduce the color depth
Compress using a lossy compression tool like JPEG
edit: Of course 250KB is large for a web background. You might also want to rethink the graphic design that requires this.
Caesium is the best tool i have ever seen.