By random browsing, I found a web optimization article about using sprites within CSS.

Sprites are basically a set of small size graphics that were used a long time ago to simulate characters animation within video games. There was a predefined set of postures per character, and by alternating between them you could produce a "fake" animation.

Now, back on the CSS topic, the article explains how this old trick can be used to speed up web pages. It's obviously a hack, but quite an elegant one. Let's say you have a few arrows and icons you would want to display within a web page.
First, you put all of them within a single image, in this way:

(icons courtesy of ineversay.com)

Then you set the background of some element of your web page (table cell, list,...) to your sprite image, and using a combination of positioning you correctly set up your element to use the correct sprite (by using the "background-position" CSS property).

What do you save this way?
*A bit of bandwidth related to the graphics, as combined graphics are using less space than the sum of the individual graphic files (mainly because of the headers that would be repeated within each file)
*Most important, you reduce the number of individual http requests. That reduces the needed bandwidth, but also reduces the load of the http server.

This trick can also be used neatly for rollovers, using a single graphic instead of separate ones. Positioning is then even easier, as you could simply alternate background-position from left to right

a:link, a:visited {
	display: block;
	width: 127px;
 	height:25px;
	line-height: 25px;
	color: #000;
	text-decoration: none;
	background: #fc0 url(image-rolloverdual.png) no-repeat left top;
	text-indent: 25px;
}
a:hover {
	/* background: #c00; */
	background-position: right top;
	color: #fff;
}

Here are some old catalogs of Russian lenses, from 1970 and 1971. They are quite big, extensive (but of course are missing the lenses developped after 1971), and best of all, they include lenses diagrams. If you are interested into this kind of lenses, those will be quite usefull.

Table of content
1970 edition
1971 edition

Those catalogs were originally posted on the astronomer.ru website.

note: each one is more than 400 scanned pages, so they are a bit on the heavy side.

Considering that I'm already doing the "one prime for one month" challenges from Dyxum, and considering that those challenges happen every 3 month, that obviously means that I'm shooting 1 pic per day during 1/3rd of the year.
... so why not going further?
Thus, I decided to go pic-a-day, for the whole 2008 year.

I'm progressively building the gallery engine. Right now it only allows to browse through pics, but eventually it will allow dynamic resizing of pictures, borders automatic generation and so on...

Until now, Ogg/Theora and Ogg/Vorbis were included within the HTML 5 recommendation as a feature that "should" be supported:

"User agents should support Ogg Theora video and Ogg Vorbis audio, as well as the Ogg container format."

Nokia just issued a position paper about it, recommending for a removal of this part from the HTML 5 draft, until further clarifications. This caused a lot of noise, with several people questioning this move.

While I agree that there are some strange points within Nokia's position paper, I also have to agree on the fact that W3C should not substitute itself over ISO, ITU, or SMPTE regarding Audio and Video coding standards, and that neither Vorbis or Theora can really be considered to be some standards at this point.

For sure, the current Vorbis specs would probably not be accepted by the usual standardization bodies. Most of the issues would be easily solved, but that is, to me, a demonstration of the usefulness of ISO/ITU/SMPTE standardization processes.

As I'm not fluent with the Theora specs, I'm just going to have a quick look at current Vorbis specifications issues:

*Is the current spec a draft or a final document?

Right now, it's mentioned to be 0.8, without any mention of "freezing" date. It's very likely to be a final document, but why isn't it mentioned anywhere?


*Lack of proper external references.

Granted, this is a very minor issue, but why is there no consistent mention of external references? In section "1.3.2.3. Window shape decode" there is a proper reference to an external paper, but section 7.1 is referring to Bresenham’s algorithm, without any external reference. Any reader interested in Vorbis spec is very likely to be aware of this algorithm, but this is just an example of a place where external references should be added.


*Lack of profiles

A few things within the Vorbis specs can be problematic for implementation within heavily constrained environments. This could be solved by having profiles within the specs, and is acknowledged by section "1.1.6. Hardware Profile".
The problem is that this hardware profile is not actually defined within the standard.


*Codebook transmission

Vorbis mandates the use of custom codebooks, which have to be transmitted as side information in a way or another. That is a great flexibility, but in the real world, most cases could happily be covered by a standard set of codebooks. Having a base profile with fixed codebooks would allow to store those in ROM instead of RAM, which could be of great value for some embedded devices.


*MDCT window size

According to Vorbis specs, a stream must feature two different windows sizes, which is a usual feature for such an audio format. The problem is that the sizes can be 64, 128, 256, 512, 1024, 2048, 4096 or 8192 samples, instead of only 2 fixed sizes. That is an additional complexity that is mostly unneeded, versus having only 2 sizes, which would ease code optimizations, and would not go up to the 8192 size that could sometimes be stressful regarding memory use (and memory transfers).
Once again, this issue should be taken care of by defining some profiles.


*The two types of floor curves

As defined by section 4.2.4.3, Vorbis allows two different kind floor curves. However, only 1 of those is really used by all the current Vorbis encoders. Why not just keeping one, and eventually put the other type within an "extended" profile?


*Floor+residue dynamic range

As mentioned within the specs, some parts of decoding (see section 1.3.2.8) can not be done using 32bits fixed point. You either need a movable binary point (quite inefficient) or use 64bits fixed point (64bits computations also being quite inefficient on many architectures). This should really be addressed in a way or another, either by profiles, or "limited accuracy decoders" defined by the specs.


*No maximum packet size

According to section 1.1.3, there is no maximum packet size. While this will work considering a personal computer, once you go into embedded devices, there is no such thing as unlimited memory, especially if you are considering the local memory of your processor/dsp/whatever.
Moreover, if there is no maximum packet size or maximum bitrate, how do you test performance of your decoder?


*No constant bitrate mode

The specifications do not define any constant bitrate (CBR) mode. That would not be that hard to do, all that is needed is defining a coding buffer/reservoir, and allow a way to signal its current level (could be on the transport level). In many streaming cases, CBR or "capped VBR" (ie VBR with a maximum bitrate, considering a given buffer size) is a necessity.


*A standard should, as much as possible, be set in stone

"However, the Xiph.org Foundation and the Ogg project (xiph.org) reserve the right to set the Ogg Vorbis specification and certify specification compliance."
Sounds a bit frightening. Please, mention somewhere that the standard is in final stage, and won't be changed at latter stage.