Today I achieved what some might consider to be a rather simple milestone, but it is quite exciting for me none the less.  I was able to access a COM object using python.  More specifically, I was able to create an object for my windows screen reader, Window-Eyes, and make it speak something using the python interpreter.  Let me explain precisely how I did this, because it is extremely cool!  In windows, many programs have an object model of sorts with which you can communicate to provide enhancements to the application in question.  Many main stream applications such as Word, Excel, iTunes and Skype have object models so you can alter or provide your own functionality to the program.  This adds extreme flexibility to the program, because script writers now have a way to tailor the software to better meet their needs.  Most screen readers are no exception to this rule, although there are a wide variety of implementations depending on the screen reader.  The Window-Eyes screen reader happens to be a COM server which can be accessed the way you would access any other COM server.  From what I understand, COM is somewhat of a standard in Windows.  Before we get started with this example, you will need to grab a few things from the internet, assuming they are not installed already.  You will need Python of course, but hopefully that’s a given.  The next thing you’ll need is the pywin32 extensions for python.  This is a library of modules that are useful if you plan to be writing lots of python scripts or applications under Windows.  The win32 extensions purportedly works with Python 3.1.2.  However, when trying to install it for 3.1.2 I received an error that python 2.6 was required.  As I didn’t feel like trying to figure out why I was getting that error, I have temporarily rolled back to version 2.6.5.  Once everything is installed, let’s open up the python interpreter by the usual means, or you could simply create a new script using your favorite text editor.  Type the following lines.

# begin example script

# shows how to get a COM object and access some of its properties and methods.

import win32com.client

weObj = win32com.client.Dispatch(“WindowEyes.Application”)

# speaks the string that is passed to the speak method.

weObj.Speech.Speak(“Hello world!”)

As you might have guessed, I immediately heard the phrase “hello world!” spoken by the active speech synthesizer used by Window-Eyes.  How cool is that?!  A useful application of Window-Eyes scripting, or indeed screen reader scripting in general is to enhance the accessibility of applications that do not work right out of the box.  I have already done this using other languages, mostly JScript, but the nice thing about COM is it supports a wide variety of programming languages.

One of the reasons I bring this up here aside from the fact that it is really cool and very relevant to our project, is that we are always looking for potential script writers for Window-Eyes so that more programs can become accessible.  If you know python, half the battle is over; it’s simply a matter of learning the Window-Eyes object model, which is well documented.

I have only begun playing around with COM objects using python, so I am hoping to get further with this in the weeks to come.

The interweb has been my friend when it comes to researching 3d image libraries.  It is also my sole source for learning to use python, so what I’m about to share can be found if one has a bit of free time to go poking around and do some searching.  However, I wanted to bring this to everyone’s attention.  There is a 3D graphics library for python called Pyvy.  Pivy is a python binding of the Coin toolkit and makes the development of 3D objects in Python a rapid process.  It can even be used from within the python interpreter immediate mode window so you can get immediate feedback, from what I’ve read.  This seems relevant to our project for obvious reasons, but I wonder if this functionality overlaps with blender, to the point that we may not need such a library?  Any thoughts?  There is a useful article with code examples on how to use some of Pivy’s basic features that can be found here, and The project site can be found here.  I took a quick glance at the license for this library and it appears to be freely available for distribution, if we choose to implement it in our software.  The source code is also available.

Stephanie and I have started examining the beginning steps in building the software for this project. We decided that it would be useful to first noise reduce an image before beginning to transform it. This will hopefully rid the image of randomly placed and unwanted pixels and allow the edges of shapes to become more defined. A noise reduction method that we discovered is median filtering. This involves going through the pixels in an image and, for each one, examining the surrounding pixels, or “neighborhood.” Typically, the neighborhood consists of all the pixels adjacent to the selected pixel. This method then determines the values of these pixels. The value could be the numerical value representing a pixel in grey scale, for instance. We then find the median value of these pixels and use it as the new value for the original pixel.

Once the image has passed noise reduction, we can then begin the process of edge detection. In keeping with an iterative development process, we decided it would be easier to only be concerned with grey scale images first. This way, we can examine each pixel’s grey scale value and turn it either black or white. Then, we can then easily distinguish between black and white and decipher where the edges are. As the images we work with become more complicated, so will our technique. For now, we believe this is a first good step.

In further discussions, we hope to improve our edge detection method, examine how to transform the shapes that we find into 3D, and begin to actually implement some of our ideas.

We have a functioning printer! More details in the next few days…

I’ve been racing to get my printer done before spring break starts (now) and I leave for a conference next week (Tuesday). The X and Y decks are in, the power is in, the boards are mounted, and endstops are mounted, the Z deck is in… but… I managed to destroy two of the three ribbon cables used to connect the motherboard to the stepper boards. Not sure how I’m going to replace them as they are no for sale on Makerbot.com. Looks like it’s time to email Bre.

Additionally, while building the plastruder, the insulation tape ripped and I am very unhappy about how loose it ended up being around the print heater. I am likely to order a supply of new items, like the insulation tape, to eventually replace it (summer)?

I’m angry at the build directions, as I can not find how the endstops should be connected, how the wires should go, and if I need to wait to do this. If one follows the directions to a “T”, you would not connect them. Finally, I completely don’t understand the popsicle stick and endstop directions. Can someone post a good close of series of photos of how yours looks? I’m not clear on where I’m gluing the sticks, size of the sticks, where they are placed, etc. The directions are far, far too vague.

We started some private discussion about what the user interface of the software portion should look like, how it should function, where the software should be stored (on a server or locally) and other logistical things.  One of the objectives is to make the software as portable as possible across as many platforms as possible.  This goal would probably be most easily achieved through a server-side software configuration that can be accessed via a web browser.  This would also make our challenges with accessibility a bit easier as well, since any modern screen reader will be able to handle a web interface right out of the box.  After all, the web is the future, right?  Of course, this does have some security issues we have to keep in mind.  For example, who will have access to this service, especially when it’s in its initial stages, and how can we control user access?  The first idea that comes to my mind is that we could put this service behind a firewall of some kind, and allow only certain people access through the firewall.  On the other hand, let’s say we go with the approach of storing the software locally.  We may have some accessibility issues to address.  Most screen readers communicate directly with operating system controls to provide the feedback that they do.  I reported a while back on this blog about my findings with virtual box, something I didn’t have much success with on a count of it using QT.  QT is useful because it makes it easy to make software more portable, but many screen readers will have trouble with it without some kind of modification, as they do not use standard operating system controls.  These are some of the design issues we are considering, and obviously there are tradeoffs either way.