Archive for the 'Graphics' Category

Die Hard 5: with kernels

It’s been a while since I last posted some opinionated crap. How could that possibly happen? :)

Last week Bitwig folks finally announced upcoming beta of Bitwig Studio, a new commercial DAW for Win, Mac and Linux. As it often happens, some folks in the community started speculating how this is going to affect existing free software and the community itself. After all, it’s not that we’ve got huge teams slaving away to make music production a breeze on Linux, eh?

Well, one thing I really liked in the LAU thread is that most folks who cared to comment didn’t express extreme views. I seriously hope that it’s a sign of the community becoming mature enough to treat things in a relaxed, no-fanatic way.

What I’ve been seeing on the desktop layer is that free/libre and commercial software can perfectly coexist without kicking each other in the nadgers and turning half the city to ruins. Just a few examples:

  • Bibble Pro (Corel AfterShot Pro since last week, btw) didn’t make any existing free software die. Instead we got darktable.
  • A month ago BrainDistrict announced PaintSupreme. Can you see Pinta folks crying in despair, because noone’s gonna use it again?
  • BrainDistrict has also been resurrecting MainActor, and yet commits to Kdenlive, PiTiVi, Novacut and OpenShot keep piling up.
  • Renoise didn’t kill any free software project, and they even added support for DSSI, a (currently outdated) free API for virtual instruments.
  • Mixbus folks have been contributing to upstream Ardour project for a couple of years now already, and aren’t they proprietary guys?
  • Loomer is busy porting their commercial synths and effects to LV2, the state of the art free API for virtual instruments and effects.
  • linuxDSP started with Linux support from ground up and has been supporting LV2 since day one.
  • ..and the list can go on.

The only fluctuation I can think of is the 8 years old story with Jorg Anders overreacting and abandoning NoteEdit after hearing about a, frankly speaking, fantom possibility of Finale port to Linux. And he started NtEd few years later anyway. That he doesn’t get much acknowledgment for NtEd either is a whole different story.

And even if you could recall all the epic OMG!Ubuntu threads about likewise phantom possibility of Photoshop port for Linux, you’d soon figure out that most people who expressed their interest weren’t going to use GIMP anyway. No love lost.

So if you think that some proprietary app suddenly available for Linux is going to do BLOOD NEEDLESS VIOLENCE GUTS OUTSIDE CITY TAKEN OVER DEAD BODIES ALL AROUND to your favourite free application, stop worrying. Fire up that free app and do something awesome with it. Work on your skills, become damn good at using free software, and then share what you know. This is how you become your own John McClane.

Zero tolerance

As LGW owner and primary contributor I’m supposed to be neutral to various projects and try to be at least in good relations with everyone. That, however, doesn’t mean that I should like bigotry.

I haven’t covered Oyranos and related apps in a while simply because I found it increasingly difficult to explain why anyone would need them in real life, except ICC Examin which is a nice ICC inspection software (fails to work on Intel GPU, but that’s another story). However, the more I observe the whole colord/oyranos situation, the less I wish to have anything to do with Oyranos. Here is why:

Colord developer on Oyranos:

I don’t think it’s likely we’re ever going to see any interoperability between the colord and Oyranos projects in the future. Not for any huge ideological reason, but just because the feature overlap of the two projects is too small. Colord is of very limited scope, is installed by default and tries to make things just work. Oyranos is a project of huge scope that wraps many other libraries and tries to be involved in every part of the color workflow. It’s kind-of orthogonal to what colord is trying to be, and that’s the main reason I chose to start a new project rather than trying to fix Oyranos.

Note the courteous tone.

And now Oyranos developer:

What counts today is a very different understanding about, what makes a good colour management system. The colord author has failed to meet many criteria and was so far not very cooperative to accept some very common demands from various people in the colour community…

Beside that I believe, Oyranos is from a architectural level much better designed, because it relies as good as possible on existing standards, which colord does not care about.

Here is a clue. Colord is catering to Linux users who want color management to just work and not be pain in the arse. Oyranos is trying to work on all possible platforms and support all kinds of workflows. Which is why colord is now becoming mainstream (recent Fedora and Ubuntu relases have it), while Oyranos can mostly be found in the upcoming new version of OpenSUSE. Hence the bitching.

This kind of childish behavior is precisely the reason I’m getting less and less involved with some projects lately.

Switching CMS and moving on

Last week we switched Libre Graphics World to a new CMS. Most important 301 redirects are in place, XML sitemap is coming, there’s still a bunch of work to do, but new material is already pouring in. Here is some of the latest stuff:

More is coming.

Forums and software directory will be merged later as least important parts of the project.

“Excuse me, sir/madam”

Nearly forgot how I love taking interviews, so started doing it more often than usual:

  • A talk to Thomas Krijnen on IFC based workflows, Blender and architecture
  • An interview with a LibreOffice GSoC student and her mentor on implementing support for Visio files
  • Short interview with folks from Argentina who customized MyPaint for their open movie project

Some more interviews, articles and tuts are coming :)

The endless GIMP name debate

— I’m sorry, son, there’s something we’ve got to tell ya.
— Er, mom? Dad? Granpa in hospital again?
— No, not as such. It’s about your name.
­— What about it?
— Well, the thing is… It’s not good. We’ve got to change it.
— What’s wrong with the name Boyo? I’ve been a Boyo 15 years of my life. I love it!
­— Apparently in Chinese it means few different things, not all of them nice.
— Exactly how not nice?
— I’m not sure you’re old enough to know.
— But old enough to have my name replaced because of what some people in China could think?
— It’s, you know, down to marketing.
— Er, WHAT? Are you up to selling me to China???!!!
— Sorry, son, the times are harsh.
— And what will my new name be, may I ask?
— I don’t really know. We had a family meeting, and no single person agreed with anybody else, so you don’t have any new name, but that’s all right, ’cause we are all just one big loving family, aren’t we? Aren’t we?

*sound of a falling body*

— Son?

*curtain falls*

On Cinepaint, GIMP and GEGL

The Cinepaint/GIMP crusade will probably never die. Sad but true. I keep reading the same bullshit over and over again, for years, so I thought I should probably write about it once and never get back to it again.

The legend runs, as an ill-informed Phoronix user recently suggested, as this: “Just think, its only been 11 years since the functionality was handed to them on a silver platter and they rejected it unanimously in favor of vapor ware. It has got to be one of the biggest boneheaded moves in software development.”

It has got to be one of the biggest boneheaded moves in software development indeed, except the author of the statement is out of touch with reality. Let’s go back in history.

Cinepaint is a new name of FilmGIMP, the project born out of “Hollywood” branch of GIMP which was started in 1997. The first commit by the joint username “People doing a 16 bpc version of gimp” (more on that later) was done on December 15, 1997, and the last commit was done on August 27, 2002. Got the dates?

Now move to GEGL’s commit log. It starts on January 2, 2000, with commit of the very same username, “People doing a 16 bpc version of gimp”. The last commit from that username in GEGL was done on December 22, 2003.

So the idea that the pro-Cinepaint folks are trying to sell is that GIMP developers refused FilmGIMP developed by R&H developers in favour of vaporware GEGL developed by the very same R&H developers. Amazing, isn’t it? That’s some unbeatable logic if I ever saw one.

And yes — “People doing a 16 bpc version of gimp” is the joint username of Jonathan Cohen, Calvin Williamson and Caroline Dahllöf, all of them being developers at the famous Rhythm and Hues company at the time.

If you really want to understand how the actual FilmGIMP/GEGL developers (not either project leads) felt around 2002 when the whole unpleasantness was unleashed, read Jonathan’s mail to gimp-developer from early December 2002. It also answers the “why projects did not converge” concern re Cinepaint/FilmGIMP and GIMP. Then compare it to what you thought you knew.

You can choose to believe, or you can choose to find out what things really are—it’s entirely up to you. Either way, don’t fall for politics. And it’s the best advice I can give you at this time in the morning :)

Graphics tablets configuration in GNOME

I was actually going to blog on Novacut, but thought better of it. I think there’s enough tension growing already :) Instead I’d like to draw your attention to planned graphic tablets configuration tool for GNOME 3. It needs some work to get included upstream.

There already is some design/UX work done by Jimmac, with some useful comments from Hylke Bons to take into consideration.

What’s more important, there already is real code by Peter Hutterer that basically lacks calibration part. So all it needs is someone (yes, jonnor, I’m looking at you) willing to take existing code and add few missing things.

Then we can all make artsy types much happier users of GNOME. Because you can’t possibly dive into matrix calculation and come out a happy (or sane) person :)

Screencasting

As far as I can tell, the best way to deal with inability to do good public presentations (yes, I do mean my darktable talk at last LGM) is to tame and reprogram it. For you it means a series of truly horrible screencasts with voiceovers :) The first one is out along with usual textual review to do some promo for Gpick — a real kick-ass color exploration tool for Linux and Windows.

And I think it’s time to have another look at RecordItNow in case it can unscrew screencasting on Linux just a little.

Why GIMP and Inkscape are not funded by Linux vendors

Martin wrote few days ago about why GIMP 2.8 is delayed. Apart from some annoying yet predictable mini-hatefests an interesting comment was provided by Alexander Hunziker:

One thing I wonder about is why none of the big Linux distributors steps forward and funds development. Both Gimp and also Inkscape I feel are very close to being useful also for professional designers, so just a handful of full-time developers could make a big difference. Surely, this would be an interesting market to enter into?

It’s a very valid question, and it is actually easy to answer. There are, in short, several reasons why it hasn’t happened yet.

1. Canonical already tried that back in 2004. The full story is here. TL;DR: money doesn’t magically solve everything.

2. The Linux vendors that have commercial interests (i.e. RedHat, Novell) make money on enterprise clients and governments, and their few attempts at non-enterprise desktop software (Banshee for Novell, GNOME Color Manager for RedHat) are rather personal hobbies of developers than paid projects. Entering a market means doing business with people. I’d love to see a business model around GIMP that would work for someone like RedHat.

The rest? Mandriva recently had a very instable finanical situation, followed by separation of the core team into a new project. As for Canonical, they still have problems making money and anyway they are now more focused on cloud computing which doesn’t have much place for heavy desktop apps such as GIMP and Inkscape. (As a matter of fact, three of the former active Inkscape developers work for Canonical.)

3. The teams themselves have diverse opinions on paid development. Inkscape committee is 3/4 (or 4/5?) dead against it. The GIMP team doesn’t seem to be sure: a year ago they didn’t mind, fairly recently they did mind (or so it seemed to me).

The way I see it, the future of these projects is in the hands of people who care about it so much that they are willing to work on it come hell or high water. So unless you can come up with a business model that doesn’t rely on donations, and the teams suddenly stop minding paid development, the state of affairs won’t change drastically.

Is it waving goodbye to GIMP and Inkscape? Not really. Relying on volunteers is what these projects have been doing for years, and despite the will of some people they are still around and about. A great many thanks for some of the new stuff (up to 50% in case of Inkscape) we see in the new releases of both of them goes to Google for its Google Summer of Code program.

Finally, can we get Linux vendors do at least something for the projects? Sure. They already do something actually: both RedHat and Novell are rather open about how their designers use free software: Mairin does Inkscape classes, and the whole Fedora design team uses both GIMP and Inkscape all around; Jimmac used almost complete free toolbox (GIMP, Inkscape, Blender, Fontforge) in Novell which he now does for RedHat, and now Andy Fitzsimon is in his place at Novell doing the same. It’s much less so in case of Canonical for some reason or another. Also, both RedHat (Fedora) and Novell used to publish short tutorials on using free design tools, both don’t do it much these days, so maybe they could give the initiative another go.

The important thing to understand here is that since we do eat our own dog food, we shouldn’t be shy about it. After all, not using Adobe products isn’t a mortal sin. If we don’t share excitement of using free tools, then who will?

What’s up with darktable

In case you’ve been living under a rock for last several days, darktable 0.8 is out with some important changes. There’s quite a bit of work done on the next version already, including blending modes + opacity for every darkroom mode (currently in blendops branch) and an on-canvas vignetting editor:

On-canvas vignetting editing

It’s the second darkroom mode that goes on-canvas, the first one being crop/rotation. The next one hopefully will be graduated filter.

In other words, darktable development continues in its best traditions: providing a working UI for a new feature first to get people something to use, then improving it at the next stage.