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.

There is a nice "contest" going on at Dyxum, a Minolta/Sony DSLR website. During october, for one month participants should only shoot with one prime lens (ie fixed focal length, ie non-zoom). A Nikon forum, Nikoncafe, will also host the same event, but for Nikon shooters

Dyxum original thread

I will be entering with a Carl Zeiss Jena S 135/3.5. This is a very fine old m42 lens, so it is fully manual (both manual focus and manual aperture), but being a Sonnar design, it is already sharp even wide open.

This month will allow me to better grasp this lens, but will also help me to know what is my relationship with photography: Am I only someone occasionally shooting, or am I an amateur photographer.

I've set up a gallery to host those pics.

Dyxum dedicated forum
Nikoncafe dedicated forum

Today, I found a webpage about using Minolta MC/MD lenses on EOS cameras. Using some clever mechanical engineering, this one allows infinity focus without any alteration of the lenses (ie no need to modify lenses).
The problem of MC/MD lenses with Canon EOS mount is that the registration distance between flange an film (or sensor if using DSLR) is shorter on Minolta MD mount than the EOS one, which imply that it should be impossible to use an adapter without optical element that would keep infinity focus.

This adapter is a replacement for the EOS flange, then allowing direct use of MC/MD lenses on the modified EOS. It also seems that camera modification is totally reversible.

Adapters are for sale on eBay, with a quite reasonable price considering the benefits.