I was inspired to write this when reading Edward Winter's always fascinating "Chess Notes" column, where I snagged our sample position here. I hope that chess webmasters everywhere will help stamp out blurry and bloated diagrams. I see them here at ChessBase.com, at TWIC, and just about everywhere else. My inner graphics pedant had to take action.
When it comes to images on the web, whether they are photographs of Aunt Millie or flashing banner advertisements, you have two concerns: look and weight. Look we all understand. It either looks good or it doesn't. It's too big or too small, too blurry or too dark, etc.
Weight isn't relevant in the paper world and it refers to how "heavy" a web image is; how many kilobytes it is, which means how long it will take the visitor to download it and see it in their browser. Many call this "size," which leads to confusion with its vertical and horizontal dimensions.
Web images usually require a balance of look and weight because one comes at the cost of the other. The two standard types of web images, gif and jpg, use different methods but both lose information to lower the weight. (We'll ignore png for now.) Jpg, or jpegs, include millions of colors and compress images. They are best for photographs and other sophisticated images. Gifs drop colors from a maximum of 256 in order to lose weight. I.e., a gif with 16 colors will usually load much faster than one with 128 or 256.
An additional element of confusion and danger in web images is the browser and the html code it reads to present the images. The code can tell the browser how big the image is, tagging it. That forces the browser to show the image at that size by setting its horizontal and vertical dimensions precisely down to the pixel, regardless of the actual size of the image. It's good practice to use size tags, but they should match the actual size.
The reason is that browsers do a lousy job of resizing things. They do it quickly and things tend to look squished or stretched out. It's also bad because you could be using a very big and heavy image and using the browser to make it small. That means people will have to wait longer to see the images even though they look small. It's the worst of both worlds. Here's an example:
A) B) C)
Image A is a gif at its correct size. B and C are the exact same image with incorrect html size tags. Image C changed the proportion as well, distorting the image. But even with proportions correct, the browser does a lousy job, so image B is unreadable.
You can screw up images on your own, too. Overcompressing jpegs or using the wrong format for the wrong type of image are the most common amateur mistakes. Chess diagrams, since they usually don't have the complexity of photographs, should be gifs, which almost always create lighter (faster loading) images from drawings than do jpegs. This was very clear when diagrams were simple and black and white. But ChessBase programs export cool wooden and marble diagrams and the pieces are rounded and have shadows. This means they can need dozens, even hundreds, of colors to look good.
ChessBase gets around this by natively exporting diagrams as jpegs. This keeps them looking good, but means they are quite heavy. The diagram on the left is from ChessBase 8, exported with the baginga board setting. It's a jpeg that weighs in at a hefty 29K. If you put a half-dozen of these on a web page it would take 30 or 40 seconds to load on a dial-up connection.
The increasing popularity of superfast broadband connections has led to a lot of bad design because broadband users don't notice slow pages. But since a large majority of internet users are still on dial-up connections, it should still matter.
It's not a bad size, 258 by 258 pixels. That's a bit big if you want it to fix next to the text like this instead of before and after paragraphs of annotation. The logical thing to do would be to resize the image in a graphics program. You don't have to buy Photoshop for $500. There are quite a few programs you can download for free and you may already have one on your machine since both Windows and Macs include basic image editors.
The problem is that things start to get fuzzy and fractured when you resize images with sharp lines, images like chess diagrams. The shadows and rounded shading get too dark. You can compress it so it loads faster, but that also makes it blurrier.
Here on the right is that image, still a jpeg, compressed to 40% and shrunk to 204x204 pixels. It's now only 13K, so it will load much faster. It still looks pretty sharp, if a bit dark. In general, you should prefer lighter boards for web images. (Like the "maple" board.) You should also turn off the "rounded" and "shadows" settings under board design if you are going to resize things.
Things go downhill dramatically if you use html to resize the original with size tags, like image B above. On the left is the original 258x258 diagram with 204x204 size tags. It is fractured and even a little hard to read. The Bb3 could be a pawn with five o'clock shadow. That's what comes of resizing images with html instead of doing it in an image editor. This was the method used in the Chess Notes column that inspired this little rant.
Of course it's a pain to resize all your diagrams after you export a game from ChessBase, but unless you want them at 258x258 that's what you've got to do if you want them to look good. You can automate this process in more sophisticated programs like Photoshop. It would be nice if ChessBase could export its jpegs at different sizes. Even S, M, L would be good.
As long as you are resizing, you may as well do it right. You can use your image editor to export diagrams as gifs instead of jpegs. This will make faster-loading and sharper diagrams if you do it right. If you really want to get into it, you can create a custom color palette for each type of diagram, although this is trickier when you are dealing with textured wooden board diagrams like the ones on this page.
The difference is clear, no pun intended. Compare this one on the right to the diagram above on the right. This is a 12K gif with a 16-color adaptive palette. It is clear and sharp, including the lines, which are what gifs really specialize in. I turned the rounded and shadow settings off so the pieces look clearer. Gradients like those don't look very good in gifs; they come out as one or two colors.
The easiest way to get custom diagrams is to use the "copy position" item under the edit menu. That sends the image, exactly at the size you are looking at, to the Windows clipboard. Then you can paste it into your image editor and export it as you like. Doing that for many diagrams is a bit laborious.
An added annoyance came along when Microsoft introduced "Cleartext" into Windows a few years ago. It's a form of text aliasing that smooths the edges of fonts on the screen. It makes text much nicer to read. (It's under Display Properties, Appearance, Effects.) ChessBase programs use fonts to display the pieces and until ChessBase 9 they weren't really compatible with Cleartype.
If you're using Fritz or ChessBase 8 and have Cleartype turned on, diagrams you export via Edit - Copy position will probably have choppy edges on the pieces. They look washed out and fuzzy. I usually turn off Cleartype before starting to export diagrams. ChessBase 9 partially solves this by using new fonts, although the entire point of Cleartype is to slightly blur the edges of text, so diagrams still won't look as crisp as with Cleartype turned off.
The fancy wooden and marble diagrams are tricky, but plain color diagrams are a snap. They are perfect for gifs because they use so few colors. Compare these two side-by-side. On the left is one I just nabbed from TWIC (sorry, Mark!). It's a 19K jpeg that is blurry and choppy. The rounding and shadows look bad and the black pieces have lost detail. On the right is a 5K (!) gif with rounding and shadows off that is razor sharp and will load four times faster than that blurry jpeg. Both are 258 pixels square. A gif will also stay sharp down to a very small size, around 200 pixels. For smaller than that it's best to go to black and white.