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

CinePaint and Perl

These developer notes are for the benefit of those working on adding Perl support to CinePaint...


Image courtesy of photographer Terry Lane

There's no Perl in CinePaint now. In CVS I have a little Perl batch script I wrote to create thumbnailed web pages from a directory of images, but that uses GraphicsMagick.

There are two open Perl CinePaint tasks. One is to add CinePaint support for Cons, a clever 3-thousand-line Perl script that replaces Make and Autotools. The other is to support Perl as a scripting language in CinePaint.

Embedding Perl

CinePaint supports Scheme and Python as scripting languages now. We want to add Perl (and also Java). Perl's been implemented for GIMP, although active support there seems to have ceased. It should be feasible to adapt GIMP code to bring Perl into CinePaint.

O'Reilly "Advanced Perl Programming" has a chapter on embedding Perl. You may want to review that before starting. Limited C knowledge should be sufficient. Embedding Perl is integration of existing code from GIMP, not a coding project. 

IMPORTANT! Do not post any plea for assistance from GIMP. They 
consider CinePaint their rival. It just makes them mad to mention we exist.

We probably want to use recent GIMP source code and may also want to refer to GIMP 1.0.4 from 1999 (when CinePaint was forked from GIMP). There hasn't been much attention to GIMP Perl. It may be nothing has changed in a decade.

Building CinePaint Using Perl Cons

We need to create Cons build files for CinePaint. We want to use Cons before getting into improving it. You can look at the existing CMake or Autotools build scripts for clues what to put in the Cons build files.

Cons is in CinePaint CVS. Cons is orphan open source software. There is no support. There is documentation with it in our CVS. Using Cons 2.2.0, the last stable version.

At this point, don't worry about getting fancy with detecting library paths in Cons, just go ahead and specify those absolutely to your distro locations. Unless somebody discovers a secret auto-detect mechanism in Cons, we will create an auto-detect function later using pkg-config. After we get Cons to build CinePaint, we can look into Cons code clean-up, which is needed for readability and extendability.

Love you guys!

Robin