nota bene : the file PhotoTimer.class included in the release archive has a small bug ; please download a fixed file either from CVS or via the bug tracker on sourceforge project's page (link below).
The sourceforge project's page : Labtimer
Those symbols means that I took care and pride to write this page in the spirit of W3C standards for accessibility. If this page doesn't display correctly in your browser, then your browser is too old or too broken and I won't support it. If you want to see this page as I intended it to display, consider upgrading to any browser supporting CSS v.2.
This site is known to work in Firefox
labTimer uses the Gambas IDE
Self processing of black and white films is an unexciting, dull and tedious task. If you are here, you probably already know what I mean. Taking pictures, framing, sensing the light, choosing models and points of view is creative. Turning on the red light, making a contact sheet, selecting snapshots and printing a good negative with carefully forethought masking is creative. But between the shooting and the the proud display of the print, stands the prosaic duty of processing the film.
If you're so new to photography, or masochistic enough, as to wonder why, the answer is that film processing is done inside a dark, sealed, cylinder. From the moment you open the film canister in the complete darkness, until the end of the processing, you have zero opportunity to willingly influence the result. Therefore, processing is a completely "industrialized" process, where you have to follow blindly some procedures and just hope the result will match your expectations.
Don't misinterpret me ! During that process, there are numerous options to influence the outcome, but parameters cannot be chosen depending on the current state of the film. Therefore the choice of the values given to those parameters depends on previous results, manufacturers figures, and personal experience. Today's industrial norms are so strict that processing a film can be considered deterministic. If the pictures are ultimately over or under exposed, blurred or whatever, then it's the photographer's sole responsability.
Hopefully, this industrial aspect calls for automation. Professionals are using complex machines to handle the work, where they basically put the film at one end and grab the prints at the other. But those equipements are expensive, and mostly out of reach of the casual hobbyist. Some processors are specificaly targeted at the home market (Jobo's CPE2 for instance), but they don't come really cheap either. Plus, a true processor is a complex mix of software and electronics, with numerous parts such as sensors, motors, timers, taps, etc., out of the scope of a computer program alone. And besides, my speciality isn't soldering.
So the idea behind labtimer was to address other automation needs, namely the most important of all, the timer. Counting time is really trivial for a computer, but what differentiate computers from a wall clock here is that computers can save and recall a large number of settings, and can display as many clocks as they wish.
Computers come handy too to access ressources that are now scattered worldwide on the web. As a must, a program should now be internet aware to get rid of binder collections, full of outdated documentations pertaining to long gone products.
Another concern is keeping tracks of processing sessions. What films, what chemicals, what time and conditions ? Finally, is the result good or not, and why ? The bookeeping of every choice is even more tedious if possible than the processing itself, but it's a must to avoid falling in the same traps over and over. And computers are really good at bookeeping too.
For those reasons, a suitable programming language had to be found. C / GTK+ has been considered at the begining, but reviews of similar projects showed that a good looking result involved a huge workload, and moreover most photographers were unlikely to be skilled enough as programmers to contribute with their experience (of course, some probably are, but I don't believe it's mainstream). For simplicity sake, I therefore decided on a RAD of some sort. After trying a certain number of linux-available dialects, Gambas was settled upon for a number of reasons : the developpement is very active, it is flexible, offers native DB connectivity, is internet aware, object oriented, and fears no one in the eye-candy departement, being strongly KDE/QT oriented (but GTK+ widgets are to become a feature of v. 2.0). More importantly, I was able to begin the program relying solely on my memories of Oric basic from 20 years ago... (of course, I had a good exposure to C and GTK programming too, and I can't deny it helped, but it shows the roots of GAMABS have remained, well, basic...)
Today, a draft of labtimer is functional ; 80% of the features have been completed, but before alpha 0.1 is released to public, there will be much rewriting. In fact, what begun as a quick and dirty personal project has to be turned into a professional-grade application, and that requires a bit more planning than was put into the making of the current demo. In fact, the bunch of lines that makes today code doesn't really use the full power of Gambas, because of my train-as-you-type approach. So I'll take the time to carefully design the logic flow of labTimer before releasing any new feature.
Currently, there's one prealpha release on Sourceforge the only other access is via anonymous CVS. See on sourceforge help how to checkout the files ; an up to date developpement version of GAMBAS is required. Current rev. is 1.9.46a. Some Gambas components may be tricky to compile, required components in order to use labtimer are gb.qt, gb.qt.ext, gb.kde, gb.kde.html, and gb.form ; those are a bare minimum, so they should be there unless your distribution lacks kde-devel or qt-devel packages. Note that a SQL support of some sort will be required very soon, so better include postgresql support in Gambas now. This requires the pgsql-devel headers to be in the include path of gcc, too.
Why postgresql ? Really, no good reason at all except that it's one of the more technically advanced database server, it's free, it's standard in any Linux distribution, and I already conducted a number of projects on it. Gambas can support a lot of other DB systems (firebird, sqllite, or MySQL), and it is possible that labTimer might be independant of a specific database. But if a choice I can't forsee at the moment forces me to become dependant on a specificity of a database, I'll go with postgresql. And, no, I won't consider MySQL for MySQL is way too far from standard SQL specification. I chose Linux to be free, not be trapped into yet another proprietary lock in.
So, if you consider this project of any relevance to you, please get in touch : a helping hand will be needed soon.
