CinePaint

CinePaint Status and Mac OS X

2009-06-16T23:30:00.000-07:00

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

2008-12-11T00:02:00.000-08:00

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

2008-12-04T23:38:00.000-08:00

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

2008-12-04T00:58:00.000-08:00

<< 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

2008-12-03T10:53:00.000-08:00

<< 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

2008-12-02T10:27:00.000-08:00

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

What's Next for CinePaint CMS?

2008-11-30T21:58:00.000-08:00

Joel Cornuz posted a note on his Linux Photography blog about CinePaint CMS.

Image courtesy U.S. Air Force

I love that Joel wants a call to action. Unfortunately, a couple of Joel's assumptions aren't quite right.

> color management will be disabled in Cinepaint.

That CMS is being disabled in CinePaint in special cases is true, but that's not to suggest it's being disabled generally. You can always compile it from source.

I made a decision to scale back on the ambition of what we try to get into the next Debian release, to not commit to getting third-party packages included in this go. It's a Debian decision, not a CMS decision.

> it would be cool to have someone willing to help and support Oyranos in Debian

Nobody is saying I can't get a Debian maintainer to help. What we lack is a volunteer to prep 3rd-party libs for Debian.

> Kai-Uwe Behrmann decided to leave the project.

Kai-Uwe is continuing to be supportive off-list. As CMS questions arise, I'm forwarding those emails to him. His latest notes, that I posted here on Friday, are certainly helpful.

> a chance to see Kai-Uwe back to the project (yeah!)

Kai-Uwe will come back when he's ready.

Kai-Uwe has been active in CinePaint for five years. That's longer than anyone should expect from a volunteer. People get burned out or have other things they need to do in their lives. Kai-Uwe's dedication should not be tested with a plea he toil tirelessly another five years. We need to be thankful for what he's already done.

Someone else needs to step up.

An issue we face going forward is CMS was always Kai-Uwe's realm. We need documentation of how CMS works now in CinePaint, with notes what it should do in the future. Beyond that simple task, someone will need to lead CinePaint CMS, to work with our users, me, Kai-Uwe and Debian.

Who will step up?

Love you guys,

Robin

Scan 35mm Film at 8 Bits or 16 Bits?

2008-11-29T08:11:00.001-08:00

A user asks, "For scanning 35mm film, it's better to use 48-bit instead of 24-bit, to use CinePaint rather than GIMP, right?"

Speaking generally, more bits is better when working toward high quality pro output. Where the input is 35mm film, a good scanner will extract 12 bits of information from the image at 2k. A high-end scanner (very expensive) may go deeper and justify scanning at 4k+.

If you're outputting to film or gallery-quality prints, you care about 16-bit. If you're outputting a JPEG for your website, you might prefer 16-bit just to have some extra headroom, but 8-bit will do fine except in special cases (e.g., B&W photography).

If you scan at 8 bits per channel, you can use whatever edit tool you like. Everything supports 8-bit. If you scan at 16 bits per channel you need a tool that can open that format. Some 8-bit apps can open a 16-bit TIFF, only to crush it into 8-bit. You have to use CinePaint or some other 16-bit editing app if you need a 16-bit workflow.

Is a 16-bit pro workflow necessary for your purposes or is 8-bit good enough? Is your scanner good enough to support a 16-bit workflow? Can you see any difference when you output back to film? These are questions you need to research yourself. You'll have to test it to see.

Let us know what you find...

Love you guys!

Oyranos CinePaint CMS Notes

2008-11-28T21:25:00.000-08:00

Kai-Uwe's notes how to use Oyranos with CinePaint in response to QA report from Fabien:

See oyranos-monitor:

http://www.oyranos.org/wiki/index.php?title=Oyranos/Device_Profiles

You can use this command line tool for setting up your Argyll or other monitor profiles. CinePaint will use a previously set profile automatically. CinePaint must therefore link against Oyranos and Oyranos must be switched on in the colour management tab in the preferences dialog.

Oyranos-config-fltk does not yet handle monitors.

Fabien's QA notes from his installation of CinePaint CMS:

1. Argyll was installed from source and was not detected by Cinepaint configure.

2. After installing Oyranos, the choice list of icc profiles worked while using the "assign" and "convert with" icc profile functions.

3. How do I tell Oyranos to use the calibration icc profile of my LCD screen (which I made with Argyll) for displaying images?

4. What is stranger is that disabling Oyranos in Cinepaint, and configure the profiles the older way does not solve the problem.

CinePaint for Windows Dev Notes

2008-11-26T02:08:00.001-08:00

The Windows port of CinePaint was removed because it was too much work to support. These notes are for the benefit of those working on bringing it back.

One of our Windows problems was VC++ project files change with every Microsoft compiler revision (VCPP6, 7, 8...) and are incompatible. It becomes backbreaking to keep all those project files in sync so open source developers on different versions of VC++ can work together.

Instead of proprietary project files we'll be using CMake (or Scons or cons) to create portable build files that won't become a maintenance nightmare. We're not using autotools because that's not a good choice for Windows.

1. Install tools on Windows:

VC++
http://www.cmake.org/cmake/resources/software.html
http://www.chiark.greenend.org.uk/~sgtatham/putty/
http://www.tortoisecvs.org/
http://unxutils.sourceforge.net/
http://gnuwin32.sourceforge.net/packages/wget.htm

2. Modify Mac OS X library download bash script (in CVS) to be a Windows batch file called cinepaint.wget.libs.bat.

3. Run batch file to download and unpack 3rd-party libs.

4. Create CMake files as needed to build libs.

5. Download CinePaint from CVS. CMake files already exist to build it.

Love you guys,

Robin

Copenhagen Presentation Slides and Photos

2008-11-02T20:11:00.000-08:00

BEVERLY HILLS, CA (cinepaint.blogspot.com) 11/02/2008 – Gabrielle and I had a fantastic trip to Copenhagen to speak October 3rd and 4th at Open Source Days. For slides and photos follow links at www.linuxmovies.org. Gabrielle and I presented “Tux with Shades” about Linux in the film industry (it’s everywhere) and on the second day I presented “CinePaint Deep Paint”.

Some interesting points were revealed during the CinePaint session discussion. I heard the typical request that the CinePaint team rejoin GIMP. Of course, “rejoining” sounds crazy since we never belonged to GIMP and never had any interest in their mission. CinePaint is a tool for deep paint of image sequences. GIMP is a paint and photo-retouching program. Krita, another paint/retouching program, shares a more similar mission. Maybe Krita should “rejoin” GIMP? Just kidding.

So why did a GIMP user in a CinePaint session ask me to work on GIMP instead? Certainly the GIMP hackers don’t want me. Had an interesting answer. He’s frustrated by the delays in GIMP’s implementation of 32-bit deep paint. GEGL was announced as vaporware by GIMP in 2000. GEGL was their rationalization for moving away from Film Gimp (now CinePaint) instead of making that GIMP 2.0. Years later, I discovered forgotten Film Gimp, which had never been released, and made it available on SourceForge to anyone who wanted it. A closed source program would have been permanently orphaned, but not CinePaint. Isn’t open source great?

Outside the session, another GIMP user offered a different rationale why I should abandon CinePaint in favor of GIMP. He said that GEGL is finally nearing usefulness, that CinePaint will no longer matter after GIMP supports 32-bit. The problem with that logic is that Krita already supports 32-bit. If deep paint is all that matters, everyone should abandon GIMP for CinePaint or Krita! Just kidding. People using or working on open source choose whatever interests them most.

So, since CinePaint isn’t “rejoining” GIMP or Krita, what are we doing? Why does it take so long to make a new release?

In Copenhagen at Open Source Days I met Debian packager Jonas Smedegaard. Jonas is already overloaded with Debian packages to maintain and gamely volunteered to take on CinePaint, too.

Michel Lesoinne has been working on creating a CMake build system for CinePaint and that’s now mostly working. One of the things I want in the 0.25.0 version release is CMake support. That should be especially helpful for the Mac build, where autoconf never seems to do the same thing twice. The Mac build is much more involved because we build every dependency from scratch and use GTK+OSX instead of GTK2 (the new default in 0.25.0 CinePaint for Linux is GTK2, not GTK1). CinePaint runs on Mac natively. No X11. No Fink.

Kai-Uwe Behrmann has been fantastic about updating our autoconf system, but he’s the only person who understands it. Having an alternative build system gives us choices, avoids bringing the whole project to a stop while debugging an autoconf problem. Problems there can be very time-consuming because autoconf outputs intermediate make files, doesn’t build directly.

More build systems are coming… H. S. Teoh is providing a build system based on Python SCons. Teoh is also a Debian packager and helping there.

Official Fedora packager Nicolas Chauvet is starting to test 0.25.0. His first question...do I use autoconf or CMake? Good question.

Henne Vogelsang at OpenSUSE is advising me on their packaging requirements. We need someone to volunteer to master using the OBS build farm. That will test building CinePaint from rpm and deb and put CinePaint on the road to being an official OpenSUSE package. When we have that going, OpenSUSE will recruit an official packager.

Alexis Ballier at Gentoo is working on 0.25.0, too.

Professional photographer Paul Indigo is testing 0.25.0 on Ubuntu. Paul, a non-programmer, has been testing my new CVS build scripts available on the CinePaint download page. By running a bash script, any user can download and build CinePaint from CVS. No programmer knowledge required. I think this is a better way to test than with release candidate tarballs that rapidly become outdated as pre-release bugs are fixed. All a user has to do is cvs update, build changes, then start testing the fixes.

Anyone who wants to help with CinePaint can contact me at robin.rowe at cinepaint.org.

Love you guys!

Preparations for 0.25.0 Release

2008-10-18T23:27:00.000-07:00

CinePaint 0.25.0 builds in CVS. Would like to release this week. We'll see.

The new version compiles with GTK2 as default. Several people are helping to get CinePaint ready for Debian. When GTK1 was dropped by Debian, that dropped the CinePaint deb, too. Since Ubuntu is based on Debian, CinePaint fell out there too. FYI, I'm building CinePaint on Xubuntu as my current distro.

Kai-Uwe has done a great job adding GTK2 support and revising the autotools files. Work on the FLTK port of CinePaint hasn't stopped, but is slow. I work on it when I have free time, which isn't often. I need to find a way to fund my time in CinePaint.

I overhauled the Download instructions at www.cinepaint.org. Lots of new info there on how to get, build, distribute and debug CinePaint. To help several new people who joined the project recently, I've written bash scripts to automate build tasks.

Where's the Latest Version?

2008-10-09T14:45:00.000-07:00

<< It's difficult to find out which is the latest release and where to download. Please put a link on the main site to the actual version and update the Sourceforge page. >>

We're working on it. It's harder than it seems because Linux package maintainers are retiring, both from CinePaint specifically and also in general from open source. The packaging effort is significant and getting harder to do with volunteers.

It takes a whole team of people to make all the platforms and distros work. We've been without a Debian packager, but it looks like help is on the way. A Debian packager I met at Open Source Days in Copenhagen last week says he'll help.

Robin

New IOL plug-in

2008-09-12T09:57:00.000-07:00

FYI. A new IOL plug-in from Stephen Geary. Available as a patch in the CinePaint SF project. Not in the CinePaint release, yet.

From: Stephen Geary
To: Robin Rowe

Robin,

I emailed quite some time ago about developing IOL. I've now got some code
for anyone who wants to have a look.

Basically I've taken IOL and extended it quite a bit. Hopefully the
plug-in is faster, although direct comparisons with the original are hard, as the new version simply does things the old one could not.

There is also a small application to build an SCM (Script-Fu) wrapper for
IOL scripts, including menu entry and parameter passing.

I've attached a Gzip'd Tar file with sources and examples.

The main features that the new IOL ( IOL7 ) now supports are :

1.) Parameters - the scripts can now accept parameters e.g. from script-fu via the plug-in

2.) Better support for HSV, HSL and a poor-man's CIE-LABtransforms

3.) Improved (?) internals for hopefully faster operations

4.) Initialization, looping and multiple pass scripts.

5.) Instructions to automate and speed up linear transforms.

6.) Support for 5 precision types ( U8, U16, FLOAT, BFP and FLOAT16).

Anyhow, you can see if you can (a) get it compiled ( only tried on my own
Linux system so far ) and (b) find it useful.

Feedback welcome.

Debian Maintainer Needed

2008-09-12T09:46:00.000-07:00

> Perhaps you already know that cinepaint has been removed from ubuntu
> repositories. Upgrading from previous ubuntu version to current one
> kicked out cinepaint. What ever the reason for that is I guess it is
> against your interests. So I just wanted to make sure that you are
> informed. Hopefully we see cinepaint again in ubuntu 8.10 (october
> release).

Thank you for your note.

I don't know who, if anyone, is our Ubuntu maintainer. It could be the Ubuntu package is based on Debian.

Our Debian maintainer retired, which knocked us out of the latest Debian because the CinePaint package wasn't updated. We had a replacement Debian maintainer in training, but then he quit because he couldn't sustain the effort. There's no technical obstacle, just the usual maintainer effort required.

Until someone capable steps up to donate his time to be our Debian maintainer, it will continue to be a problem.

Robin

MacIntel CinePaint 0.23 released

2008-04-06T00:18:00.000-07:00

MacIntel CinePaint 0.23 released. This is a native Aqua version based on GTK+OSX, not X11, not GTK2. Our first release as a Mac DMG disk image. Easy drag-n-drop installation or run as is, where is. A vast improvement in CinePaint Mac packaging, based on a makefile by Remko Tronçon. MacIntel build by Tom Huffman.

Fedora RPM Released

Sudirikku Mohanjith created a bleeding edge Fedora CinePaint rpm that I released on SourceForge. This is newer than official Fedora CinePaint package.

CinePaint at NAB

SpectSoft is hosting the "All Things Linux" meeting on Wednesday, April 16th, at NAB.

CinePaint HDR Article

Creation of HDR Images in CinePaint (also in German) article by Hartmut Sbosny.

Google Adsense

Added Google AdSense advertising to www.CinePaint.org per suggestion by Danut Haiduc.

Linux Format Article and GIMP Reaction

I'm on the April cover of Linux Format magazine UK, interview about the CinePaint project.

Bizarrely, here's a troll on the Freedesktop CREATE list by the GIMP clique in reaction to my Linux Format interview. It's been six years since I noticed the forgotten Film Gimp code branch in GIMP CVS and released it myself. They're still mad at me. They're still posting hate mail.

Freshmeat and SourceForge News Updated

Updated our outdated Freshmeat and SF News pages after Rob Lingelbach noticed those were years out of date.

Robin Rowe Interview in LinuxFormat

2008-03-11T19:33:00.000-07:00

I'm the April cover of LinuxFormat. Haven't read the article, yet. Hope it's good.

Administrative...

Paypal donations can now be accepted. New mailing list CinePaint-cvs created to track source code changes. Mac CinePaint GTK2 screenshot added to home page.

New to the Team...

Héctor Tranche Cerezo joined as Mac QA tester. Hwei Sheng Teoh joined to create an SCons build system.

Mac Progress...

Tom Huffman, Rob Lingelbach, and Eric Robinson succeed in building CinePaint GTK1 Mac OS X, still packaging and testing. I succeeded in building Mac CinePaint GTK2 aqua, but OS X native GTK2 still has broken buttons and screen refresh issues, not quite usable.

CinePaint not at LugRadio...

CinePaint invited to exhibit at LugRadio Live USA taking place at The Metreon in San Francisco on April 12th and 13th, but we have nobody available

Open CinePaint Volunteer Positions

2008-02-27T01:13:00.000-08:00

CinePaint Embedded Perl Integrator

CinePaint is popular advanced image editing software used by pro photographers and studio visual effects artists.

Are you interested in learning how to embed Perl in a GUI app? A great project for someone who wants to play with Perl and graphics. This project is to port the Perl plug-in from GIMP to CinePaint. Although superficially similar, CinePaint has a more powerful graphics engine that enables it to handle high fidelity image files (such as OpenEXR files output from Blender). GIMP plug-ins usually port easily to CinePaint because the API is similar. Minor C coding (switch/case) is needed to handle interfacing 16-bit and 32-bit color channels. An easy Perl embedding project that doesn't present a high bar. Some knowledge or interest in learning C, Perl, and autotools needed.

CinePaint Mac GTK+ Port Developer

Are you interested in having Linux GTK+ GUI code build natively on Mac OS X without X11? CinePaint has a native Mac port of GTK+ that's made a lot of progress. It works well enough to support simple apps, but not CinePaint yet. Our Mac developer resigned to join Apple. A great project for someone who wants to play with xcode and create ports of popular Linux apps on Mac OS X. Knowledge or desire to master Mac-native GUI API necessary.

CinePaint Macintosh Package Maintainer

CinePaint is popular advanced image editing software used by pro photographers and studio visual effects artists. Are you interested in learning how to build UNIX-based code on Mac OS X? A great project for someone who wants to play with xcode and master the basics of package management on Mac OS X.

FOSDEM Slides and Other News

2008-02-26T00:07:00.000-08:00

Robin Rowe and Gabrielle Pantera spoke to an audience of 500 open source users at FOSDEM in Brussels on February 23rd, 2008 [article] [slides].

Aedan Kelly has Debian CinePaint GTK2 packages available for testing.

Sudirikku Mohanjith is working on 'make rpm' amd other RPM packaging.

CinePaint listed at TIG Colorist.

CinePaint home page and screenshots pages updated, links and about pages added.

CinePaint and Debian

2008-02-14T16:32:00.000-08:00

An update on our Debian situation.

- CinePaint removed from Debian testing because Debian has dropped GTK1.

- Thanks to Kai-Uwe Behrmann, CinePaint supports GTK2 now.

- CinePaint's Debian maintainer retired. Nobody to upload GTK2 CinePaint.

- Thanasis Kinias, who's posted CinePaint bug reports since 2006, has objected to Debian about CinePaint being removed.

http://bugs.debian.org/437837#25
http://bugs.debian.org/437837#34

- Ongoing discussion at debian-multimedia@lists.debian.org

- Aedan Kelly may become the new maintainer. He's a maintainer for Sidux, a Debian-derived distro (http://sidux.com)

- Trying to find out what we need to do next.

What Is Libunistd?

2008-02-05T22:16:00.000-08:00

Libunistd is a very thin POSIX wrapper created by Robin Rowe that enables building typical Linux code on Windows with VC++. Using libunistd, many Linux terminal-based apps will build on Windows as-is or with only minor changes.

Supported POSIX Calls...

Libunistd supports open/read/write/close, dlopen, opendir, gettimeofday, and the typical BSD socket calls accept/bind/connect/listen/select/socket. It also allows iostream.h and fstream.h to substitute for their non-dot-h counterparts in VC++.

Unsupported POSIX Calls...

The most notable omission is fork. Portable programs can be revised to handle POSIX threads (pthread) instead. A Windows pthreads port is available from Red Hat or there's a chopped down lite version I created in CinePaint CVS. Also missing is fancy signal handling. And, ioctls are obviously not portable.

How to Use...

To use libunistd simply #include <unistd.h> in your code and set your Windows build path to find it. You should not need any #ifdef WIN32 code in your app. The whole point of libunistd is to eliminate that junk.

You'll want to statically link to the (tiny) libunistd library. That has implementations of opendir and gettimeofday. You'll also need to link to Windows' Winsock library and possibly its Common Controls library. If you're running sockets from a Windows command-line app, there's a magic start-up function called StartWinsock() you'll need to call.

How It Works...

Many POSIX calls are available in Windows to support its implementation of BSD sockets, but have non-standard header names. There are many deliberately empty POSIX headers in libunistd so that Windows won't complain about missing Linux POSIX headers. Most of Windows POSIX implementation is in <winsock.h>, but you don't need to know that. Just include unistd.h and it will straighten out the Windows mess. Including unistd.h on Linux does no harm. That this file is standard on nix systems but not present on Windows is the trick to making code portable.

Alternatives...

Note that libunistd is deliberately a very thin implementation covering only the most basic POSIX calls that everyone uses. If you want a full-featured POSIX implementation and don't care how cumbersome it is, you're looking for Cygwin. If you're looking for a thin implementation of nix shell tools (ls, diff, du...) then you want CoreUtils for Windows, not Cygwin. With CoreUtils you can handle patching and other nix tasks in Windows using the standard nix command-line tools. By the way, if you're looking for a nice free Windows Perl you want PxPerl. A nice free Windows text editor that handles unix-style line feeds is Notepad++.

Cleaning up an image in 16-bit mode

2008-02-03T22:32:00.000-08:00

Paul LeBlanc wrote to let me know about new forum he's working on that includes CinePaint:

http://www.smffree.com/forums/linuxgraphicsusers/index.php

There's a great little HOW-TO there for cleaning up an image in 16-bit mode.

New Debian CinePaint Maintainer

2008-02-03T22:15:00.000-08:00

CinePaint needs a new Debian maintainer. Andrew Lau, who's been the Debian CinePaint maintainer for years, has moved on to other projects. CinePaint has been removed from Debian testing because Debian is dropping GTK1 support. Kai-Uwe Behrmann's GTK2 CinePaint needs to be packaged (configure --enable-gtk ) for Debian. Read the Debian CinePaint Discussion.

Do you want to be the new Debian CinePaint maintainer?

CinePaint Interviews

2008-02-01T21:29:00.000-08:00

In this interview published today in the Linux Gazette, I talk about the upcoming FOSDEM conference, open source, Linux in Hollywood, and CinePaint.

Hollywood, Linux, and CinePaint at FOSDEM 2008

In this interview with Joel Cornuz at Linux Photography, Kai-Uwe Behrmann talks about photography, CinePaint and Kai-Uwe's views on CinePaint's future.

Linux Photography Interviews Kai-Uwe Behrmann

In this video interview with Rolf Steinort at Meet the Gimp, Joel Cornuz explains why he uses CinePaint, why 8 bits isn't enough.

Meet the Gimp Episode 028: Are 8 Bits Enough?

And, that's my cover story in the February issue of Linux Journal, about the making of Paramount's THE SPIDERWICK CHRONICLES. On newsstands everywhere.

CinePaint Glasgow on Linux 64Studio

2008-01-31T00:35:00.000-08:00

In this screenshot, Glasgow compiled from CVS is running on my desktop on the Linux 64Studio distro. Glasgow is still too incomplete to interest users, but this screenshot shows development progress. Glasgow is a rewrite of CinePaint based on FLTK, not GTK.

CinePaint Glasgow now builds on Linux using Cmake, thanks to a patch from Michel Lesoinne. Michel is from Belgium and now lives in Colorado where he does consulting in Computational Aeroelasticity. Michel modified the Glasgow blur plugin and is working on half 16-bit float support and on color scaling for a better white balance plugin.

I took care of some portability issues so Glasgow still builds with VC++ on Windows. The code uses opendir() and dlopen(), rather than the Windows FindFirst() and LoadLibrary() calls. This is handled transparently by my POSIX libunistd thin wrapper library that makes Windows file system and socket calls POSIX compatible. The policy in all CinePaint code is to use the standard Linux POSIX calls, to avoid #ifdef WIN32 code blocks in application code.

Website and CVS updates

2007-11-11T20:16:00.000-08:00

The CinePaint website has been updated. I added some screenshots to the front page and organized it a little better. Because of defacing by spammers, our Wiki had become pretty useless. I'm sure this is a problem that could be fixed with enough effort, but since I'm the one who writes most of our docs anyway I brought the Wiki back into static pages using wget. The Wiki is gone. Maybe it will be back later. Rather than put effort into the Wiki, I want to blog here more. Anybody who wants to write docs, contact me. We'll figure out a way to get your docs up on the site without the Wiki. I also updated the software list and home page at www.linuxmovies.org.

I can't remember the last time I took a weekend off. This weekend wasn't supposed to be off for me either, but instead of working as planned I got some sleep and puttered around. Part of my puttering was playing with CinePaint. I'd hardly thought about CinePaint since the Southern California Linux Expo (SCALE) back in February 2007. CinePaint had a booth at that event. I got some great feedback and ideas for going forward there. But, code doesn't write itself. I've been busy with life as a journalist and screenwriter in Hollywood.

I've been interested in playing with the Mac GTK-OSX version of CinePaint. This is a Mac Aqua-native version of CinePaint that was getting close to being usable when Andy Prock stepped away to join Apple. I haven't touched the Mac version of CinePaint in ages. As a first step toward taking a look at that, I created a README.mac.txt file that I commited to CVS.

Cinebrush is another FLTK-based paint program that's an interesting base for a version of CinePaint. Cinebrush is derived from Antipaint, a Linux clone of MS Paint. I've made some changes and have built it on WinXP. The nice thing about Cinebrush is it's less than 80 files. The issue with Glasgow, of course, is that there's a lot of code there and almost no documentation from the work done at the university.

Cinebrush is buggy, but easy to trace through in the debugger. The only image type Cinebrush can open currently is BMP. JPEG won't load at all, and PNG images look messed up. Rather than try to fix that, I want to eliminate that image loader code and bring over my img_img loader plug-ins, especially the brand new DPX loader I wrote from scratch. I made some Cinebrush changes this weekend to simplify the file selector and fix bugs. My next task may be to redesign the window layout to look like CinePaint and bring over the toolbar from Glasgow.

A bit of housekeeping, I enabled automatic notification of commits so I'll get emails whenever something is updated in CVS:

http://sourceforge.net/docs/E04/

1. Checkout a copy of the CVSROOT module

2. Modify the 'loginfo' file, adding this line:

DEFAULT /cvsroot/sitedocs/CVSROOT/cvstools/syncmail %{sv} robinrowe@users.sourceforge.net

3. Commit loginfo

Software Transitions

2007-01-12T11:46:00.000-08:00

I realize the extreme difficulty it is for a small band of volunteers to get a project of this magnitude into a highly polished form.

That's true, but every project of any size dealing with a legacy architecture that's a decade old has problems going forward. It's not like Microsoft lacks for resources, yet they have had many problems and delays moving from XP to Vista. Apple just about lost it going from OS 9 to OS X. If you want a big well-funded open source example, Mozilla, almost disappeared during their transition from legacy Netscape code.

Every project has a hard time coping with end-of-life legacy code and major software transitions.

CinePaint at SCALE on Feb 10-11th

2007-01-11T20:10:00.000-08:00

February 10-11, 2007.
Exhibits 10:15am to 5:30pm. Cost $10.
Conference cost is $60, but see below for half-price tickets.

SCALE

CinePaint and LinuxMovies.org will have a booth at the Fifth Annual Southern California Linux Expo. Come by and see me and other guests. I'll be answering questions about CinePaint, Glasgow and Linux in the motion picture industry.

Booth volunteers wanted. If you'd like to help us for a few hours on the show floor let me know!

Get half price conference tickets! Email me for a special code to get into the conference for half price. When you write me please put 'CinePaint at SCALE' in the subject so I can't miss your email. I get a lot of email!

CinePaint vs. GIMP

2007-01-11T14:14:00.000-08:00

There's been some discussion recently comparing CinePaint and GIMP/GEGL. I tend to avoid that topic because it's often old ground not worth repeating, but here are a few technical comments that could be helpful.

Well, since GIMP is still limited to only 8-bit images, I would claim that any improvements to GIMP over the years are essentially meaningless...unless one is interested in designing exclusively for the web.

That's what I think, too. The point is that pro users demand higher image fidelity (16-bit and 32-bit channels) and such deep paint capability is hard to add to software later.

The problem is that GEGL was almost dead for a long time, and the code is still a good long way away from making it into GIMP.

GEGL design leadership and their code architecture have changed many times over the years. In 2000 it was DAGs, there was a never-completed compiler called Gil, it took a turn toward the Java Image Library API (JIL), and now it's based on babl which is DAGs again. The GEGL image core is one thing, but how would any new deep paint GIMP core architecture graft into the legacy GIMP 8-bit GUI?

Building a flexible multiple-depth image core is hard and only the beginning. Even Photoshop still struggles with deep paint, that not all parts of that program can deal with their new deep paint core. Ordinary users won't care whether the underlying engine is DAGs, tiles, channels, scanlines, or whatever. The important question is how will GEGL-GIMP integration overcome the same challenges that Film Gimp overcame in 1999 in adapting GIMP to handle deep paint?

From a C coding standpoint (what GIMP uses), everywhere GIMP code touches a channel will need a switch-case statement added and a different code path for each supported depth. That sounds just like Film Gimp, a design that GIMP has dismissed with many negative comments. Using C++ in Glasgow means we can use virtual classes instead of switch-case. Will GIMP use switch-case just like Film Gimp? When will GIMP start work on a deep paint GUI?

Where could I start in comparing Glasgow and GEGL code architectures?

CinePaint Glasgow img_img code:

ImgChannelNames.h
img_img main.cpp

GIMP GEGL code:

gegl.h
hello-world.c

Being dependent on volunteer developers, Open Source projects tend to be less capable than commercial endeavors, but the fact that Open Source has produced what it has already, namely Cinepaint, LittleCMS, Image/GraphicsMagick, and Netpbm, et al, is, in my opinion, nothing short of remarkable.

We're not less capable, just very short of resources. What open source does with less is amazing.

Robin
--
CinePaint.org

Glasgow Plans for Linux and Macintosh

2007-01-02T07:00:00.000-08:00

The POSIX-compatible Glasgow source code should build on Linux and Mac without trouble, but not before someone creates project build files for those platforms. The Glasgow code builds on Windows using a library called libunistd that provides POSIX Windows compatibity. Glasgow for WinXP is built using VC++ project files.

What Work is Needed to Build Glasgow on Linux Using autoconf?

The Glasgow autoconf files get outdated every time I make changes on the Windows side. For someone who is an expert in autoconf it may be no big deal, but that's not me. Linux build environment tools suck. Having wasted many frustrating hours on it in the past, don't expect me to help with autoconf. I don't have that kind of time to waste. If somebody else wants to take charge of supporting Glasgow autoconf, that's fine.

Choices in Linux build environments, in the order in which I would attempt:

cons
pmk
cmake
autoconf

I'm hoping someone else will pick up the Glasgow Linux build environment as a personal project, but I will get to it eventually if nobody else does. FYI, copies of cons and pmk sources exist in CinePaint CVS. No need to track down.

What About the Macintosh?

Who would like to create an Xcode project?

What's the Glasgow Code Layout?

The layout of Glasgow is that the app subdirectory builds to the executable. The other subdirectories build to static libs (that link with cinepaint app), except for subdirectories of the plug-ins folder that build to dynamic libs. The plug-ins link to the plug-ins lib, the utility lib, plus any relevant 3rd-party lib (e.g., TIFF). The 3rd party sources exist in CinePaint CVS. You don't need to download any external source code. To be neat, project files created should be in a separate subdirectory (like the VC++ project files in vcpp7 subdirectory).

What's Coming Next?

The img_img command-line tool with support for PPM, SGI, DPX and OpenEXR.

2006-12-31T20:25:00.000-08:00

CinePaint Glasgow is the next generation of CinePaint technology. CinePaint Film Gimp is a popular deep paint program used mainly in film industry for frame-by-frame image retouching (Cineon, DPX, OpenEXR, TIFF, JPEG, etc.).

This is a technology evaluation release for developers and others interested to see where Glasgow is at. Basically, it proves that Glasgow exists and encourages developers to participate more.

Changes in the 0.2 Release 2006.12.31

1. FIXED: Programs wouldn't launch due to issues with redist dll files
2. FIXED: Programs would crash on dual-head display due to bug in FLTK 1.1.7
3. Better diagnostic messages in CinePaint console window
4. Plug-ins moved to plug-ins subdirectory

Robin
--
CinePaint.org

2006-12-23T12:19:00.000-08:00

CinePaint Glasgow 0.1 Released!

What's Glasgow?

CinePaint Glasgow is the next generation of CinePaint technology. CinePaint Film Gimp is a popular deep paint program used mainly in film industry for frame-by-frame image retouching (Cineon, DPX, OpenEXR, TIFF, JPEG, etc.). Users of CinePaint should look at Glasgow, but continue to use Film Gimp until Glasgow is stable.

What's in the 0.1b Release?

This is a technology evaluation release for developers and others interested to see where Glasgow is at. Basically, it proves that Glasgow exists and encourages developers to participate more. Expect lots of breakage and incompleteness. CineCalc, Mickey and synch are somewhat usable. CineBrush will draw but not open files (broken). Glasgow will open JPEG and TIFF files but not paint (broken). Yage will paint but not open files (broken).

CineBrush - FLTK 8-bit image editor
CineCalc - FLTK RPN calculator
Glasgow - FLTK deep paint image editor
Mickey - FLTK hex editor
Synch - Command-line clock sync tool
Test_Images - Sample JPEG and TIFF images
Yage - FLTK gradient editor

Synch uses a website's clock to set your local PC clock. Usage: 'synch [some_web_site.com]'. The default website if none is specified is google.com. Executing synch will set your PC clock to the correct time. If you're using time servers already or you have atomic clocks you don't need this. Unlike the time service, synch uses port 80. Handy if you need to sync the clock on a machine that's behind a firewall or don't want to fiddle with configuring time servers.

Revision 0.1b fixes a problem that some users had with a missing msc dll.

Platforms

Compiled for Windows XP. The code is designed to be portable to Linux and Mac OS X (native Aqua, not X11), and should be available on those platforms soon.

Copyright and License

These programs are open source GPL, MPL, or BSD licensed, depending on the source. Each program's source code should contain full info. Software is provided as-is without warranty.

Sample images of military aircraft are from government archives and in the public domain. Image of Blue Lagoon in Iceland is copyright Robin Rowe and may be copied freely. Spot image by SoftImage artist Christian Deister is open source under the Tux license.

Download

Sourceforge.net

Source Code Available in CVS at SourceForge

:pserver:anonymous@cinepaint.cvs.sourceforge.net:/cvsroot/cinepaint

Contact

Please use the CinePaint mailing lists at SourceForge (follow link from
www.CinePaint.org).

Robin
-----
Robin Rowe, CinePaint Project Manager
Beverly Hills, California

2006-12-04T03:04:00.000-08:00

What is the big change in Glasgow?

Everything. Glasgow was created at the University of Glasgow with funding from the EU. Glasgow isn't based on GIMP.

Features

GUI uses FLTK, not GTK as in GIMP. Pretty, high performance GUI.
Renderfarm-compatible headless operation.
Flat raster buffer for simplicity/performance, not tiled like GIMP.
Support for 8-bit, 16-bit, 32-bit, 64-bit, and vector channels.
Mixed channels, e.g., 16-bit and 32-bit channels in the same image as needed for OpenEXR.
Uses libunistd so that unix code builds as-is on Windows. Single unix-style codebase without ifdefs. No visible WIN32 API calls.
New plug-in architecture. Plug-ins launch dll-style, not spawn like with GIMP.
Glasgow plug-ins will be compatible for use in After Effects.
C++ code throughout, except for exposed C plug-in API.
Much easier to understand, test and debug.

Tools

CinePaint Glasgow deep paint tool
img_img command line tool something like ImageMagick convert
hdr_display based on OpenEXR exrdisplay
open_image, a shared memory image server
CineCalc calculator
Flixi movie/DVD player based on Xine
3D modeling tools based on sharpconstruct and ewave
Webclock time synchronization
Mickey hex editor
Monica monitor calibration
Splat image editor based on antipaint
Yage gradient editor
Scanner tool based on flscan
Photo sorter based on flphoto
Video editing based on shotcut
Audio tools TBD

Everything except open_image has significant pieces implemented. Except for CinePaint Glasgow and img_img, there's a lot of experimental code not in CVS yet.

Will the initial release include a Windows version?

Yes, Windows is my primary development platform.

How stable is it?

It's very stable where I've tested, but not stable where I haven't. I'm crawling through img_img in the debugger now. I'm still making architecture changes there and porting plug-ins. The Glasgow plug-ins I'm working on now are PPM, SGI, DPX, and OpenEXR.

After releasing img_img I'll go back to crawling through CinePaint Glasgow in the debugger. CinePaint Glasgow will release with hacked Film Gimp plug-ins for JPEG, PNG and TIFF. Then there will be an integration so all the plug-ins are Glasgow.

Robin

2006-11-29T00:22:00.000-08:00

Progress on img_img

I'm debugging the CinePaint Glasgow img_img command-line tool after making some changes to the img_ppm parser classes. Nice stuff, but taking too long. Hope it saves me time working on img_sgi and img_dpx. I need to write some architecture docs and a source file manifest for img_img. I expect to finish img_ppm today.

CinePaint Press

SCALE Readies 'Non-Commercial' Open Source Conference
by Jacqueline Emigh at LinuxPlanet.com
November 20, 2006

Despite the proliferation of LinuxWorld and other commercial open source shows, several regional Linux organizations continue to hold their own conferences and expos. Right now, for example, a group of open sourcers in California is readying SCALE (Southern California Linux Expo) 5x, an event slated to take place in Los Angeles on February 9 to 11 of next year.

Non-profit exhibitors will include CACert, CinePaint, EFF, Fedora, Gentoo, Haiku, Inkscape, KDE, KnoppMyth, Linux Astronomy, Linux Terminal Server Project, NetBSD, OpenNMS, ReactOS, Ubuntu, Ulteo, and Wikimedia.

Cinepaint for Linux
by Alan Weller
23 November 2006

Cinepaint is a 32 bit capable photo editor for Linux. It is derived from The Gimp and uses the original GTK 1 library and therefore feels a bit snappier than the Gimp. On the version I have on Slackware it takes a long time to rescale an image therefore I do not use it at present. A new version called Glasgow is on the horizon. This will use the lightweight FLTK library and so should be efficient on resources.

Pictured Cinepaint in action with Christina Aguilera (lucky Cinepaint !).

Raster image editors: A comparative look at the GIMP and Krita
bu Nathan Willis at Linux.com
November 01, 2006

With the release of Krita 1.6, it seems like a good time to compare the two big raster image editors for Linux. Coming as they do from the divergent GTK+ and KDE programming camps, it can be hard to assess the differences between the GIMP and Krita without being swayed by politics and emotion.

Adding another wrinkle to the difficult task of a direct comparison are two readily available incarnations of the GIMP with additional features. CinePaint forked from the GIMP several stable releases ago, and supports high bit-depth images and color management. If you need to retouch high dynamic range photos, neither Krita 1.6 nor the GIMP 2.2 has the magic combo of 16-bit-per-channel color and dodge/burn tools, but CinePaint does.

Cheers,

Robin

2006-11-22T20:05:00.000-08:00

Thanksgiving and CinePaint

Happy Thanksgiving. I'm thankful to be making progress on CinePaint and life in general. I appreciate all the support everyone has given me.

I had a Compaq WinXP laptop hard drive crash this week and a Linux ftp server go down. All fixed now, but lost some time. By the way, if you're running Fedora vsftpd make sure it's set to chroot in /etc/vsftpd/vsftpd.conf.

Compaq laptops are sure sweet to replace a drive in. Two screws to pop a cover off the bottom, give the drive a tug, and it pops right out. Got a new Seagate 120gb drive at Circuit City for $120. Mounted the old laptop drive in a Linux server (using a 2.5 to 3.5 IDE adapter). Although the OEM 2-year-old Fujitsu drive wouldn't boot Windows XP anymore and made chirping noises, it was good enough to allow me to copy all the data off. That particular Linux box had SUSE 10, but it gave me so much grief figuring out how to install SAMBA that it was faster to reformat into Debian 3.1 and install SWAT. The new Seagate drive has 5-year warranty which is nice.

I'm testing the new img_img PPM plug-in, which I hope to complete tomorrow (Thanksgiving). I have some work to do on the SGI plug-in after that which seems almost done, then on to the DPX plug-in. After that I want to do some debugging on Glasgow itself and roll an alpha Windows release.

Cheers,

Robin
--
CinePaint.org

2006-11-19T17:29:00.000-08:00

CinePaint Glasgow Progress

Robin's Nov 19th update. I've brought the CinePaint blog online at Blogger and updated home page to point to it. I'm making progress on img_img. Fixed a linker bug that was messing up DLL calls to plug-ins.

Robin's Sept 23rd update. I wasn't able to do much the past month for open source. Too many interruptions with my life. Robin's Aug 11th update. Chris McKinley provided a patch for autotools so Glasgow builds on Linux again.

Robin's July 9th update. I took some time for myself and didn't work on CinePaint over the 4th holiday as I'd originally planned.

Robin's June 27th update. Below is for developers. No user-serviceable parts yet. Been working on img_img, the command-line component of Glasgow that's a little bit like GraphicsMagick 'convert'. Adding support for SGI and DPX files. It had only PPM support lately (now broken). OpenEXR and JPEG2000 (Jasper) were working in the distant past and will get added back later. Eventually all the file types now supported in CinePaint will get added in.

Changes to the types and quantity of img_img channels. Now number of channels is limited only by RAM and may be of mixed type. The mixed types are particularly important to support OpenEXR without crushing. OpenEXR may have Half, Float and U32 channels intermixed, but CinePaint Film Gimp is homogeneous to channels (all channels in a layer are either u8, u16, b16, f16, or f32 -- not mixed).
Channels in img_img have a color tag. RGB is considered a single color in nomenclature because the colors aren't in separate blocks that can be individually freed. The architecture will be able to copy (convert) from channel color RGB to planar R,G,B channels with a library call.

Here's what the types and colors are:


CHANNEL_TYPE(b16); //Binary 16-bit (HDR)
CHANNEL_TYPE(f16); //Float 16-bit (half)
CHANNEL_TYPE(f32); //Float 32-bit
CHANNEL_TYPE(f64); //Float 64-bit (double)
CHANNEL_TYPE(u8); //Unsigned 8-bit
CHANNEL_TYPE(u16);//Unsigned 16-bit
CHANNEL_TYPE(u32);//Unsigned 32-bit
CHANNEL_TYPE(u64);//Unsigned 64-bit
CHANNEL_TYPE(vec);//Vector data (not raster)

CHANNEL_COLOR(r); //Red
CHANNEL_COLOR(g); //Green
CHANNEL_COLOR(b); //Blue
CHANNEL_COLOR(m); //Mono
CHANNEL_COLOR(z); //Depth
CHANNEL_COLOR(rgb); //RGB interleave
CHANNEL_COLOR(rgba);//RGBA interleave
Here's the channel structure:
struct ImgChannel
{ DL_node node; // channel's node in channel list
 unsigned image; // image #, the first image is 0
 unsigned layer; // layer #, the first layer is 0
 ChannelType channel_type; // e.g., img_type_u8
 ChannelColor channel_color; // e.g., img_color_rgb
 unsigned x; // position in layer, e.g., 0
 unsigned y; // position in layer, e.g., 0
 unsigned width; // width in pixels, e.g., 720
 unsigned height; // height in pixels, e.g., 480
 unsigned bit_depth; // depth in bits, e.g., 8
 ByteData data; // raster or other image data
 StringData metadata;// text data about channel
};

An image object is a list of channels. The channel list is flat. There isn't an image or layer list in the image file container. The image # and layer # are simple attributes on the channel. The image # is for file formats that may contain more than one image.

CinePaint News
Aug 11, 2006
Version 0.21 Changes
Flipbook overhaul
HDR creation from 16-bit sources
Internationalisation
CMS improvements
GUI improvements

July 13, 2006

Kai-Uwe Behrmann reports that post-production company TV WERK GmbH in Munich, Germany, sponsored one week of development on CinePaint. TV WERK's Markus Baburske says, "CinePaint is one of the rare tools useful for the task desired." Kai-Uwe work was on stabilising the Flipbook and implementing shortcuts to streamline the workflow.

June 1, 2006

Adding SGI and DPX support to img_img command-line converter (currently PPM only)
Fixed bug that prevented core Glasgow plug-ins from loading
Rewriting AppRc system settings class to eliminate bugs and GIMP-like plug-in path complexity
Researching Extreme Wave 3D paint tool, trying to build on Windows
CVS ChangeLog

FLTK 1.1.7

May 29, 2006: FLTK updated in CinePaint CVS to be the latest stable version. Our copy in has different VC++ project files and directory layout, but is about the same as FLTK.org version.

CineCalc Rounding Bug

May 29, 2006: Fixed so numbers beyond five figures don't round off in display (34,332.25 was displaying as 34,332.3).

Recent Events

CinePaint at LILAX

Robin Rowe, Beverly Hills 2006.4.1

CinePaint project leader Robin Rowe presents at HREF="http://lilax.net/meetings.shtml">LILAX in Los Angeles.
CinePaint at NEXPO 2006

Robin Rowe, Beverly Hills 2006.3.20

CinePaint project leader Robin Rowe will be part of
an open source software panel at the Newspaper Association of
America NEXPO
conference in Chicago on April 2nd. [slides.pdf]
CinePaint at SCALE 2006

Robin Rowe, Beverly Hills 2006.2.14

Thanks to the generosity of SCALE,
CinePaint had its first booth at a tradeshow. At the conference
I spoke for a session
about Linux in the motion picture industry (#1 by far) and CinePaint
(#2 after Photoshop there) [slides.pdf].