I am currently pursuing interests in computational methods, signal processing, and image processing. In the first part of 2007 I concentrated on a mathematical topic: the connection between matrices and geometric algebra. Just recently I have spent some more time looking at computer languages with a view to pinning down more of the design for the drawing system.
I have been interested for a long time in a matrix operator called the gyration. In 2006 I was bringing results together and tidying up some loose ends when a mention of a Moebius transformation and its connection with rotations on a sphere under stereographic projection led to the result that gyrations can be expressed as rotations under certain projections. The further discovery that all this could be more easily described using geometric algebra (GA) led to an exploration at the beginning of 2007 into the connection between GA and matrices.
I haven't been doing this in order to discover something new, but instead for the fun of discovering things for myself. In fact, little if any of it is new. I continue to be a little dissatisfied with some aspects of GA, and I ended up trying to avoid what I see as two problems. First, the elegance of the geometric product is, I think, often quickly lost through the reliance on inner and outer products. Second, multiplying basis elements with reals and adding them to reals (along with other similar products) seems to me to be an error. From the computing point of view it is a bit like trying to apply the addition operator to incompatible types. This may not have great significance, but the more that the essential elegance of GA may be preserved, the better.
I haven't done a lot of image processing recently, though I have a few ideas for improving on some of the available techniques. The primary purpose and naming of these techniques have recently changed. Before, the interest was in contrast enhancement. To some extent this still holds. However, the increased availibility of, and interest in, images with high dynamic range (HDR) has led to more emphasis on dynamic range compression. Techniques are also called tone mapping, though perhaps dynamic range compression is a special case of tone mapping or contrast enhancement.
Perhaps more importantly, I think that useful contributions could be made to this field in a couple of ways. The more significant one is that adaptive methods do not work particularly well in a clinical setting. This is in large part not a matter of improving the underlying methods. In fact, I think that the lack of progress in the past has been the pressure to invent new methods that can be universally and indiscriminately applied. Instead, effort should be put into developing tools that can be used by clinicians in a practical setting. I have ideas for this, but I don't think they are particularly clever. The problem is that researchers do not have the incentive to develop them.
An important, though less significant, contribution might be made in encouraging those writing tutorials to go easy on the enhancement. As a rough guess, the examples that I have seen in tutorials use about twice the strength of enhancement that is desirable. Yes, one should apply strong enhancement to check for artefacts, but the final result should not eliminate all shadows in the composition. For example, it is possible to lighten up the foreground landscape in a sunset scene, but doing so does not so much enhance an image as make a wholesale change to it. In consequence, these tutorials and samples do not serve as good advertisements for dynamic range compression, especially not to the serious photographer who would be most interested in HDR images.
For many years I have played around with drawing programs for pleasure. This has provided me with an excuse for learning new languages and concepts. The idea has been simple: write a fairly small graphics engine that is extensible in a similar way to emacs and TeX. This demands a program that is very well crafted. I have formulated a kind of object system for this purpose. The current design question with which I am wrestling is if this should be implemented as a subsystem of data using an existing language, or if it would be better to use a modified language with the data types as inherent to the language.
One might have hoped that over these years such a program would have emerged. However, I have yet to see any open source drawing project built upon a simple core in the way that I have in mind. The fact that the XFig and Gnuplot projects are alive and well I think bears this out. I have put some examples in this Sourceforge project website. In the immediate future I need to pin down the design decisions for the underlying language. With a background in DSP and using Matlab, Octave and so on, I wish that the language could handle matrices and sequential data well. However, the extent to which that is feasible is yet to be seen.