CinePaint Status and Mac OS X

Hi. Hope everyone is well.

Sorry I've been away from CinePaint for a while. I've been working long hours and have had less time for free projects. In case anyone is wondering, I'm still working on CinePaint when I can find free time.

My focus recently has been on the build system, something that's always been a sore point with CinePaint. Because I'm spending more time on Mac OS X lately (using Final Cut Pro), that's where I'm focusing on CinePaint now. I want the Mac release fully automated so anyone can build it from a script. That's a bit more complicated than the script I wrote to do that on Ubuntu because every supporting lib must be downloaded and built from source on the Mac, not just the app.

On the Linux side, I thought I was going to quickly wrap a release long ago so we can get back into Ubuntu and Debian. When I did some testing I found fresh bugs in the CVS version. One that's particularly annoying is all the windows lose their screen positions and pile on top of each other. That made it more effort than I'd expected and put me off. I did think I'd get back to it much sooner than this.

Thank you to everyone for your support.

The New CinePaint Team

If you’ve looked at changes to our CinePaint Team web page this week, you may be wondering, who are all these people?


Image courtesy U.S. Air Force

Types of CinePaint Developers

Under our CinePaint Active Developers section is everyone who’s contributed a patch or code via CVS that I expect to have included in our next release. Because volunteer developers cycle in and out of the project at will, I define who’s active based on actual contributions, not on factors such as whether they’re working on CinePaint today or have written code that I haven’t seen, yet.

Under our New Developers section is everyone who’s volunteered to join CinePaint recently. Recruiting and training new volunteers is part of my role as project leader.

With new volunteers, I can’t tell at first who’s going to be stellar and who will flake. To separate the wheat from the chaff, I have new developers start by building CinePaint from anonymous CVS. Unfortunately, most new developers will give up and vanish without completing that simple task. Volunteers simply fade away when they get busy with something else or discover that software development can be challenging. This isn’t a problem special to CinePaint. It’s normal.

Under our Secret Developers section is...well, that’s a secret. In the film industry, it’s normal to work in secret, to wait until your next movie releases before you reveal any of your tricks. If you’re a studio programmer working on something you want to open source, there’s the question of whether the studio legal department will eventually allow you to give the code away. There’s no point in announcing anything until that’s decided, when I actually get the code. Sony Pictures Imageworks and ILM are studios that have contributed code.

Another type of secret programmer is the graduate student working on his thesis. Stefan Klein, who added CMS and 16-bit binary fixed-point color support to CinePaint in 2004, is an example of a grad student developer who made a significant contribution. Graduate work isn’t that secret, but the student may not want to announce his research too broadly until he finishes his thesis. We don’t have any grad student projects currently.

New Release Manager is the Old Release Manager

One of our team changes is me. Based on community feedback, I decided that getting CinePaint released and back into Debian should be our highest priority. Not counting our Mac native port release, CinePaint hasn’t had a new release since June 2007. As discussed here previously, CinePaint’s release manager was set on a plan that would not make Debian any priority. When we couldn’t agree on a plan, he resigned. I’ve become the release manager again.

Debian CinePaint Support

As part of an effort to get our Debian and Ubuntu distribution in order, I’ve reached out for help in those communities. Lars Wirzenius of Finland, who I met at Ubuntu FOSScamp last week, has volunteered to help with our Debian packaging. He joins Jonas Smedegaard of Denmark, who I met at Open Source Days, and H.S. Teoh, who contributed CinePaint’s Scons patch. All three are official Debian packagers, not trainees.

Ubuntu CinePaint Support

Lars Wirzenius is both a Debian packager and a Ubuntu packager. He’s our new Ubuntu packager. At FOSScamp I saw Ubuntu community manager Jono Bacon, who’d already offered support. Although not at FOSScamp, Ubuntu Studio project lead Luis de Bethencourt has promised to help as much as he can. I talked with Ubuntu project leader Mark Shuttleworth. He sat in on my FOSScamp presentation on Open Source Team Leadership. He suggested that CinePaint use Ubuntu LauchPad and make use of the Bazaar version control system. More on that another time…

Love you guys!

Robin

Ubuntu FOSScamp This Morning

I'll be at Ubuntu FOSScamp on Friday, December 5th, and then until 3pm on Saturday the 6th.



I'll be talking about Multimedia Apps, OSS Biz Models, C++/OO/Agile/Literate/Team Programming, Hollywood Linux, and ideas for the Desktop 2020.

Love you guys,

Robin

More CinePaint Build Systems

<< Why is CinePaint adding another build system when you have autoconf and just added CMake? >>


Image courtesy U.S. Air Force

Autotools has always been troublesome for us. The autoconf-automake-make tool chain can be very time-consuming to debug and few find it easy to learn beyond the basics.

CMake is a popular alternative to autotools. CinePaint developer Michel Lesoinne has done a great job creating CMake build files for CinePaint. That's recently completed and now available in CVS for testing.

CinePaint is moving away from dependency on a single build system. With multiple build systems implemented, if one system gets wedged, as has happened several times to us with autotools, we can still build CinePaint using an alternate. Having a broken build system creates panic in an open source project. It's an emergency that must be handled before anyone can do anything. That's stress we can do without.

I've received a patch for CinePaint SCons build support, based on Python, from H. S. Teoh. I'll be committing that to CVS soon. It's half way there, not ready for testing yet. It builds CinePaint except for its plug-ins.

Cons is yet another build system. This one is based on Perl. We're just getting started on that.

Autoconf, CMake, SCons and Cons are all viable build systems. There are developers who love each system. Why pick only one? It's better for developers who join CinePaint that they can use their favorite build system tools, that they aren't forced to learn a tool they don't know or don't like.

Except maybe for autotools, that nobody seems to enjoy working on maintaining, we have the resources and the expertise to support multiple build systems. It's fun to have more choices. Isn't that what open source is about?

Love you guys!

Robin

CinePaint Procedural Brushes

<< Is there much of a community for CinePaint photo editing? >>


Image courtesy photographer Per Inge Oestmoen

Yes. Here's our new web gallery of CinePaint pro photog user Per Inge Oestmoen.

<< How much do you care about features such as CMYK, color matching, floating point image manipulation, better tablet support and procedural brushes? >>

I care a lot. That is, as much as I dare to care about anything in CinePaint when I have no budget with which to be able to direct development or enforce schedule.

CinePaint has had floating point and CMS for many years. That's 32-bit FP and more recently 16-bit Half. 64-bit float is a feature request to support 64-bit TIFF.

There's limited CinePaint CMYK support in the context of CMS. Core support of exotic channel layouts such as XYZ and RGBAZ and heterogeneous mixed bit-depth images are feature requests to better support OpenEXR. That could include full CMYK support.

Wacom has supported CinePaint tablet development by providing tablets. Many other vendors have provided hardware, too. I'm our tablet tester. Our tablet developer has moved on. Would love to have help there, especially on the Mac.

The plan for brushes is to create a dll C API so C/C++ programmers can create procedural brushes as external plug-ins. Our first step toward procedural brushes could be to make our existing brushes into plug-ins, the clone brush being the hardest. Healing, vibrancy, picture tube, colorization, alpha, and selection brushes are feature requests to be implemented as procedural brush plug-ins.

Our CinePaint CMS wizard recently retired after five years of CinePaint development effort. We need someone to step up and fill his shoes.

Love you guys!

Robin