It was around early 2008 when I started to embark on a journey that would turn out to add a lot of fulfillment, knowledge, and experience to my life (and also keep me busy during my free time). That was when I started developing dispcalGUI, a graphical user interface aimed at display calibration and profiling using Argyll CMS, a command line driven color management system.

Until then, I had used Argyll CMS occasionally from time to time (I remember first discovering it in 2005), and around 2007/2008 started to use it as a tool to explore color and learn more in-depth about ICC color management from a software development perspective (I had prior knowledge as a user of ICC color management as part of my day job at an imaging and prepress house until 2006, before I became self-employed as a web developer).

I also began to grow dissatisfied with the display calibration and profiling software I was using privately, and realized that Argyll CMS did a much better job at generating a hue neutral calibration (an aging CRT that I used back then had a significant green cast in the shadows through midtones in its uncalibrated state that Argyll CMS managed to get completely rid of). I didn’t object to using Argyll CMS from the command line, but started to write a simple graphical user interface in Python (which I already had some development experience with)—with wxPython as the GUI toolkit—that would help me explore the various options without having to remember command line switches and their effects. I had no plans to make my work public at the time, in fact I didn’t even think it would be useful to anyone (it was really, really rudimentary UI-wise).

But in the same year, Argyll CMS hit its version 1.0 milestone, and subsequently I became increasingly aware (by reading forums and mailing lists) of users actually wishing for a graphical interface. I began to wonder if I should build upon what I had and release it publicly under an open source license. So I decided on the not very creative and near unpronounceable working title that would ultimately not change to this day, and began to work on this little project in my free time. I remember an ever-increasing drive and motivation coming along with this endeavor—several other people had announced their development of GUIs for Argyll CMS, and I wanted to be among the first to present something useful. In retrospect, I feel a little silly for worrying that somebody else might beat me to the punch the way I did back then—a few others managed to release their GUIs before mine was ready, but theirs seemed even more rudimentary.

The first version of dispcalGUI, numbered 0.1b, was publicly released on August 18, 2008 and still a bit rough UI-wise, but already fully cross-platform and had a few interesting features, like the automatic detection of measurement instruments. Back then I was definitely a little proud of what I had achieved in a relatively short amount of time. I received a good amount of really positive and encouraging feedback, which I remain thankful for (and keep getting) to this day.
Since then, I continued working on the project whenever I had free time available, adding features, fixing bugs and testing, testing, testing.

Over the years, I increased my knowledge of the inner workings and structure of ICC profiles, and wrote a little parser library to that effect. I learned a lot about systems, packaging, general software development advances, and interesting color and (human) vision related topics. Through following my own internal roadmap, reacting to changes and advances in the supported platforms as well as Argyll CMS itself, and by incorporating user and developer feedback, I kept driving the project forward, even though there were occasions when I had little time to further its development.

In 2010, following users repeatedly asking for a possibility to donate money to the project, I started accepting donations to aid development expenses—beforehand I wasn’t too comfortable with the idea, because I didn’t want to pressure myself into having to work on a project where a main driving factor I felt was that I could work on it whenever I felt like it and had the time, but ultimately that turned out to be a non-issue.

Fast forward. In 2012, I finally hit version 1.0 (although that was never released in binary form, the binary release was actually 1.0.7.6—the last two numbers coincide with my birth year and the release was on my birthday). Since then, development pace has continually picked up, ultimately resulting in version 2.0 being released last year and 3.0 this year with significantly overhauled UI, following an Argyll CMS 1.7 release. This brought another change with it in the sense that I’m now actively asking for donations to compensate for time and resources spent, and because I want to support Argyll CMS itself in a more direct way (all donations received by me are currently split 50/50, after deduction of PayPal fees, with me using one half and donating the other to Argyll CMS each month), the latter being a factor that I previously didn’t give much attention to even though I probably should have (dispcalGUI isn’t really useful without Argyll CMS).

My hope is that I’ll be able to continue working on this project, interacting with users and developers, furthering and refining it as time goes by.

And finally, a few lessons learned during development that may be helpful to people looking to develop a cross-platform application using Python (this is not an exhaustive list by any stretch of the imagination, and I might come back and amend it once more things come to mind):

• Cross-platform and general Unicode support in Python 2.x is not very good. It’s easy to introduce unforeseen issues even if coding carefully (some of the potential pitfalls are mentioned in the Python Unicode HOWTO, but that’s really just the tip of the iceberg). You’ll likely run into unexpected Unicode-related problems depending on platform, when you’d expect such differences to be abstracted away by the module in question. For example this os.walk bug, or the subprocess module—the latter under Windows fails with anything not representable in 7 bit ASCII, under Linux/Mac OS X it works fine as long as the file system encoding can represent the Unicode characters. In such a case, the only solution is to restrict yourself to characters representable in the file system encoding, and hand byte strings over to problematic modules. Or exclusively develop for Python 3.x instead, where Unicode support is much better and consistent.
• Platform differences in GUI behavior can be very annoying and cause unforeseen problems. If you plan to support multiple platforms, think hard about which GUI toolkit you are going to use. If the toolkit you’re considering wraps another toolkit which is native to the respective platform, like wxPython/wxWidgets does, you are very likely to run into these platform related issues. Something like Qt seems a better choice in such a scenario.