How did it start? Some time ago, our company decided to buy a digital camera. We wanted something not very expensive, but with a set of features allowing us to make pictures for our intranet. We have a good relationship with our local HP dealer and so we bought a camera they offered - an HP PhotoSmart C200. This one-megapixel digital camera wasn't the worst choice. I didn't much like the software however. Like many commercial programs written in Visual Basic, it was quite ugly, quite fat and slow, with a limited set of features. And, of course, this software was Windows software. I tried searching, but for OS/2 I only found DCITU by Stephane Charette. It doesn't support any of the HP cameras at all. Even contacts with the author didn't get any results - "Support isn't planned". Oh. I was very bored with the software industry. Having nothing to do, I decided to write my own utility. Thus the HP C200 plugin for NetDrive was born. Some people tried it, some others asked me to add support for additional cameras. Fortunately there was a new project starting -Third Eye, founded by a group of Russian enthusiasts who eagerly need digital camera support in OS/2. I was offered an opportunity to take part. And now it is time to talk about what we have accomplished so far.

As it is written on the official Third Eye site www.ecomstation.ru/thirdeye : "The most modern and powerful digital camera manipulation program for OS/2". Really, at the moment this project supports more than half the digital cameras known to us (including the newest ones.) The program has a very user-friendly graphical interface with skin support. For example your program could look like it is shown in the two shots below:

Excluding help windows, which are very familiar to OS/2 users, the program has two main windows:

Below is the setup window with three tabs:

The current features of the Third Eye are:

• It is a completely native OS/2 application. No Linux code inside.
• COM-port control in Third Eye is based on the tested engine from the fidonet-mailer GPMail.
• Auto Reconnect function.
• Low processor load.
• Graphics engine is based on CooLFM application.
• Camera manipulation is detached from the User interface. This feature guarantees reliability and smooth operation in the OS/2 environment.
• Wide range of supported hardware including: Kodak, Agfa, HP, Casio, Fuji, Konica digital cameras. The full list is available on the official Third Eye web-site and is updated constantly.
• Low disk space requirements (currently less than 2 Mb.)

One of the most important (at least for me) features of the Third Eye is the fact that the program is being developing by its customers. Moreover, it is a child of the OS/2 internet community. Linux fans can try to say the same, but there is a significant difference. For example, Linux's gPhoto is written by a several dozen programmers, each of them has his own habits and style (trust me, I looked though the gPhoto sources from the first to the last page.) That fact affects the result - there isa lot of repetition, different level of support for different cameras, etc. ThirdEye is different - it has a small tight team of programmers and widespread help from potential users. The result is that in the Third Eye we have only one C++ class for all Kodak DC210/215/240/280/3400/5000 (perhaps earlier models work too, we didn't check) family cameras despite several separated libraries in gPhoto. Of course in this case it works faster, and it is easier to control and modify.

In developing the list of what I can add - our users have suggested some additional features which they need (and which will be realised in the next versions.) The main ones are:

• Rexx command language support for main Third Eye functions.
• Camera control via tcp/ip networks.
• Panorama support (in this case, program "glues" together one large image from a set of sequential frames.)
• "Professional" skin support with a full snapshot control (i.e. exposure, strobe mode, zoom etc.)
• And the "hot" feature is - web-camera mode support with automatic picture publishing on a Web-server.

While working on this project I discovered a new software development paradigm - it is impossible for us to purchase all the types of cameras we are going to support. Hence we support all cameras where owners (read - users for us) display great activity in the testing process. I think this sort of contact between programmers and end users gives a better product than general software industry practise. Customers act as if they are a part of the development team. Thank you, guys!