What's Next for CinePaint CMS?

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?

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

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

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

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!