Eyepiece - some thoughts on GUI interfaces using Python

What a nightmare ...

As a long-term user of IDE (Integrated Development Environment) programming tools, and specifically Visual Basic on Windows, I'm used to being able to drag and drop controls, insert modules and pop-up forms and so on without having to write more than a line or two of code - and to then to add the functionality wherever I need.

With Python, it seems that everything has to be hand-coded using library classes that have multiple rules about how anything is placed, a hierarchy of grids, stickies and classes that are ill-documented. It felt like I was programming back in the 1970's without the benefit of being able to preview what I was doing.

the standard tk (Tkinter) library that is an integral part of Python is a hoary old set of widgets (graphical control objects) and cruft that requires some arcane knowledge and a lot of practice to use - especially since anything more complex than a 'Hello World' application seems to require swathes of code to manage.

Indeed, it was to the point where I was considering using Curses - a kind of text-mode interface that creates forms just using colour and text (including the box-drawing characters).

Then I found wx.Python - a somewhat more modern GUI interface with a larger choice of widgets. It still requires a library of arcane knowledge, and the documentation is just as confusing to a Python newbie like me.

Google (my best friend) turned up a number of IDEs for Python, and specifically for wx.Python. Some were form generators, others were supposedly IDEs

I tried several that completely failed to do anything useful - either they didn't load, or they didn't do what it said on the box.

Then I found Boa Constructor - a Windows IDE specifically for Python (Boa and Python are both big snakes of the constrictor variety). Boa not only does what it says on the virtual box, it is free, and it resembles nothing more nor less than the old Delphi interface, using a mosaic of windows rather than a single one with multiple panes.

The range of widgets is excellent (and can be expanded), it generates the necessary code on the fly and will allow a preview. The form designer is also drag and drop (a bit clunky in places, but still excellent). It even allows you to preview the controls in action while designing the form.

I now have an interface of sorts, but I still have to figure out where to put the various bits and pieces of actual code. What's more, the same code runs on both Windows and the Raspberry Pi ...

Version 0.01 prototype interface on Windows 7

As you can see, the windows interface features the nice, rounded corners, semi-transparent top-bar and windows-style controls, while -

Version 0.01 prototype interface on Raspberry Pi

the Raspberry Pi's Linux interface has the square frame, foursquare controls and the same look and feel as the operating system's GUI (LXDE in this case). On a full Linux system where speed, memory and disc space was less of an issue, the window would take on the look and feel of whatever Desktop Environment was in use be it LXDE, Gnome, KDE etc.

Incidentally, while the interface reacts to input, it doesn't actually do anything useful - yet.

Boa Constructor can be found at:
Boa Constructor at Sourceforge

Eyepiece - Problems and Successes

For some reason during the past couple of days, while trying to get the configuration on the Pi right, the automatic graphical log-in on the console decided that it wasn't going to work - resulting in the display switching off.

I finally discovered that I could disable the graphical desktop on the console and get the screen to remain switched on indefinitely.

Strangely, (or maybe no so strangely) this speeds up the system by a marked amount.

Rather than have a permanent mess of system messages littering the console when not displaying a camera preview, I have created an ASCII-graphic that displays some information and something to identify the appliance.

The version should be shown as v 0.xx.xx, but whenever I get a production system will be the first release.



I have had a chance to play around with the camera - exploring the dozens of settings that can be changed from software. Some highlights are as follows:

The Automatic White Balance has a selection of profiles that will correct for a  range of lighting conditions.

There is a setting that allows Dynamic Range Compression - giving an insight into shadows and highlights.

There are settings for Shutter Speed, Film Speed, Colour Saturation, Contrast, Brightness and Sharpness amongst other settings.

It is possible to capture images without any of the usual corrections, indeed, it is possible to capture the whole image effectively as it comes out of the image sensor.



I have started writing the camera control software in Python - a language that I have never used before. I have been pleasantly surprised at how easy it is compared with other languages that I have used.

I have reached the point where the camera is switched on, will display a full-screen preview, will warm up before capturing a series of images (with timestamps on the image and on the file name) and will then switch off the camera.

Next comes the work on the user interface - and a way of setting all the controls without having to type in python commands.



I have turned up a salvaged stepper motor that I will be able to use to drive the fine focus knob. It is rated at 24volts, but it should run at 5v with sufficient torque to turn the knob (a very free motion), and to stall at the ends of the fine focus travel - thus allowing detection of the upper and lower limits of motion.

As it is a 4-phase motor, I will be able to drive it with a unipolar control board (so much simpler than H-bridges).

Some festive thoughts on LED lighting.

As someone with a collection of things that I would like to photograph, I have long considered the question of suitable lighting.

For close-up work, including macro-photography, good daylight is unparallelled but, being Britain, good daylight is at a premium. When we have it, I want to be outside enjoying the sunshine and not indoors photographing small bits of rock.

Anyone who had done any macro-photography knows that the lighting is the most difficult part to arrange of the whole set-up. Flash tends to bleach out highlights and to cast stark, black shadows; incandescent light tends to be too yellow-orange and fluorescent light produces some weird colour casts.

Enter the LED.

For a while now, ice-white LEDs have been widely available in hand torches (flash-lights), work-lights and so on. While excellent for blue and green minerals, these LEDs produce poor earth-tones and dull reds, oranges and yellows.

Recently, warm-white LEDs have been available. These give a much better colour rendition for most subjects, but need to be combined with Ice White LEDs for a better overall effect.

Now comes the problem - buying warm-white and ice-white LEDs is a problem - they are generally advertised simply as white - and finding LEDs labelled by colour usually means expensive.


Today, I was shopping, and looking at Christmas Lights, and specifically cheap strings of LED lights. Lo and behold, there were strings of Ice White and strings of Warm White LEDs, as well as a range of other colours. I bought a string of ice white and a string of warm white (as well as a couple of other colours) - they were £2 per string of 20, batteries not included.

Now, LED fairy lights, instead of a dome-shaped lens, have a dimple in front of the chip to spread the light so that it is visible through a 270° angle.

What results is a pleasantly diffuse light similar to a coloured (or not) incandescent light with the appropriate colour tone.

A little time with a soldering iron and strip-board would quickly turn a string of festive LED lights into a macro-photographer's flood-light. Switching LEDs in and out could change the colour cast, brightness of illumination etc. - and all at 10p per LED. You even get a free battery box and switch with each pack of 20!


Incidentally, I have to say that the warm white LEDs are a little warmer than I would have expected, and really would make excellent display lighting without the starkness of the ice-white LEDs that are more commonly encountered.

Eyepiece - an interlude

The new PiCamera has arrived and, at first, I thought that it was dead on arrival ...

For anyone who receives one of these items that doesn't appear to work, you may need to re-seat the ribbon cable at the camera end, and to pop the nano-connector on the board out and back in.

The nano-connector is a little, flat, rectangular connector hidden under the flexi-circuit that emerges from the optical module (the actual camera).

A thumb-nail under the edge of this should separate the two parts, pinch between finger and thumb to re-seat the connector.

Also, for some reason, it takes a few seconds at cold-boot for the Pi to start up with the camera connected.

While I am working with the assembled electronics and doing the prototype work, I needed a temporary case for the camera. An off-cut of black, 1mm art board (cardboard) folded with a suitable hole for the optical module, held together with tape serves well. It is only to provide protection from handling (electrostatic discharge and stray signals from fingers), so it doesn't need to be a permanent (or even terribly attractive) feature.

..............................

I have also turned up a computer-mouse sized, wired, remote module already fitted with a push-to-make switch (to use as a shutter-release) and a neon which will accept a LED 'ready' indicator. The curly cable from an old, serial keyboard will serve for connection.

While waiting for the camera module and playing around with the settings on my Pi, I have been considering the interface between the computer (Raspberry Pi), the physical controls for the next stage of the project (for image-stacking), the remote shutter release and the stepper motor that will operate the fine-focus knob of the microscope.

Because the shutter control will eventually need to send a signal to two Raspberry Pi computers (when I get around to building an eyepiece spectrometer), the button will operate two transistor switches.

..............................

On the subject of the microscope spectrometer, I have decided that, since I will be using a camera as the detector (a PiNoir, infrared-sensitive version of the Pi Camera), there will be sufficient sensor space to handle four simultaneous channels of data - one being the light passing through the specimen. The other three will be a neon discharge tube, a mercury discharge tube and a beam of light direct from the microscope illuminator (delivered via  fibre-optic light-pipe).

This will allow each spectrometer frame to have sufficient calibration data in it to enable direct measurements without having to set up calibration shots and reference illumination sources each time the device is used. Now all I have to do is to find myself a decent, linear transmission grating, since the DVD I was originally planning to use isn't a sufficiently high quality grating for anything but testing (the grating is curved, after all).