• Subscribe

    Subscribe to This Week In Panospace by eMail.
    Subscribe in a reader
  • License

    Creative Commons License
    This work is © 2008-2012
    by Yuval Levy
    and licensed under a
    Creative Commons License.
  • Entries

    November 2017
    M T W T F S S
    « Dec    
     12345
    6789101112
    13141516171819
    20212223242526
    27282930  
  • Archives

Here We Go Again

hugin-logoHugin 2009.2.0 is still warm and fresh out of the oven and I have started the next release cycle. Hugin 2009.4.0 is coming soon to a download server in your neighborhood. The beauty of parallel development without trunk freeze and the discipline of managing the integration queue are starting to pay off: while I was managing the 2009.2.0 release, Tim added lens calibration to trunk and Thomas added a tool to clean outlaying control points by statistical method.

Three simple criteria and three increasing levels of maturity reduced the bottleneck that has plagued Hugin in the past three years as it had to learn to absorb more change than ever.

The three levels of maturity are:

  • “works for me”
  • integration in trunk
  • release to the general public

And the three tests are

  • functionality
  • multi-platform build
  • regression

Works for me

Developers are no longer hindered by trunk freezes. They can work on their ideas any time, simply by branching out a development codeline either locally or in the central subversion repository (I know distributed revision control systems. Andrew implemented Mercurial for Enblend and I love it. Right now Hugin is undergoing enough change. In a quiet moment we’ll open a discussion about the revision control system).

When the implementation is ready to move to the next level, it is checked against the three criteria. A development codeline – whether under revision control or presented as a patch against trunk – is considered mature when:

  • the functionality it is intended to implement works on the developer’s machine (“works for me” condition)
  • it has been tested to build on the major supported platforms (“does not leave them behind” condition) by at least one contributor for each: Windows, OSX, Linux
  • it does not unintentionally break existing functionality (“no regression” condition)

When a development codeline reaches maturity, it enters the integration queue.

Integration Queue

The integration queue is the ordered list of new features / development codelines waiting to be integrated in trunk. The prioritization is a collective decision by consensus of the developers. Silence = consent. The discussion, and the latest version of the list, are on the mailing list.

The integration queue is not set in stone: a change in the maturity status of a feature in waiting is good reason to review/change the ordered list. In any case it is reviewed after every release branching.

The integration queue is all about coordination. The code matures further. Ideally developers talk and there should not be conflicts. In the real world changes in trunk may affect the new functionalities or the other way around. This is the the time to solve this kind of conflicts, and to test the code on a (slightly) broader basis.

A feature from the integration queue is ready to be merged into trunk when

  • the functionality it is intended to implement works on the machines of the testers who bothered to play with the codeline (“works for them” condition)
  • it has been tested that a merge with trunk builds on the major supported platforms (“does not break trunk” condition) by at least one contributor for each: Windows, OSX, Linux
  • it does not unintentionally break existing functionality (“no regression” condition)

This limits the time during which trunk is unavailable. Integration of the features that have gone into 2009.2.0 and will go into 2009.4.0 was almost seamless. And the clean up from the 2009.2 release cycle has benefited trunk so mcuh that the 2009.4 release cycle is expected to be even faster.

If trunk has absorbed a feature from the integration queue and we’re not yet ready for a new release (e.g. because the current release cycle is still on), integration of the next mature feature from the integration queue starts.

Release

Developers are polled once a month whether trunk warrants a release. If there are enough new features and/or bug fixes compared to the last release somebody starts a release cycle. Instead of releasing from trunk, forcing a freeze, we now branch out a release codeline. That release codeline absorbs all the change control that was slowing down development in trunk to a halt. And the polishing changes that it get benefits trunk at the same time.

Again, a release branch is declared matured and released to the public when

  • the functionality it is intended to implement works for a larger number of testers (“works for the public” condition)
  • it has been tested to build on the major supported platforms (lives up to Hugin’s ideal of being “truly cross-platform”)
  • it does not unintentionally break existing functionality (“no regression” condition)

Resources

All of this would not be possible without human resources: developers, translators, builders, documenters. A big thank you goes to all of them for making this new, more dynamic pace of development possible. The recipe is relatively simple: every resource is self-directed. The least control is exercised on it, the more likely it is to contribute to the project. So the only controls are the maturity tests – and they can be self-administered. Self-responsibility and empowerment reign.

To me resources are like water. They will flow to an attractive codeline like a stream flows into a riverbed. Barrages (such as a trunk freeze) only impede the flow. Water finds alternative ways, and so do potential contributors. My only task left is to remove bottlenecks. Let them flow!

Google Summer of Code 2009 Wrap Up

Another summer is over. The maples in my neighborhood are changing color and we just finished our third Google Summer of Code (GSoC) participation, the best ever. Like the previous two editions, GSoC has been a catalyst beyond the five project slots generously allocated to us by Google. GSoC has been more than money. More than an opportunity to attract fresh contributors and get things done. It has been first and foremost a transformational opportunity, making an inherently insider organization an open and outward looking one.

Allocation

Google generously allocated five slots to us and this year we decided to allocate one of them to a smaller Open Source project. It seems to me that there is an ideal mentoring organization size (or at least minimum size) for GSoC participation. Smaller mentoring organizations require a similar amount of administrative effort as larger ones. Sharing is a way of enabling smaller projects to participate while limiting the burden on Google’s Open Source Programm Office.

There are many small Open Source projects in our related field, and in talks I had with them most expressed interest. I decided to work with Professor Sébastien Roy’s Vision 3D Lab at Université de Montréal and his LightTwist project for a few reasons:

  • I needed to make a case to our community that sharing is in our interest. Indeed there was a very short discussion about LightTwist’s relevance to the Hugin community.
  • Meetings and contacts between members of the Hugin community and of the Vision 3D Lab go back to Libre Graphics Meeting (LGM) 2007. We share a similar culture / attitude.
  • Last but not least, I was looking for more academic contacts to promote GSoC recruiting efforts.

The experience worked better than expected. We even organized a joint display of Hugin artwork projected with Lighttwist at LGM 2009. I warmly recommend other organizations to do the same: Next year give a lift to a smaller project!

Recruiting

This was my biggest deception this year. I did put a lot of effort upfront – contacting professors at relevant faculties in my region and beyond. The turnout – at least for us – was zero. Recruiting is indeed our bottleneck. This year again we had more mentors than allocated students, so we rotated mentoring responsibilities. Our recruiting needs improvement.

Students

One of the biggest question was to hire new students or returning ones? I am thankful to my fellow mentors for changing my mind on this one, and I hope our faithful returning students will forgive me. Initially I even convinced one of last year’s students to participate as a mentor. Then I asked him to submit a project proposal. Thank you, Tim, for your flexibility! Student’s life is IMO the most beautiful period in one’s lifetime, enjoy it while it lasts!

Selection

Three months are a short period. To make the most out of it candidates must be up to speed from day one. Following the lead of other mentoring organizations, we introduced qualification tasks. Despite some controversy amongst a few vocal students, it has worked well for us. Our goal was to determine basic proficiency with the tools. Other organizations, notably x264, have put more effort in the qualifying tasks so that they also determine if the candidate has the skill to complete the task. It may be more work, but it is definitely best practice IMO, and we should consider putting in this upfront effort.

Meetings

Remote collaboration works better after a physical handshake. I interviewed all serious candidates by phone and try to organize as many face to face meeting with community members as possible. More by lucky circumstances than by design we managed to meet all students this year: two at LGM in Canada and three at a dedicated meeting in the UK. These meetings have been very productive. Even face to face meeting did not prevent us from failing one student, but they are useful and we should try to bridge physical distance in the future as well.

Projects

Our two returning students did not have to get up to speed with the code base and could take on more ambitious projects. And indeed they did, beyond my dreams and expectations.

James Legg, mentored by Bruno Postle, refactored code deep into the core to implement his new layout model. The model works. Minor quirks in specific situations will be fixed. This project corrects a design weakness, unintended heritage of the pre-HDR time.

Tim Hugent, mentored by Tom Sharpless, produced an automatic lens calibration tool. The calibrated lens model still need a lot of validation work through practical use in the field. The potential benefits are improved precision and, beyond panorama making (and Hugin) better images from less than perfect lenses. This project was the first step in an exciting new direction.

Lukáš Jirkovský, mentored by Andrew Mihal, brought deghosting (the removal of moving artifacts from multiple exposures) to the next level and made it available to enfuse, the preferred choice for photo realistic exposure bracketing. Also this project will continue after the end of GSoC.

Yulia Kotseruba, mentored by Sébastien Roy, added new blending algorithms to LightTwist, making it possible to extend the projection surface vertically and opening up new fields of uses such as dome projection or, given enough wall space, a low-cost high-resolution IMAX replacement. Work continues and will be published in a scientific review.

Last but not least a word about Dev Ghosh, mentored by Daniel German. Unfortunately we had to fail Dev because he had not achieved the agreed (and revised) milestone. To his credit he got the mathematics right – his MatLab implementation works. Chances are that the code will be implemented in our code base, sooner or later.

A big THANK YOU to all the students for their effort and dedication!

Update: The only reason to fail Dev was quantity. The quality of his work was excellent. Daniel has implemented it in Libpano and it may become the first chunk of 2009 code to be officially released, with the upcoming libpano 2.9.15.

Integration

We found the right recipe for this last year and we recidivate. During GSoC students focus on implementation. They will integrate their code after GSoC. As an encouragement, they will be sponsored a panoramic head from Nodal Ninja, an industry leader that sees the benefits of supporting Open Source software that drives sales of its hardware. At the time of writing, the first project has been already integrated in trunk. Thank you, Bill Bailey, marketing director for Fanotec.

Community Development

On this year’s mentoring organization application form there was one interesting question about “criteria used to select community members“. This lead to some introspection, following which I drafted this community charter. Thank you, Google Open Source Program Office, for giving us food for thoughts.

Speed

GSoC projects have accelerated the pace of development. Our sequential development process with trunk freezes and long release cycles was no longer adequate. I’ve taken it upon myself to re-engineer it and at the time of writing we’re getting ready to release for the first time under the new, parallel process. I hope we can integrate and release all the code developed for GSoC 2009 before Christmas, and that our project team will increase it’s capacity to absorb and release code changes.

Generations

After graduating university I was offered a job at a company that I still admire (I accepted another job because it gave me the opportunity to expatriate). That company had a three year cycle: the first year you’re hired as a junior and trained on the job. if you did it well the second year your boss moves on and you put your imprint on the job, adding to it what you have learned. On the third year, you train a junior to replace you and if everything went well you’re promoted to the next job. This helped the company stay nimble and up to date. We need a similar attitude in our project. People come and go, and we need to groom the next generation of committers before the current generation fades out; and to document our processes and know how for the perusal of the next generation. GSoC has been a great recruiting ground and our next project leader may be amongst this year’s GSoC students.

Conclusion

Before our GSoC participations, joining Hugin was a steep learning curve. Still today we get consistent feedback from GSoC candidates and students that getting up to speed with the code base is the biggest hurdle they face. Things have improved. In 2007 with an SDK for Windows developers. In 2008 with the equivalent for OSX developers and with build documentation for different platforms. This year it was the release process, and there is more on the plate for the years to come – much of this thanks to GSoC. Thank you, Google!

Preparing the Next Release

hugin-logoHugin 0.8.0 has been released two weeks ago. Like with 0.7.0 the release cycle has been too loaded. We introduced plenty of new features (many developed during Google Summer of Code 2008), but forgot to fix some trivial things such as the location for temporary files (which can grow to gigabytes of size). Moreover, the prolonged trunk freeze has forced developers like Gerry Patterson and Thomas Modes to withhold those incremental improvements and bug fixes that make the difference between a software package with rough edges and a polished application.

I decided it is time to fix our release cycle and changed some things, breaking the old pattern. Most important, I’d like to make development independent of release so that we move continuously forward. I intentionally broke a few things and triggered a healthy discussion. It seems that we reached consensus and I’ve started to clean up the subversion repository. The next release will be 2009.2.

Besides pent up incremental improvement, there are some bigger changes on the horizon, but for 2009.2 we will retain only one of them: Andrew Mihal has added GPU support to nona. This means that users with a modern video card can leverage it for faster processing. This has been ready for a few months and it is time to release it. It will be the main change of the next release.

Our Google Summer of Code students will excuse me if I don’t talk about what’s beyond. This time we won’t make the mistake of loading too many things into one release. Their projects will follow, hopefully in rapid sequence, after 2009.2.

Below I document how I merged Andrew’s nona-GPU branch into trunk, hoping that it will be helpful for other merges. It shall be quick and painless – as long as the new functionality in the development branch does not work, it does not make sense to merge.

I started with a clean slate.

1) I fetched the branch from the repository

 $ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/branches/nona-gpu h.nona.gpu
 $ cd h.nona.gpu

2) I pointed the browser to the SVN log viewer for the branch

3) I identified the revisions concerned: 3510,3511,3522,3523,3535,3563,3568,3569,3574,3582,3583,3648,4069

4) I created a diff file containing all the changes in the revision

$ svn -r 3510 diff > nonagpu.diff

5) I checked out a fresh trunk

 $ svn co https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk hugin

6) I built to make sure the initial status is known and OK

 $ mkdir ../h.build
 $ cd ../h.build
 $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local ../hugin
 $ make
 $ make package

7) I installed it and tested to make sure it works

8) I moved and applied the patch

 $ mv nonagpu.diff ../hugin
 $ cd ../hugin
 $ svn up
 $ patch -p0 < nonagpu.diff

9) applying the patch identified two conflicts in two CMakeLists.txt files:

 ...
 patching file src/hugin_base/CMakeLists.txt
 Hunk #1 FAILED at 51.
 1 out of 1 hunk FAILED -- saving rejects to file src/hugin_base/CMakeLists.txt.rej
 ...
 patching file src/CMakeLists.txt
 Hunk #1 FAILED at 9.
 1 out of 1 hunk FAILED -- saving rejects to file src/CMakeLists.txt.rej

10) I fixed the conflicts manually

11) I built the merged code to make sure I did not break anything major

 $ mkdir ../h.build
 $ cd ../h.build
 $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local ../hugin
 $ make
 $ make package

12) I installed and tested

13) I looked at each of the revisions concerned in the log viewer, e.g. 3511 to find out if files where addded, deleted or moved, and used the appropriate svn commands to add them. It would have been faster to look at the diff file, but like that I could also read Andrew’s comments and code changes and understand what was going on.

 $ svn add src/hugin_base/panotools/PanoToolsTransformGPU.cpp
 $ svn add src/hugin_base/vigra_ext/ImageTransformsGPU.cpp
 $ svn add src/hugin_base/vigra_ext/ImageTransformsGPU.h

14) In the end I was ready to commit

 $ svn ci

So what is the current status and what is next?

The code added a new dependency on GLEW. Most likely that this breaks the Windows build until the SDK is updated. So we need to update the SDK.

Andrew’s GPU code works and is available with the switch -g to those building trunk SVN4146 or later. I started to investigate support of the feature in the GUI, although in my opinion it is not mandatory to have GUI support to release the new feature.

There are enough new features in trunk so that when at the beginning of September the Hugin developers are polled whether to release or not, chances are that we’ll decide to go into release mode. My wish is to see this release out in September. Even if it will happen before the end of the year, I will be more than happy. Maybe a quantum leap for the project?

LGM 2009: Conclusions

Time to sum up my feelings about Libre Graphics Meeting (LGM) 2009 and set targets for the next twelve months, inspired and encouraged by Jon Phillips.

LGM2009: what went well

  • Venue: Excellent support, good infrastructure, and extremely useful recordings of the conference (thank you, Kaveh Bazaragan). The offer by Louis Desjardins to hold LGM regularly in this setting should be considered seriously. Kaveh’s offer to host us in India is very attractive as well. Never been to that part of the world…
  • Format: Single track is just right! Stick to the clock. Session length appropriate. Good mix of sessions, lightning talks, BoF. Plenty of opportunities to get things done and network.
  • Attendance: A good mix of artists and developers.

LGM2009: what could have been better

  • Echo in the local media (I tried to get noticed with the Ultra Wide Views exhibition but strictly speaking I’m not local).
  • Interaction with the local public (my impression is that there was less local public than at LGM2007).
  • Outreach beyond the world of Free graphics. Everybody has imaging devices nowadays and we need to convey to them that this software is for them too.

To do for LGM2010

  • Decide on the venue ASAP. This is the single most important issue on the critical path to leading to LGM2010. The discussion on the mailing list seems to have fade out?
  • Reach out to the general public! Ginger Coons suggested tupperware parties? Let’s show schoolkids that they need not pirate software to be creative. Let’s share our creations with the general public. Let’s get the media buzz going. Concentrate a few speeches geared at the general public on the Saturday. Make the exhibition last longer than the conference, with the conference being its culminating point. Entice the general public to learn about free graphics.
  • Keep the buzz going – my feeling is that there is not enough going on in between conferences. I’d like to see more activity on the mailing list. We need more fund raising in these difficult times.

Hugin at LGM2009

Lucky circumstances had it that I could offer free lodging to those of our team that were attending. Being that close was a unique opportunity to discuss the challenges ahead, both immediate (with two of the new Google Summer of Code students due to start coding soon) and in the longer term (with Andrew Mihal, Pablo d’Angelo, Jim Watters). While I would prefer to focus on the creative process rather than on the tool-making process, we are still at a stage where tools require more attention than I’d like.

  1. The first exhibition of panoramic artwork was a good start. It provides a stepping stone for a V2 at LGM2010 (or 2011?). I’ll summarize key learnings at some point.
  2. Our tool-making process is not ticking regularly enough yet. We’ve discussed a fix for our release cycle (we do not subscribe to ffmpeg’s philosophy and we are far behind compared with the best practices of the Libre Graphics pack). Pablo had a good idea for a new naming convention. Hugin-0.8 is due very soon. After that we’ll initiate the changes.
  3. Our organization needs to grow to the next level. Here again, we’ll be looking at best practices in the Libre Graphics world and shamelessly copy you.

To do for Hugin 2010

  1. Get more artists to physically attend the conference and present their work. I liked Stani’s presentation; an inspiration for next year. I did not really plan jumping in for Tom and presenting his new tool. Next year we shall also have at least one tutorial session to introduce people (possibly from the general public) to the joys of panorama photography.
  2. Deliver the tools to the users at a faster pace. Users have been waiting almost a year to have convenient access to tools introduced during Google Summer of Code 2008. We intend to shorten that time with the current crop of Google Summer of Code projects.
  3. Structure our organization to better handle donations (foundation? ideally piggy-back on something existing rather than reinvent the wheel) and go more systematically about recruiting which is currently also not diversified enough.
  4. Help another small Libre Graphics related project to jump on the bandwagon. This year Hugin made the conscious decision to allocate one of its Google Summer of Code slots to Lighttwist. I believe that giving a lift to like-minded projects and helping them establish reputation as recipients of student slots within the GSoC universe is in the common interest. For 2010, should Google elect to run the program again and should we be accepted as a mentoring organization again, I already spoke with Rafal Mantiuk. He would love to have a student work on pfstools. Whether I can pull my friends at Hugin in this direction remains to be seen – the connection between Lighttwist and Hugin is a more obvious one than between pfstools and Hugin. But I am confident that this is of strategic interest to Libre Graphics as a whole, beyond Hugin.

Umbrella Organization

One fact that can’t go unnoticed is the complete absence from LGM of one of the biggest Free Software sponsors. And I am not talking money. Leslie Hawthorn of the Google Open Source Program Office was a two hours drive away, in Ottawa, at BSDCan. Why couldn’t LGM attract Google Open Source Program Office to hold a presentation? What can we do to improve this, and maybe even convince Google to return to be a full sponsor of LGM like it was in 2008?

I think one of the issues is that we’re still too splintered. Libre Graphics would be better off if we can set up some sort of umbrella organization to handle our common interests.

  • Umbrella organizations such as Gnome, KDE, FreeBSD and others are heavy weights of the Google Summer of Code program. The logic is simple: Leverage. Google leverages the mentoring organizations to manage projects. The more student projects a mentoring organization takes care of, the more attractive it is for Google to work with it. An umbrella organization as an added layer makes the program scale better. It reduces the strain on Google’s resources for a given quantity of students while providing the necessary quality assurance. I’ve added a feature request in that sense to Melange’s tracker. An umbrella organization could allocate slots within projects that taken alone would have little chance to be selected as mentoring organization, and many Libre Graphics projects qualify in this category.
  • Hugin is not the only project that needs a formal way to handle money. Other projects have already been down that road. Why reinvent the wheel? We could learn from their best practices regarding tax exempt status and other issues. Or even better: why start a foundation if there are existing ones? We’ll be looking not just to learn from existing foundations, but also to explore whether there is a natural fit for us to join forces. Pablo agrees that joining an existing foundation is the best option for us, and my wish would be to join an umbrella foundation for Libre Graphics.
  • I hope I’m not the only one who wants to help other small Libre Graphics projects on the bandwagon. As a team we can help more efficiently.
  • Last but not least, the umbrella organization could give a base to the Libre Graphics teams organizing the local meetings. As such, we already have a candidate leader for the umbrella organization: Louis Desjardins has done a terrific job at LGM2007 and LGM2009 – plus all the support he has given to the LGM2008 organization. I did not discuss this endorsement with him and I hope my proposition does not  anger him: Louis for president!

Academic Track

One of the directions discussed at the end of LGM 2009 is to improve ties to the academic world. There is a natural fit between motivated students (not only in computer science) and Open Source. With Micheal Terry of University of Waterloo (a pioneering institution that it lets students keep intellectual property to their work, enabling them to release under Free licenses); Nicolas Robidoux of Laurentian University; Sébastien Roy of Université de Montréal; there were at least three professors presenting at LGM. And let’s not forget Benoît Ozell of École Polytechnique who made LGM’s infrastructure possible. We need more. Universities can leverage Free software as teaching instrument and research ground; as well as a lower cost, high quality, self-maintained infrastructure (not a negligible point in these times of shrinking budgets). Free software’s benefit would be a reneweable source of recruits: as generations of students come and go, some of them may stick around. Others will just make a small part of the journey with us as a way to start early establishing a track record for their future professional career. Tht0s good too. I am proud of the ties Hugin developed to Lighttwist and the 3D Vision Lab at Université de Montréal. We need more such symbiotic relationships.

Usability and User Interfaces

One of the hottest topics throughout the conference was user interfaces.

Jon seems to be sold on the web based stuff. Listen to his talk. I’m skeptic. The cloud buzz reminds me of early day eCommerce buzz, and more specifically a Powerpoint slide (I think it was a McKinsey consultant) ranking goods and services in order of eMarketability. That slide made perfect sense to me: goods where the touch/feel/smell experience is important (e.g. cigars) don’t sell well over the net. Twelve years and a few bubbles later another smart consultant may have already a similar slide for the cloud. Great for new media publishing; for transparent data backups and other back-end services. I bet that graphics apps in the cloud are not far away from cigars in eCommerce. For services that already have an inherent dependence on bandwidth, the cloud is indeed a great thing. Redundancy is good.

I found Michael Terry’s lightning talk about kinematic templates one of the most refreshing and interesting contributions. Time to apply these same principles to general menu navigation. Apple does it the hardware way by putting the menus always on top of the screen so that reaching for a menu I don’t have to slow down and target the item precisely as if it was in the middle of the screen. With screens becoming ever larger, the approach has its limitation. Not every pixel on the screen has equal weight/importance and this should be mapped to a sort of gravity map in mouse movements. Drawings / kinematic templates are the first and most immediate application to this. Kudos!

Video Editing

Before LGM I had this perception of void in the area of video editing. I did my research six months ago when I bought this great camcorder to share the joys of a grandson discovering the world with my parents across the pond. I want to spend time video editing, not trying to make the tools work. Result: I bought SONY Vegas 9 Platinum Edition to replace the useless stuff that comes bundled with the camcorder and has the limitation that it does not work with anything else but the bundled camcorder (serial number check!).

Jean-François Fortin Tam gave an excellent presentation about PiTiVi. Interestingly, he was perviously also a Vegas user – Vegas is in my opinion the least worse of the pack of video editing applications, all licenses considered. PiTiVi looks promising, but it seems to be only available for Linux, still lacks some basic tools such as fade transitions, and as Jean-François said, tog et something useable you still have to make an effort to make the tools work by getting them from the repository. I have not tried it yet, but it may become an interesting alternative in a few month, when the project will release something stable that will be picked up by the different Linux distributions.

What really inspired me was Bassam Kurdali’s speech describing the use of Blender as a video editor. During Bassam’s talk I grabbed a video to my notebook and tried to follow in his footstep. And guess what? I’m sold. From a user interface perspective, things worked very well for me. Only a technical issue for which I filed a bug report is keeping me from making my first steps in Blender as a video editor.

User Interfaces Revisited

Using Blender was an eye-opener to me. My greatest fear, which turn out to be unwarranted, was that a complex tool would have a steep learning curve. What I found out was the other way around. Blender has a user interface metaphore constent across the board (even across different operating systems, which is a plus) which makes it so easy to take the plunge! It interface effectively between the users and the very broad and sometimes extremely complex set of functionalities. It scales nicely and once a few basic concepts are understood, it is very effective. Blender rocks!

This brings me to another (last) topic in this long post: UI consistency. As Ginger Coons said in one of my preferred talks designers like Adobe. In my opinion, one of the factors that contribute to this liking is the consistent user interface. When you know how to handle one tool, you know how to handle all of them. Many Libre Graphics software have a rather rough user interface (and I include Hugin in the pack). The notable exception is Blender.

The UIs of our tools are too disparate. I know my following wish won’t happen any time soon. I know all of our tools have their own unique histories, cultures, dependencies, likes and dislikes. But I am allowed to dream, right? So let me drop the bomb: If I could, I’d put a layer of Blender UI on top of all of them. Because the Blender UI is so great. It’s consistent across the tools and even across operating systems. My guess is that this is the result of a well thought-through design because the people at Blender were confronted with a bigger problem than the rest of us. They had to interface between their users with a set of functionaities that is far more extended and often times more complex than any other graphics tool. The result of their design effort is a UI with a clean and consistent metaphore. Learn that, and you’re half-way on the learning curve. It is easy to learn and efficient to use.

Conclusions

LGM 2009 was great. Dreaming is permitted. But most important, we need to take consistent actions throughout the year and build on top of what has been achieved to make LGM 2010 even better. For myself, I’m off for a one month trip back home. When I’m back, I’ll tackle those priorities that are in the realm of what I can do. For the rest, I am ready to team up with whoever shares the vision of a stronger, united, Libre Graphics Universe.

LGM Day 3, Day 4, Follow Up

Days went by so quick, so here is a summary.

Day three was intense. The presentations were very interesting, particularly those of Andrew Mihal about Enblend-Enfuse and about GPU stitching. In the evening we had the conference supper, a very pleasant social event at which I learned from about Øyvind’s Now By Then installation and got a chance to purchase one of the last “Architecture Fiver“‘s  that Stani brought along for his talk. He also patiently gave me an insight into the thinking pattern of curators, lifting my morale from the previous day.

On day four I had a near-death experience. Since Tom Sharpless could not attend, I picked up his slide and hosted the talk. In the morning I prepared my notebook in dual display mode, so that on one display I can run the demonstrations of Panini, MathMap and Hugin, while on the other display I had my notes, which I kept editing until shortly before my talk. Without saving. Disaster strikes when I connect the notebook to the projector. My notebook’s native resolution is 1400×1050, too much for the projector to handle. Must restart X. Lose all presets and notes! I froze on the spot. Had to cut on a few gimmicks such as recording the talk with the catadioptric lens or shooting a stitched panorama during the talk (I made the move with the camera around the tripod, but had no available brain cycles to even think of setting the exposure or pressing the real button. I felt like a zombie and was disappointed at my performance which I felt was terrible, although a look at its recording comforted me: it was not that bad after all, even if I forgot to say half the things I wanted to say, the live demo and the interaction with the public were not that catastrophic.

The good news from day four was that Sébastien and Vincent debugged the flat display in extremis so that people walking out of for the lunch break passed by and could admire Guillaume’s stunning Boulevard Bancel (we’ll gladly admit that once this was on screen and working we pulled the cables on the slide show so that nothing can go wrong. Proper slide show the next time).

Since the cafeteria was closed on Sunday, we had to order pizzas for lunch, which was great as it inspired more exchanges before the last presentations. In the end, I even got the honor of shooting the official group picture, and to offer some of the present teams a panorama inside a panorama in the Cyclorama, while our team helped folding up the exhibit canvases.

After protracted good byes, I drove eastwards with Alexandre and Pablo. Alexandre only joined us for a tour of Québec-City. Pablo continued with us to Boréalie before I drove him back to Montréal for his flight on Wednseday. The rest of the week, and the weekend, I had to catch up with pent up business. Particularly the weekend was difficult, with a few difficulties upgrading servers remotely from FreeBSD 6.3 to FreeBSD 7.2 (the worse thing is that all manipulations worked well on the guinea-pig server in the office that is pretty much an exact mirror of the servers to be upgraded).

I still made time on Sunday evening for another quick hop to Montréal, and I am happy I did. Joergen Geerds was visiting for the weekend with his girlfriend. Interesting people.

After

LGM Day 1

We’re at LGM. Yesterday  I picked up the Ultra Wide Views, Fahim in downtown and Pablo coming from Germany at the airport. We spent the late afternoon / early evening mounting all the canvas and the few photopaper prints; then we looked at Sébastien, Vincent and Jean-Ambroise set up the LightTwist driven Cyclorama. We had a bite with Benoît Ozell, his support for everything happening here at École Polytechnique de Montréal is fantastic. Dev Ghosh joined us after his plane landed.  Jim Watters arrived after dinner. I worked until 3 AM on my notebook.

This morning most things worked as planned but still neded some oiling. The exhibit of 360° views from a dozen artists on the Cyclorama was ready just in time for after Sébastien’s speech, with some minor details corrected afterwards. It was delighting to receive the visit of .Jean-Pierre Lavoie, one of the most successful panorama photographers in Canada, who has pioneered usage of immersive medias in the news. LightTwist made a great debut.

I am running on my last juices, but all the interesting people keep me going. It’s good to see familiar faces; to put a face on a name known from the mailing lists; to meet new people and hear about new ideas. This conference is refreshing. I’m capturing some of the moments on video, but won’t have time to process it for a while.

Andrew Mihal arrived a few minutes ago and Yulia Kotseruba is scheduled to arrive late tonight. This will complete one of the largest Hugin developers line-ups in a single location. Friday night is the conference’s official dinner, but we’ll have our team dinner Thursday night in a yet to be defined place.

Accepted Students for Google Summer of Code 2009

MascotteThe dice have rolled. For the third year in a row the Hugin community will mentor five Google Summer of Code students as they go about writing free software:

  • James Legg of Fast Preview fame will tackle the Layout Panorama Model mentored by Bruno Postle, improving the handling of stacks.
  • Tim Nugent of Celeste fame will tackle Straight Line Detection for Lens Calibration mentored by Tom Sharpless, improving the handling of fisheye lenses.
  • Lukáš Jirkovský, too young in 2008, has become a significant contributor to our community over the past year and will tackle Ghost Removal for Enfuse, mentored by Andrew Mihal.
  • Dev Ghosh will add Mosaic Mode to Hugin/Panotools, mentored by Daniel German.
  • Last but not least Yulia Kotseruba will add functionality like multiple blending to Lighttwist, mentored by Sébastien Roy.

I am particularly proud of the collaboration with Sébastien Roy on Lighttwist. First, because I believe there is a cultural fit between his Vision3D laboratory and the Hugin community. Second, because it is good to see academics releasing the result of their research (which, let’s not forget, is often funded with public taxpayer’s money) to the general public under an Open Source license.  And last but not least, because I think that Lighttwist is the natural extension to Hugin. I would dare to advance that Lighttwist is to panoramic photography in 2009 what QuickTimeVR was to it in 1999. In a private email exchange Ken Turkowski, inventor of QuickTimeVR and one of our team, acknowledge the analogy.

Then there is a sixth project that I care about. We have teamed up once again (and we hope to be luckier this time) with VideoLAN to bring QTVR playback to this popular media player. This time with an extra bonus: Wiimote control. León Moctezuma, who in 2007 added SPi-V playback to FreePV, will build on his expertise of FreePV and add the Wiimote on top of it, mentored by Antoine Cellerier of VideoLAN.

What’s next for the students? this article I wrote exactly one year ago applies.

Good Luck, students, I hope to congratulate you all in a few months.