We are happy to receive another fanart image, this time from Carlos “Lobo” Zamora. He is also published a post describing the process of working on this image – worth to take a look!

Welcome to Issue #41, “Imagine the Possibilities”

In a world full of yet to be imagined possibilities, often the only thing stopping you is a bit of inspiration. This issue we bring you a wealth of just such possibilities to inspire and jump start your own artistic adventures.

So grab your copy today. Also be sure to check out our gallery of wonderful images submitted by very talented members of our community.

Table of Contents:

• Letting Cycles Do The Work
• Making Of Katie
• Making Of Red Fox
• Master Of Puppets
• Blender For Comic Illustrations
• Making Of a Trophy

And Lot More…

Reminder: Submissions for issue #43 due July 5^th,

Call for Content #43

It’s time again to start thinking about articles, tutorials and images for Issue # 43 of Blenderart Magazine.

The theme for this issue is “From Concept to Character”

Character design can be one of the most rewarding areas in 3d modeling. You get to choose the look and type of character you are creating. And most fun, non humanoid characters are always a possibility. From animals to normally inanimate objects, just about anything can be transformed into a fun character to model and possibly animate.

So in this issue we are looking for tutorials or “making of” articles on:

• Creating Concept Art
• Personal or Commercial Character projects
• Texturing
• Character accessories and environments (backgrounds)
• Sculpting
• Retopology

*warning: lack of submissions could result in an entire issue of fuzzy bunnies, puffy hearts and a galley filled with random images off my hard drive …. …… goes off to check number and variety of images on my hard drive …. just in case.

Articles

Send in your articles to sandra
Subject: “Article submission Issue # 43 [your article name]“

Gallery Images

As usual you can also submit your best renders based on the theme of the issue. The theme of this issue is “From Concept to Character”. Please note if the entry does not match with the theme it will not be published.

Send in your entries for gallery to gaurav
Subject: “Gallery submission Issue # 43″

Note: Image size should be of 1024x (width) at max.

Last date of submissions July 5, 2013.

Good luck!
Blenderart Team

For half a year now my Timex watch (yes, I'm one of those old fogeys who actually wears a watch) hasn't had a light. And it doesn't beep when I use the stopwatch. I don't care so much about the beep, but the light was handy.

I replaced the battery at some point, and apparently got something wrong when I put it back together. I've been meaning to go back in and figure out what I got wrong, but life intervened, so I've been putting up with it for way too long, until now.

I felt a bit better about having messed up when some web searching showed that many, many people have this exact same problem. Some of the web pages I found had succestions that got the beeper working again; but the light still didn't work.

Curiously, it worked fine with the watch disassembled: the watch's brains and battery are all in one self-contained module, and if you push the tiny button in the front, the light comes on. It's just that the big button in the front didn't push the tiny button on the watch module.

Maybe there was some tiny piece that went sproinging off to freedom the first time I opened the watch. No matter; if so, it's long gone now. But you know what? Several pieces of masking tape stacked up over the inner button worked fine -- and now my Indiglo light works again.

A few other tips for Timex fixers, some of which aren't obvious from the how-to sites:

• The "scratches" on my crystal -- so bad I'd been thinking it was time to buy a new watch -- were actually melamine (or some such material) that had rubbed off from the artists' table I use as a desk. It cleaned off nicely with alcohol.
• I used a needle to open the spring clip over the battery.
• Rotating the back cover 180° was probably what fixed the beeper.
• You may or may not need to reset the watch by shorting the two contacts as suggested on the label inside the watch. If you see an error code or the watch doesn't work right, try shorting the contacts.

From the creator of the GIF: “it’s pronounced JIF, not GIF.” Of course, I’ve known this all along. As with all debates, the important thing is that someone is wrong.

( читать по-русски | Russian translation )

It’s ten days passed by since the new version of Synfig Studio got officially released but I guess it’s never too late to announce it here. ^__^

This release includes the brand-new cairo rendering engine, as well as our improvements – simple plugins system and disabled keyframes. That’s it – the features developed during the work on Morevna Project Demo now officially included into Synfig and this is a significant milestone for us, of course.

Download Synfig Studio 0.64.0

And yes, Synfig isn’t crashing anymore when you try to disable keyframes. ~_^ The new version also includes the stickman template, available as a plugin called “Simple Skeleton”. That means the stickman is now a part of Synfig Studio and will be updated with its development. Though, we do not exclude possibility of publishing more alternative versions of stickman, but they will be provided as Synfig plugins from now.

Read the complete list of new features

Been quiet some time since my last blog about Krita, well, I had been a bit busy with college work. Nonetheless, with whatever time I had, and all the help from Boud, I have been able to import a particular feature from the Perspective Grid to the Perspective Assistant. A little background Perspective Grid The […]

It's becoming a tradition... 2 weeks after the release a bugfix update get made. Over 100 fixes!

In my post about Controlling a toy car with a Raspberry Pi, I skipped over one important detail: the battery. How do you power the RPi while it's driving around the room?

Most RPi sites warn that you shouldn't use the Pi with a power supply drawing less than an amp. I suspect that's overstated, and it probably doesn't draw more than half of that most of the time; but add the draw of two motors and we're talking a fairly beefy battery, not a couple of AAs or a 9V.

Luckily, as an R/C plane pilot, I have a fridge full of small 2- and 3-cell lithium-polymer batteries (and a li-po charger to go with them). The problem is: the Pi is rather picky about its input voltage. It wants 5V and nothing else. A 2-cell li-po is 7.4V. So I needed some sort of voltage regulator.

It's easy enough to get a simple 5V voltage regulator (pictured at right) -- 30c at Jameco, not much more locally. But they're apparently fairly inefficient, and need a heat sink for high current loads. So I decided to blow the big bucks ($15) for a 5V step-down power converter (left) that claims to be 94% efficient with no need for a heat sink.

Unlike most of Adafruit's products, this one comes with no tutorials and no hints as to pinouts, but after a little searching, I determined that the pins worked the same way as the cheap voltage regulators. With the red logo facing you, the left pin (your left) is input power from the battery; middle is ground (connect this to the battery's ground which is shared with the Pi's ground); the right pin is the regulated 5V output, which goes to pin 2 on the Pi's GPIO connector.

I was able to run both the RPi and the motor drive circuit off the same 7.4 volt 2-cell li-po battery (which almost certainly wouldn't work with 4 AAs, though it might work with 8). A 500 mAh battery seems to be plenty to drive the RPi and the car, though I don't know how long the battery life will be. I'll probably be using 610 mAh batteries for most of my testing, since I have a collection of them for the aerial combat planes.

Here's a wiring diagram made with Fritzing showing how to hook up the battery to power a RPi. If you're driving motors, you can run a line from the battery's + terminal (the left pin of the voltage regulator) as your motor voltage source, and use the right pin as your 5V logic source for whatever motor controller chip you're using.

Krita was the first painting application with an OpenGL accelerated canvas. We had that before Photoshop... Which also meant that the code was getting quite old fashioned. These days, life is supposed to be better. More flexible in any case. However, even though a 2D canvas is a simple thing, once you factor in rotation, zooming, panning and so on, the potential for bugs is quite big, and we've been fixing bugs for ages in the old code.

So I didn't want to throw that away, but have as clean and straightforward as possible a port from the old code to start with. The old code mostly looked like this (for painting the transparency checkers background):

KisCoordinatesConverter *converter = coordinatesConverter();

QTransform textureTransform;
QTransform modelTransform;
QRectF textureRect;
QRectF modelRect;

converter->getOpenGLCheckersInfo(&textureTransform, &modelTransform, &textureRect, &modelRect);

KisConfig cfg;
GLfloat checkSizeScale = KisOpenGLImageTextures::BACKGROUND_TEXTURE_CHECK_SIZE / static_cast(cfg.checkSize());

textureTransform *= QTransform::fromScale(checkSizeScale / KisOpenGLImageTextures::BACKGROUND_TEXTURE_SIZE,
                                            checkSizeScale / KisOpenGLImageTextures::BACKGROUND_TEXTURE_SIZE);

glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glViewport(0, 0, width(), height());
glOrtho(0, width(), height(), 0, NEAR_VAL, FAR_VAL);

glMatrixMode(GL_TEXTURE);
glLoadIdentity();
loadQTransform(textureTransform);

glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
loadQTransform(modelTransform);

glBindTexture(GL_TEXTURE_2D, m_d->openGLImageTextures->backgroundTexture());
glEnable(GL_TEXTURE_2D);

glBegin(GL_TRIANGLES);

glTexCoord2f(textureRect.left(), textureRect.bottom());
glVertex2f(modelRect.left(), modelRect.bottom());

glTexCoord2f(textureRect.left(), textureRect.top());
glVertex2f(modelRect.left(), modelRect.top());

glTexCoord2f(textureRect.right(), textureRect.bottom());
glVertex2f(modelRect.right(), modelRect.bottom());

glTexCoord2f(textureRect.left(), textureRect.top());
glVertex2f(modelRect.left(), modelRect.top());

glTexCoord2f(textureRect.right(), textureRect.top();
glVertex2f(modelRect.right(), modelRect.top());

glTexCoord2f(textureRect.right(), textureRect.bottom());
glVertex2f(modelRect.right(), modelRect.bottom());

glEnd();

glBindTexture(GL_TEXTURE_2D, 0);
glDisable(GL_TEXTURE_2D);

In other words, we set a projection, a transformation matrix for the texture and for the model/view and then start drawing the vertices. Pretty simple. I was rather surprised when I did not find any clear tutorial on converting code like this through google. I've read a bunch of modern opengl books and tutorials by now, and they pretty much all have the same order of explanation, the same things they emphasize and the same "advanced" topics. But I couldn't figure out how to draw my checkers or the tiles for my image. Yeah, I'm a linguist, not a mathematician, and I probable read these tutorials wrong or something.

In any case, after going through the Qt OpenGL examples, the tutorials on Wikibooks, the Red, Orange and Blue books, the Matt Gattis' notes on porting to WebGL and more confused questions and more confusing answers on Stack Overflow than I care to count, I finally got something that works, and is as straight a translation of the old code as possible.

Purists will cavil at my use of attribute arrays and glDrawArrays -- but the alternative, as far as I can tell, would be to redo all the matrix calculation and use matrices to place my tiles in the right location or to update and send new vertex buffer objects all the times. This works -- and in the future it might even be pretty.

So, for posterity, and because there might be others in the same spot as me (to wit, tasked with porting OpenGL 1.3 code to OpenGL ES 2.0 or OpenGL 3.1 without compatibility profile), here's a summary of my current code.

The vertex shader:

uniform mat4 modelViewProjection;
uniform mat4 textureMatrix;

attribute highp vec4 a_vertexPosition;
attribute mediump vec4 a_textureCoordinate;

varying vec4 v_textureCoordinate;

void main()
{
    gl_Position = modelViewProjection * a_vertexPosition;
    v_textureCoordinate = textureMatrix * a_textureCoordinate;
}

The fragment shader (needs to be expanded to handle color correction):

uniform sampler2D texture0;

varying mediump vec4 v_textureCoordinate;

void main() {
    gl_FragColor = texture2D(texture0, v_textureCoordinate.st);
}

And finally the code. The shader programs are all done using Qt's shader classes, and I don't show that code here -- it's in the calligra git repo anyway.

KisCoordinatesConverter *converter = coordinatesConverter();

QTransform textureTransform;
QTransform modelTransform;
QRectF textureRect;
QRectF modelRect;

converter->getOpenGLCheckersInfo(&textureTransform, &modelTransform, &textureRect, &modelRect);

// XXX: getting a config object every time we draw the checkers is bad for performance!
KisConfig cfg;
GLfloat checkSizeScale = KisOpenGLImageTextures::BACKGROUND_TEXTURE_CHECK_SIZE / static_cast(cfg.checkSize());

textureTransform *= QTransform::fromScale(checkSizeScale / KisOpenGLImageTextures::BACKGROUND_TEXTURE_SIZE,
                                            checkSizeScale / KisOpenGLImageTextures::BACKGROUND_TEXTURE_SIZE);

m_d->checkerShader->bind();

QMatrix4x4 projectionMatrix;
projectionMatrix.setToIdentity();
projectionMatrix.ortho(0, width(), height(), 0, NEAR_VAL, FAR_VAL);

// Set view/projection matrices
QMatrix4x4 modelMatrix(modelTransform);
modelMatrix.optimize();
modelMatrix = projectionMatrix * modelMatrix;
m_d->checkerShader->setUniformValue("modelViewProjection", modelMatrix);

QMatrix4x4 textureMatrix(textureTransform);
m_d->checkerShader->setUniformValue("textureMatrix", textureMatrix);

//Setup the geometry for rendering
QVector vertices;
vertices << QVector3D(modelRect.left(),  modelRect.bottom(), 0.f)
            << QVector3D(modelRect.left(),  modelRect.top(),    0.f)
            << QVector3D(modelRect.right(), modelRect.bottom(), 0.f)
            << QVector3D(modelRect.left(),  modelRect.top(), 0.f)
            << QVector3D(modelRect.right(), modelRect.top(), 0.f)
            << QVector3D(modelRect.right(), modelRect.bottom(),    0.f);

m_d->checkerShader->enableAttributeArray(PROGRAM_VERTEX_ATTRIBUTE);
m_d->checkerShader->setAttributeArray(PROGRAM_VERTEX_ATTRIBUTE, vertices.constData());

QVector texCoords;
texCoords << QVector2D(textureRect.left(), textureRect.bottom())
            << QVector2D(textureRect.left(), textureRect.top())
            << QVector2D(textureRect.right(), textureRect.bottom())
            << QVector2D(textureRect.left(), textureRect.top())
            << QVector2D(textureRect.right(), textureRect.top())
            << QVector2D(textureRect.right(), textureRect.bottom());

m_d->checkerShader->enableAttributeArray(PROGRAM_TEXCOORD_ATTRIBUTE);
m_d->checkerShader->setAttributeArray(PROGRAM_TEXCOORD_ATTRIBUTE, texCoords.constData());

    // render checkers
glActiveTexture(GL_TEXTURE0);
glBindTexture(GL_TEXTURE_2D, m_d->openGLImageTextures->checkerTexture());

glDrawArrays(GL_TRIANGLES, 0, 6);

glBindTexture(GL_TEXTURE_2D, 0);
m_d->checkerShader->release();

For Krita, there are quite a few todo's left:

• Restore the opengl outline cursor -- now we use the qpainter one
• Render onto a framebuffer object so this code can be integrated in Krita Sketch
• Update the image texture tiles in a thread
• Update the projection in a thread
• Restore the colormanagement using OCIO
• Check whether it runs on Windows, OSX (and Android)
• Maybe move the layer composition to OpenGL using the GPUImage shader code?

Especially the testing on Windows is interesting, since the old opengl canvas never worked on Windows.

Checking versions in Debian-based systems is a bit of a pain.

This happens to me a couple of times a month: for some reason I need to know what version of something I'm currently running -- often a library, like libgtk. aptitude show will tell you all about a package -- but only if you know its exact name. You can't do aptitude show libgtk or even aptitude show '*libgtk*' -- you have to know that the package name is libgtk2.0-0. Why is it libgtk2.0-0? I have no idea, and it makes no sense to me.

So I always have to do something like aptitude search libgtk | egrep '^i' to find out what packages I have installed that matches the name libgtk, find the package I want, then copy and paste that name after typing aptitude show.

But it turns out it's super easy in Python to query Debian packages using the Python apt package. In fact, this is all the code you need:

import sys
import apt

cache = apt.cache.Cache()

pat = sys.argv[1]

for pkgname in cache.keys():
    if pat in pkgname:
        pkg = cache[pkgname]
        instver = pkg.installed
        if instver:
            print pkg.name, instver.version

Then run aptver libgtk and you're all set.

In practice, I wanted nicer formatting, with columns that lined up, so the actual script is a little longer. I also added a -u flag to show uninstalled packages as well as installed ones. Amusingly, the code to format the columns took about twice as many lines as the code that does the actual work. There doesn't seem to be a standard way of formatting columns in Python, though there are lots of different implementations on the web. Now there's one more -- in my aptver on github.

Recently, I was asked by email to help with the status of my GSoC (2011!) project. So before I say anything about that, let me explain a few things about my current situation.

For those of you who didn't figure it out already from the lack of activity on this website (and the lack of my activity on the web in general), due to my current real-life situation, I barely have any free time except for those few precious hours in the weekend in which I try to run my own life.

This means that my open-source activity went to a level which is not enough to do anything which requires long sessions (*cough* coding new stuff *cough*), and only translations of open source software are being kept in progress (very slowly, but they are being worked on and I'll commit them when I have enough material).

Now that I said that, and now that you know why I'm rather unresponsive by email/comments to this site, let us begin a technical overview of the project status. Note that this was originally written as an email, so I'll sometimes write as if I'm addressing someone specific in a conversation, and sometimes I talk in general (3rd person). Please ignore this inconsistency...

Technical Overview & Status

Proposal
Unfortunately, I failed to find the original proposal. However, you can find the proposal which I recorded in the GIMP wiki. The proposal is located here.

Papers
I'm listing them here, it will become clearer once you see the modules listing.

• The paper behind the seamless cloning algorithm: Coordinates for Instant Image Cloning
• Unfortunately, due to open source licensing issues and some other reasons, I had to implement myself an algorithm for creating fine triangular meshes.
• The algorithm I used (and implemented!) was the Delaunay Terminator, as described by Jonathan Richard Shewchuk in his paper Delaunay Refinement Algorithms for Triangular Mesh Generation.
• Some of the code was based on an existing library (poly2tri) which is in turn based on it's own papers

Modules
The project is divided into 3 main modules

• A library for creating fine triangular meshes - poly2tri-c
• The first part of this library is a C port of a library for creating Constrained Delaunay Triangulations, which are basically "nice" triangulations of existing outlines with/without holes.
  The original library is poly2tri, and the C port I wrote can be found in poly2tri-c's repository under the poly2tri-c/p2t folder
• The second part of this library is an implementation of the Delaunay Terminator algorithm for what we call a Delaunay Refinement.
• Delaunay Triangulations are triangulations which are considered "nice", meaning that most triangles are more or less of equal size, without too big or too small angles.
• Delaunay refinement is the process of taking a Constrained Delaunay Triangulation (which is not exactly Delaunay due to constraints such as outline that must be respected) and refining it by inserting more and more points. The process terminates when the resulting triangulation is almost Delaunay.
• The implementation of the algorithm above was made from scratch and in fact was the biggest part of the GSoC project (the assumption was that there was an existing open source library to do this. Apparently it wasn't so...)
• My implementation can be found in poly2tri-c's repository under the poly2tri-c/refine folder
• The third and final part of this library is an implementation of a triangular mesh render. The render basically takes a mesh created from the refinement process, a buffer to fill and a vertex-to-color function, and creates an image of the mesh in the specified resolution and size.
• This is another implementation from zero, although quite trivial and could probably be made more efficient
• The original article used OpenGL to do this rendering, resulting an ultra-fast renderer. Since the project was done when GIMP/GEGL were in an unclear state regarding usage of graphics hardware acceleration, it was done on the CPU purely which is much slower (yet still almost interactive - less than a second for rendering regular objects)
• My implementation can be found in poly2tri-c's repository under the poly2tri-c/render folder

• The second part of the project is a GEGL operation for doing the actual seamless-cloning operation.
• In brief, here is a description of the process (needed to understand the state of the code):
• Do a heavy preprocessing step for creating a fine triangular mesh from the outline of the pasted area
• Now, for each render attempt, compute the color differences between the edges of the paste and the background image, and use the previously created mesh to interpolate the differences in the colors along the entire area of the pasted image. Add the interpolated color differences on-top of the paste and you get a seamless pasting!
• The GEGL implementation of the operation can be found under gegl/operations/common/seamless-clone (in the soc-2011-seamless-clone branch):
• Files beginning with sc-* are part of a "shared library" with the code required to do seamless cloning
• This library is used using the GeglScContext object (sc-context.h) which manages a seamless cloning operation for a specified buffer to use as a paste.
• GeglScContext implements smart logic to notice when a paste doesn't change between rendering sessions (i.e. calls to the process function) in order to avoid re-doing the heavy preprocessing step
• Ideally, GIMP would use this "seamless cloning library" to implement seamless cloning with an internal op that does not need to do this check over and over, since the paste can't change when moving it on the canvas in the GIMP UI. However, currently gimp uses the GEGL op which is described below in a rather dumb way...
• This library even exposes a pkg-config file to be easily linked against later...
• seamless-clone.c implements gegl:seamless-clone - A simple seamless cloning operation using the above library.
• seamless-clone-compose.c implements gegl:seamless-clone-compose - A simple meta-op for GEGL that composes the seamless paste above a given background...
• Finally, in order to have the triangulation algorithm included, a copy of poly2tri-c is included under the libs directory of GEGL. This is since poly2tri-c has no package that can be installed and it was asked for so that developers won't need to download additional source code from more locations. This is not a desired situation, yet I'm unaware of any package owners for various Linux distributions which would be willing to help with distributing poly2tri-c as it's own package. If any such developer would be found, send them to me and I'll give them any access/help to the repositories (and I'll do any code modifications needed)

• A GIMP tool using the seamless cloning GEGL op
• The tool is a bit buggy in terms of refreshing the canvas (sometimes, artifacts are left when dragging the paste)
• Additionally, it is inefficient since it doesn't use the library directly and so it does the check of whether the paste buffer changes each time
• I'm not sure whether the errors regarding non-continuous pastes (with holes and/or composed of several unconnected parts) do find themselves into the GIMP UI in a proper way...

GIMP/GEGL TODO

• Make GIMP check for the presence of the seamless cloning operation on the startup of the tool
• Make GIMP use the library directly (and check for it's presence on compilation time)
• Conditional OpenGL for doing the rendering of the triangular mesh!
• Implementing the OpenGL rendering in poly2tri-c should be very easy for anyone knowing OpenGL. I'll do it if GIMP/GEGL accepts OpenGL (not OpenCL! That's different!) into the pipeline
• Fix the described bugs in the GIMP tool UI

Poly2tri-C TODO

• Code cleanup, prepare for distribution (I'll do that - it requires less coding then the GIMP stuff and does not require a long coding session - so I can do it on my short available time periods)

During the past months work has been done on preparing a modernized and brand new website. First...

• Emacs, C-SPC, dead keys, and ibus

  Some time before or during the GTK+ hackfest, Emacs on my laptop started acting strange. C-SPC wasn't working (a major catastrophe), and when using a Latin American keymap, it was spewing nonsense like <dead-acute> is undefined.

  Today I finally figured it out, but just by comparing things between my machine-where-emacs-works and my laptop. It turns out that ibus had gotten installed on my laptop, and it was screwing things up.

  TL;DR Emacs stopped handling C-SPC and dead keys; I uninstalled the ibus package and everything works again.

  I have no idea of how Emacs users manage to live when they actually need to use ibus for input methods.

If you want your GNOME build in the Fedora 19 Beta, please make sure you release a tarball today. The builds are being collected in a spreadsheet and the mega-update will be filed tomorrow morning.

The day after Volkswagen + Wolfsburg I was on my way to San Francisco. I had been invited by the California College of the Arts (CCA) for their Dutch Design Week, ‘a series of events celebrating Dutch Design and fostering exchange between Dutch and American Designers.’

My personal highlight of these events was a two‐day masterclass for design graduates and interaction design undergraduates. Not only because of the intense and re‑energising work with the CCA students, but also because I learned something new from two cases of unintended consequences.

begin the beguine

While I was planning the class, Kristian Simsarian—chair of the interaction design program at CCA—encouraged me to pick a topic which I am passionate about. So I picked two: product realisation and mobile. The last decade these have been the most important themes in my design practice, with the highest impact.

So the masterclass was going to consist of designing a proper mobile website or app for a software product, a service, website or organisation. Question was: which one?

uncanny valley

I am not comfortable with structuring my teaching around imaginary projects. Only when there are one or more persons inside a project who burn to make something valuable, it is viable for designers to work on it and realise this goal.

So instead of making up an imaginary project for this class, I asked the participating students to bring their own project, one they are passionate about. I was curious to see what they would bring in: could be some app they love but wanted to redesign, or a local community project. At the end each student brought a personal project to work on, some of them with a local (transport/biking) flavour.

on the one

Fast‐forward to the first morning of the masterclass. The CCA’s SF building is like a cathedral part‐filled with a labyrinth of cosy spaces to teach and work. Next door to my class was the one of industrial designer Maarten Baptist. Right in front of us, the floor of the ‘nave’ filled up with the graphic design students of Marijke and Chantal, i.e. Cobbenhagen Hendriksen, working on posters. Everyone was inspired.

After a riveting introduction by Alexander Baumgardt—who had been instrumental in bringing me over for the week—it was time for me to get to know the students, seven graduates and five undergrads. I am always interested in the reason why each chose to participate, it tells me something about this student and her/his expectations, and the future of my industry.

get with the program

I then explained the main building blocks of the class, product realisation and mobile, and two auxiliary ones: ‘design is solving the problem’ and ‘designing is done pencil on paper.’ I wove these together with an overview of my career, to show where they are coming from and why they play such an important role in my practice.

explaining the tactical deployment of user scenarios; photo © Kathleen Moynahan

Next, I structured our work for the first day. We started off with the product phase; building a foundation for the design work: product vision; functionality overview; user scenarios; expert evaluation. First up was the method that I see as crucial for product realisation: compiling a product vision.

vicious games

Experience tells me that it is incredibly hard for project insiders to define their vision; it’s like pulling teeth. It also takes a long time; weeks of pulling teeth. I did not have the time for this, although I had created the situation that every student entered the class as a full insider of her/his own project.

What I needed was what every project needs: a moderator to tease the vision out of the project insiders. Luckily I had a class full of potential moderators. Product realisation means working from a vision, thus it became natural to go through the exercise of moderating one.

1 + 1 = 2

During the morning, I introduced the product vision method and told the story of how I developed it years ago. I showed the Krita example—long live open working—and explained what each part means, down to single words. Then I asked the students to work in pairs.

Because I found the interaction specialisation vs. maturity asymmetry in my class interesting, I asked the undergrads to pair up with a graduate student, just to mix things up. Looking back I can report that collaboration was exemplary.

Within each pair, one would take the role of moderator, helping the other—insider to her/his own project—to formulate a vision. Then they swapped roles.

altogether

Getting a product vision together takes time and each pair had to formulate two of them. As a result we spent a couple of hours on this method. Apart from doing Q+A and guidance with the six pairs, I also held two rounds of discussion with the complete class.

In these discussions we spoke about how we were doing, what we were observing and experiencing, and I explained the more tricky parts of a product vision. From the reaction of my students, I got my first dose of unintended consequences.

1 + 1 = 4

By now you know that I had the students work on a vision in both moderator and insider roles just to stand a chance of getting it done. I could have predicted that by playing both roles they would get twice the insight into the product vision method.

But judging from the overwhelming reaction of my students, I seemed to have a struck a quadratic effect. They were enthusiastic and ‘getting it’ as if they just had four times the insight. That really made my day.

can you dig it?

Here are three product vision statements made in the class:

‘The Thrive App gives a voice to household plants. Thrive lets busy, novice plant owners know their plant’s well‐being via a paired sensor in the soil and recommends appropriate care through the voice of the plant.

‘Thrive notifies owners of their plant’s vitals in real time. Thrive connects people to nature in a small way by creating an emotional bond between people and their plants.’

vision © Ramunė Rastonis, moderated by Allison Leach

‘Echosphere is a mobile application that creates and controls sounds based in your movement.

‘By combining live movement with sound and visuals, it helps an older audience reawaken their sense of play.

‘Echosphere is an individualized, immersive experience that encourages breaking out of analytical thought.’

vision © Kathleen Moynahan, moderated by Evan Litvak

‘MyWay is a smartphone app to optimize the daily use of public transportation. Users can personalize their regular destinations and schedules. The app keeps track of the public transportation times and provides accurate feedback to the user, sending updates. It learns from users’ behavior and automates their routine trip plans.

‘It is meant for San Franciscans, in their 20’s to 50’s, who use public transportation, own smartphones and are familiar with the streets of San Francisco. The users have busy schedules, commute daily with normally 2 to 4 regular destinations.

‘With MyWay people will be able to clear their minds from repetitive tasks of keeping tracks of their time to catch public transportation. It will free the user from the burden of keeping constant eye on the transit schedule.’

vision © Tatsiana Siadneva, moderated by Francis Nakagawa

It is clear what each of these three is about and what value it aims to deliver. And that is the point of a vision.

bat man

On the second day of the masterclass the accent moved to mobile interaction. It was time to lead the students to a series of hard mobile design choices that they had to make for their project. For instance:

mobile website or app?

This choice should not be based on how cool, or confident one feels designing it, but on what is best implementing the product vision.

fragmentation

With limited time available for this class, I made the students pick one platform and one screen size (‑range, in cm/inches of course) to design for. In the real world, each (supported) combination of these two needs a separate, optimised design.

the nr.1 issue in mobile

a.k.a. the battery. It has been the issue for decades. As interaction designer—i.e. designer of ‘the whole thing’—one will either be confronted with severe limitations set by the platform on how much the app/site can be ‘alive’ all the time, or there are no limits and one has the full responsibility to not drain the battery, all the time.

The overall goal of the masterclass was to design a solutions model; i.e. the broad‐strokes plan that solves the main design challenges, plus a strategy to design the rest. A complete (draft) design of even a small app would have been too much work for our two days.

go west

I encouraged my students to explore and brainstorm before working reductive and settling for a solution. But in practice, quite a few of them settled too quickly.

So I challenged these students: ‘I see your design hinges largely on XYZ, It would be good if you brainstorm a few ideas that do not involve XYZ. Either you’ll find something better than your current plan, or you will learn valuable lessons about XYZ.’

Thrive interaction sketches, © Ramunė Rastonis

go next

Working with the students showed a lot of variation. Each had her/his own pace, project, approach, and design. I enjoyed immensely working with each individually and I am sure all of us would have enjoyed a couple of days more of designing together. Then there was the second case of unintended consequences.

The feedback of most students was that they were going to continue working on their project. This is really different than usual, where the project gets dumped the moment the class is over. Why was it different this time? Ah, because each of them brought a personal project.

All in all it is very rewarding to see the impact of the masterclass. To see how the project of every student made at least two steps in the right direction. To see how the students ‘got’ something out of it that they can use during their design careers.

Echosphere interaction wireframes, worked out after the class, © Kathleen Moynahan

postscript

I did a panel discussion and a Q+A session with first year interaction design students during the CCA Dutch Design Week. I also met a lot of interesting people. But the masterclass stands as my personal highlight because from all the feedback I got, it was clear that both the students and the CCA got a real kick out of it. And so did I.

I would like to thank the students for their hard work; Tatsiana, Kathleen and Ramunė for allowing me to share their work here; Alexander Baumgardt for getting the ball rolling; and all at the CCA and the Dutch consulate who enabled this trip.

In a world where so many open source projects never get to version 1.0, I’ve just announced colord 1.0.0. See the archives for the release announcement and the FAQ for details about the new numbering scheme.

My friend and occasionally-quadrennial conference co-organizer, Peter Rukavia, is writing about his experience with a developer-preview Firefox OS phone.

His perspective is particularly interesting as it doesn’t come from inside the Firefox/Mozilla world. He’s just your average run-of-the-mill kind of alpha-geek that would pre-order a semi-functional developer preview device from Spain to try out an unproven operating system. Keep us posted, Peter.

If you’re wondering why Mozilla is working on building a mobile operating system, when the market is already maturing to two(ish) leaders, see former Mozillian, Asa Raskin’s article on why Mozilla is at its best when being a “fast second follower”.

In my previous article about pulse-width modulation on Raspberry Pi, I mentioned that the reason I wanted PWM on several pins at once was to drive several motors, for a robotic car.

But there's more to driving motors than just PWM. The GPIO output pins of a Pi don't have either enough current or enough voltage to drive a motor. So you need to use a separate power supply to drive the motors, and do some sort of switching -- at minimum, a transistor or relay for each motor.

There are lots of motor driver chips. For Arduinos, "motor shields", and such things are starting to become available for the Pi as well. But motor shields are expensive, usually more than the Pi costs itself. If you're trying to outfit a robotics class, or to help low-income students build robots, it's not a great solution.

When I struggled with this problem for the Arduino, the solution I eventually hit on was a SN754410 H-bridge chip. For under $2, you get bidirectional control of two DC motors. For each motor, you send input to the chip via a PWM line and two directional control lines.

The only problem is the snarl of wiring. One PWM and two direction lines per motor is six wires, plus power for the chip's logic side, power for the motors, and ground, and the three pins for a serial cable, and you're talking a lot of wires to plug in. Although this is all easy in comcept, it's also easy to get a wire plugged in one spot over on the breadboard from where it ought to be, and then nothing works.

I spent too much time making tables of what should get plugged into where. I ended up with a table like this:

Pi connector pin	GPIO (BCM)	SN754410 pin
Pi 2	5V power	Breadboard bottom V+ row
Pi 18	24	1 (motor 1 PWM)
Pi 15	22	1 (motor 0 PWM)
Pi 24	8 (SPI CE0)	4 (motor 1 direc 0)
Pi 26	7 (SPI CE1)	14 (motor 1 direc 1)
Pi 25	Gnd	Breadboard both grounds
Pi 19	10 (MOS1)	3 (motor 0 direc 0)
Pi 21	9 (MOS0)	13 (motor 0 direc 1)
motor 0		5, 11
motor 1		6, 12

... though, as you'll see, some of those pin assignments ended up getting changed later.

One more thing: I found that I had to connect the chip's logic V+ (pin 2 on the SN754410) to the 5v pin on the RPi, not the 3.3V pin. The SN754410 is okay with 3.3V logic signals, but it seems to need a full 5V of power.

Programming it

The software control is a little trickier than it ought to be, too, because of the 2-wire control lines on each motor. With both lines high or both lines low, nothing moves. (Some motor driver chips distinguish between those two states: e.g. both low might be a brake, while both high lets the motor freewheel; but I haven't seen anything indicating the SN754410 makes any distinction.) Then set one line high, the other low, and the motor spins one way; reverse the lines, and the motor spins the other way. Assuming, of course, the PWM line is sending a signal.

Of course, you need RPI.GPIO version 0.5.2a or later to do any of this PWM control. Get it via pip install --upgrade RPi.GPIO -- the RPI.GPIO in Raspbian mis-reports its version and is really 0.5.1a.

Simple enough in concept. Okay, now try explaining that to beginning programmers. No, thanks! So I wrote a PiMotor class in Python that takes care of all those details. Initialize it with the pins you want to use, then use calls like set_speed(s) and stop(). It's on GitHub at pimotors.py.

I put the H-bridge chip on a breadboard, wired up all the lines to the Pi and a lithium-polymer airplane battery, and (after several hours of head-banging while I found all the errors in my wiring), sure enough, I could get the motors to spin.

But one thing I found while wiring was that I couldn't always use the GPIO lines I'd intended to use. The RPi has seemingly a lot of GPIO lines -- but nearly all of the GPIO lines have other purposes, except I haven't found any good explanation of what those uses are and how to know when they're in use. I found that quite frequently, I'd try a GPIO.setup(pin, GPIO.OUT) and get "This channel is already in use". Sometimes GPIO.cleanup() helped, and sometimes it didn't. None of this stuff has much documentation, and I haven't found any IRC channel or mailing list for discussing RPi GPIO. And of course, there's no relation between the pin number on the header and the GPIO pin number. So I spent a lot of time counting breadboard rows and correlating to a printout I'd made of the RPi's GPIO socket.

Putting the circuit on a proto-board

Once I got it working, I realized how much I didn't relish the thought of ever doing it again -- like whenever I needed to unplug the motors from the Pi and use it for something else.

Fortunately, at some point I'd bought an Adafruit Pi Plate, sort of the RPi equivalent of Adafruit's Arduino ProtoShield. I love protoshields. I have a bunch of them, and I use them for all sorts of Arduino projects, so I'd bought the Pi Plate thinking it might come in handy some day. It's not quite like a protoshield, because it's expensive and heavy, loaded up with lots of pointless screw terminals. But you don't have to solder the screw terminals on; just solder the headers and you have a protoshield for your RPi on which you can put a mini breadboard and build your motor circuit.

I do wish, though, that Adafruit or someone made a simple, basic proto board PCB with headers for the Pi. No screw terminals, no extra parts, just the PCB and headers, to make it easy and cheap to swap between different RPi projects. The HobbyTronics Slice of Pi looks intriguing, but the GPIO pins it exposes don't seem to be the same ones exposed on the RPI's GPIO header. I'd be interested in hearing from anyone who's tried one of these.

Anyway, with the Pi Plate shield, my motor circuit looks much neater, and I can unplug it from my RPi without fear that it'll mean another half hour if I ever want to get the motors hooked up again. I did have to change some of the pin assignments yet again, because the Pi Plate doesn't expose all the GPIO pins available on the RPi header. I ended up using 25, 23, 24 for the first motor, and 17, 21, 22 for the second.

I wanted to make a circuit diagram with Fritzing, but it turns out the Fritzing I have can't import part definitions like the one for Raspberry Pi, and the current Fritzing doesn't work on Debian Wheezy. So that'll have to wait. But here's a photo of my breadboarded circuit on the Pi Plate, and a link to my motor breadboarded circuit using a cable to the GPIO.

Kevin Mark tipped me off that Fritzing is quite easy to build under Debian, if you first apt-get install qt4-qmake libqt4-dev libboost1.49-dev
I had to add one more package to Kevin's list, libqt4-sql-sqlite, or I got a lot of QSQLITE driver not loaded and other errors on the terminal, and a dialog saying "Unable to find the following 114 parts" followed by another dialog too big to fit on the screen with a list of all the missing parts.
Once those packages are installed, download the Fritzing source tarball, qmake, make, and sudo make install.

And my little car can go forward, spin around in both directions, and then reverse! Now the trick will be to find some sensors I can use with the pins remaining ...

After a whole one year of development we are happy to present you a new major release of Synfig Studio!...

I hesitate to mention G'MIC in a title sometimes because I feel that whatever I write is not going to do it justice. For this post, I couldn't resist.

I really should have posted this a while ago when I first saw it, but to be honest it slipped under my radar. So I'm trying to catch up and make amends.

+David Tschumperlé was kind enough to post today a link to some incredible work done by Jérome Ferrari with more averaging images. (It is seriously incredible).


This time everything was done entirely in G'MIC. The images are aligned on the eyes automatically using a little cropping and phase correlation, then scaled to fit both eyes. The results are fantastic.

They are also way faster than doing it my way (aligning eyes and scaling to fit by hand in GIMP).

Head on over and check it out:

Averaging face photos : eye alignment

Also, be sure to check the follow up where there are some slight distortions applied to align the mouths as well.

Well, the second Ubuntu Long Term Support release, 8.04 Hardy, has reached end-of-life. (Along with 11.10 Oneiric and the Desktop Support for the 10.04 LTS Lucid.) Flushing my package mirror of Hardy and Oneiric was pretty dramatic, freeing up about 142GB worth of space.

Before:

$ df -h /var/cache/mirrors/
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/sysvg-debmirrorlv  753G  692G   62G  92% /var/cache/mirror

After:

$ df -h /var/cache/mirrors/
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/sysvg-debmirrorlv  753G  550G  204G  73% /var/cache/mirror

If only online filesize resize shrinking worked. :)

© 2013, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

I’ve been working on Enfuse support in Rawstudio for quite a while and now it’s ready for some testing :D

It was added to trunk yesterday and packages are ready in our Launchpad PPA for Ubuntu.

A quick guide:

1. Select photo(s) and press ctrl-alt-e (or find Enfuse in Photo menu).
2. Adjust settings and update thumbnail by clicking on it .
3. When you are happy with the thumbnail, click “Execute” and wait for the finished result to be opened.

Some notes:

• You might have noticed that I’ve written “photo(s)” in the first step above – you can select just one photo and Rawstudio will help you export different exposures from that photo and you might get a better result than the initial photo (or not).
• To get as high a quality as possible, Rawstudio exports photos in 16bit PNG and Enfuse hands it back to Rawstudio as 16bit PNG. Even though the files are PNG, the extension are “rse” (RawStudio Enfuse) to make the files easy to identify.
• Be patient! I’ve done a lot to speed the process up as much as possible, but exporting, aligning and enfusing full size photos does take time!
• Photos that have been enfused might need some extra work as you are used to with RAW :)

Well, go ahead and give it a try – I’d like to get some comments on it (here or at http://bugzilla.rawstudio.org/)

 

I’ve made a few screen captures of it in use. This is the speed I have on my relatively slow laptop. Check them out below…

 

Multiple photos with camera mounted on a tripod:

 

Multiple photos with handheld camera (aligning required)

 

Single photo:

• This is amusing and bitter at the same time.

A couple of months ago I wrote about watching an eclipse of Europa by Jupiter's shadow. It's a game I call "Whac-a-Moon", where a moon comes out from behind Jupiter, but stays there for only a short time then disappears into eclipse. If you aren't ready for it, it's gone.

This can only happen when Jupiter's shadow is offset from Jupiter that there's a gap between the planet and the shadow as seen from Earth. Jupiter is getting low in the west, and soon we'll lose it behind the sun, but tonight, Wednesday May 8, there's a decent Ganymede Whac-a-Moon opportunity for those of us on the US west coast.

Ganymede disappears behind Jupiter at 6:45 pm PDT, still during daylight. Some time around 9:43 Ganymede reappears from behind Jupiter, but it only stays visible for a couple of minutes before entering Jupiter's eclipse. Don't trust these times I'm giving you: set up at least five minutes early, preferably more than that. And set up somewhere with a good western horizon, because Jupiter will be very low, less than 8 degrees above the horizon.

You can simulate the event on my Javascript Jupiter. When the G goes blue, that means Ganymede is in eclipse. But the simulation won't show you the interesting part: how gradual the eclipse is, as the moon slides through the edge of Jupiter's shadow. During the Europa eclipse a few months ago, I wanted to record the time of disappearance so I could adjust my code accordingly, but I found I couldn't pin it down at all -- Europa started dimming almost as soon as it emerged from behind Jupiter, and kept dimming until I couldn't convince myself I saw it any more.

So far, I've only watched Europa as it slid into eclipse by Jupiter's shadow; I haven't whacked Ganymede. But Ganymede is so much larger that I suspect the slow dimming effect will be even more obvious. Unfortunately, I'm not optimistic about being able to see it myself; we've had cloudy skies here for the last few nights, and that combined with the low western horizon may do me in. I may have to wait until autumn, when Jupiter will next be visible in our evening skies. But I hope someone reading this gets a chance to see this month's eclipse.

( читать по-русски | Russian translation )

As many of you know, this April I was happy to attend the Libre Graphics Meeting (LGM) event in Madrid - the largest conference for free software graphics application users and developers. Much thanks to all community members who made this trip possible!

It took some time for me to analyze the results and have everything settled in my mind. So, today I would like to present a personal report about this event.

This was my second experience of attending LGM. Previous year I have attended LGM in Austria and gave a talk about Remake usage. This year it was a bit different. My plan was to give a workshop about the usage of character template that we have developed lately. Another important thing is that LGM was attended by Synfig’s main developer – Carlos López González – so my target was to have a meeting with him for a productive collaboration.

Also, I have decided to expand the benefit of my trip and organized additional Synfig workshops on my way to LGM. There were two workshops in St. Petersburg for “Regional Center of Quality Evaluation in Education and IT” and one in Moscow for the “Moscow’s Institute of Open Education”. The first workshop in St. Petersburg was about technique of cutout animation in Synfig. The second was advanced one about the usage of character template (same as given at LGM). Moscow’s workshop was about cutout animation only. All workshops are turned out great, we had a lot of discussions during the events and I’m happy to see a good trend – there is a growing interest for Synfig as alternative to replace Flash in Russian education.

During my stay in St. Petersburg I also got a chance to visit “Melnitsa” – the biggest animation studio in Russia. That was really good experience for me.

By the way, the interest to use Synfig in education is not a Russian-only trend. My workshop about the character template was at the very first day of LGM, and besides the conference members there was a lot of students from the art academy. Right in the middle my workshop was interrupted by the fire alarm, but in general it all went fine.

Unlike the LGM talks, the workshops weren’t recorded, but in the last two days of LGM I was invited for a live broadcast at Experimental TV and I’ve took that chance to re-record the workshop contents as a screencast. As result – you have my workshop available as tutorial online now. The live broadcasting was very fun and people told me that it was a longest session in the history of Experimental TV.

This year the LGM was attended by 5 representatives of Synfig community:

• Konstantin Dmitriev (me, aka Zelgadis)
• Carlos López González (aka Genete)
• Jerome Blanchi (aka d.j.a.y.)
• Timothée Giet (aka Animtim)
• Manuel Ospina (aka Mospina)

In the third day of LGM we had a development meeting (BoF), where we discussed a development priorities for Synfig. It was decided to continue work on optimizing rendering speed for workarea. Another priority turned to be the Single-Window interface and we discussed the optimal strategy of its implementation.

Besides the main priorities we have took a chance to discuss implementation strategies for Bones, Raster Drawing Tools, Vector Drawing Tools and Frame-by-Frame Animation Support.

It was a lot of fun to meet you all guys there, and I’m proud to be a part of your community!

One of the frequent questions people ask me is about the results of our meeting with Nina Paley. In my opinion it’s a bit hard to talk about results, since  it usually takes time for such consequences to show up. But below is some brief attempt for analysis.

Nina got into complex situation. From one side there was a Synfig, from the other side – Tupi. And there also was Blender, which wasn’t represented at LGM and she don’t know anything about, except that it have very well established development. On the other  hand, she likes Flash so much and none of the mentioned tools are close to deliver the Flash experience she have.

In such situation, there is a willing to do something to make a difference, then that probably implies supporting one of the projects. But the main question is: which one? Choosing which one project give support to is impossible without deep expertize, investigation and a lot of learning. And that requires time and resources. So I have to disappoint my readers expecting decisions to be taken now and sudden – nothing like that will take place at the moment.

At this moment, for Nina all the existing open-source projects look equally far from ideal and the worst thing is that she’s not that much into free software culture (yet?) to believe that it worths to put her efforts into it.

Another problem of the discussion was that none of the participating sides was able to offer a clear strategy of establishing collaboration.

So, before Nina really could do something, she have to answer many questions for herself:

• Which one project give support to?
• How to give support
• Does it worths to dig into this at all, or better just go with proprietary software?

Lots of questions, eh? For me, as being a part of Synfig, all the questions can be reformulated in much simpler one: “Why not Synfig?”

During the LGM days me and Nina had a few practical sessions for Synfig usage, giving it a “test-drive”. At the end, her main complains about Synfig were summarized as low response/performance speed and the complexity of the program (“too difficult to learn”). She admitted that found impossible to learn Synfig on her own, without direct (personal and in-place) developer/consultant assistance and the software speed is considered on top of all her other priorities.

Then why not give a hand to Synfig and help to get rid of the outlined issues? Let me be honest here: at the current status Synfig isn’t ready to receive a support nor from Nina Paley, nor anyone else. The situation is that Synfig doesn’t have a resource gap to put the money into, which will guarantee the result as feedback, clearly observed as benefit for the sponsor.

So it’s a good moment to think what are exact steps we (Synfig) can do to leverage the existing gaps. Here are a my thoughts:

1. We need to bring Synfig development from random/freetime contributions to the status of planned and regular process.  For the past years there are already a good substantial movements in that direction, but we need to push that even further. This is impossible without establishing full-time employment for major Synfig contributors. And I feel the situation  gets ready for that. I’m not sure when exactly would it happen, but I’m sure that will be a real “game changer”.

2. The critic about Synfig’s complexity couldn’t be ignored. Of course, that could be done by changing Synfig itself and that refers to my previous point about full-time employment. But there’s also another way. For the past years we have proofed Synfig as suitable for animation production in the state “as it already is”. We have developed a workflows and that become our “know-how”.  Now we need to deliver this knowledge, those workflows to the audience. At the moment it doesn’t go further than random tutorials and screencasts. I think we have to bring this content to the next level by following Krita & Blender steps – releasing training DVDs. My experience of doing workshops in St. Petersburg and Moscow shows that the explanation of basics of cutout animation workflow in Synfig could fit into 2-3 hours. As result of those workshops I have a methodics and proofed it as effective. So, I believe that might be a really good direction to put our efforts into.

So, that’s the introspection. What else can I say about LGM?

Of course there was a LOT of interesting workshops. Unfortunately many of them were overlapped in time and that forced me to make a hard choices. Personally, I would prefer workshops to take place in parallel with the talks instead of having several workshops at the same time.

So I have missed the workshop by David Revoy, because we had Synfig meeting. For the same reason I missed the Krita Sketch workshop by Timothée Giet – I’ve dropped by at the “animation creation workflow sharing session” by Girin Studio. It was very interesting to see their approaches and I really admire of their work. Of course I couldn’t miss a chance to share our workflow – so it turned into a kind of another unplanned workshop for me.

Also at LGM I have discovered a modification of Pencil, which turns this software into stop-motion tool. Awesome idea! Unfortunately, they have used the official version of Pencil, not ours. So it might require some efforts if I would decide to merge their changes.

This year I was not much into attending talks, instead I was happy to have some coding/debugging sessions with Carlos. I’ve started to work on the Zoom Handle feature for Group layers and almost finished another feature that allows to set default interpolation for individual layer’s parameters. Also we have discussed some neat concepts about extending Synfig animation features. That was a lot of fun and also the great chance to expand the horizons!

Well, I think that is. My report is already too long and it’s hard to fit all the awesome events happened. I was happy to meet  a lot of awesome people and although it was only a few days, I feel many of you as a close friends and always smiling when see your faces at the photos or videos.

At the end of my trip, when I met Alexandre Prokoudine in Moscow, he asked me what was the most important thing happened to me during the conference. I was unable to answer clearly. It was too early to answer. Now, after everything settled down in my head and first results are starting to reveal themselves, I can answer clearly: the most important thing in this trip was meeting Carlos López González and collaborating together. I think the consequences of that are hard to underestimate and more results are sure to follow.

P.S. You can read more LGM reports from an awesome people here:

• http://timotheegiet.com/blog/anim/back-from-the-future-tools-lgm-2013.html
• http://krita.org/item/144-libre-graphics-meeting-2013
• http://www.ramonmiranda.com/2013/04/lgm-madrid-2013-future-tools.html
• http://tatica.org/en/2013/04/17/lgm-2013/
• http://girinstud.io/news/2013/05/report-of-our-first-libre-graphics-meeting/

…and here are also links to LGM photos I found:

• Official LGM photostream
• Gallery by Tobias Ellinghaus
• Galleries by Peter Westenberg: (1) (2) (3) (4)
• Photos by David Revoy
• Gallery by Carlos López González
• Gallery by Tatica

Stuff like this makes me sad:

apparently rethinkdb’s official js client is coffeescript hahahah #fail

— TJ Holowaychuk (@tjholowaychuk) May 7, 2013

Also, the github issue where TJ requests that everything gets rewritten in plain JavaScript: https://github.com/rethinkdb/rethinkdb/issues/766

 

We’ve been here before
Language discussions aren’t new (nor is vim vs. emacs). In the GNOME community we’ve seen a ton of them. Just recently there was a huge one at the DX Hackfest.

GNOME/Mono developers have certainly received their dose of crap thrown at them. But so have GNOME developers that preferred Vala, Python, JavaScript, or even just GObject/C. Whatever you seem to be using, it’s never the right thing for someone.

Have all these years of shedding words over it solved anything? Frankly: no. We are still seeing a large combination of languages being used and all of those projects have good reasons to do so.

I get TJ’s point though: by using CoffeeScript, the rethinkdb people are making it harder for the wider JS community to contribute to their project. But…

 

It really doesn’t matter
Most open-source projects (or modules) don’t have a ton of contributors. It’s usually a modest team of core maintainers/developers that do the bulk of the work. And that’s fine: the success of a project should not be measured by the number of contributors, but by the quality of the software it produces.

This smallish team of core developers will have their own good reasons for picking up a certain language. They’ll use the language that they feel most productive with for the task at hand. And that’s a good thing, they are mostly the people that move the project forward.

The biggest barrier to contributing on a project is not the language, there are plenty of projects written in unproductive languages that get a ton of contributions. Any good programmer can pick up a new language up quickly (and TJ is more than just a good programmer, he’s a fantastic one, much respect). The bigger hurdle is the specific domain knowledge involved.

Let’s all agree to disagree and have some respect for each other’s opinions, they are all valid anyway.

 

PS: I’ll be heavily moderating comments that try to turn this into a flame-war. I’m writing this to find some more respect and understanding.

New in this release is the Freestyle render engine for cartoon rendering and a 3D Print toolbox....

In my recent experiments and playing around with even more image averaging in Imagemagick, I decided to have a look at some other methods for calculating pixel values. This time I focused on stacks of images of the same thing.

Why the same thing?


Because the (uninspired) above image was shot at ISO 25,600. Go look at it again.

To be fair, I cheated a little bit... The relatively noise-free image you see above shot at ISO 25,600 is actually combined from 10 identical shots.


The trick is that I combined all of the shots using a median evaluation in Imagemagick. This basically means that for every pixel in the image, there were 10 pixel values to choose from. Imagemagick automatically picked the pixel value that was closest to the middle.

So if we had a list of 7 values, for example, that looked like this:


Then the median value is just the number in the middle of the list:


If there were an even number of values, the median is calculated as the average of the two numbers in the middle (usually).

This is different from the averaging I had done previously, where the pixel value was an average of all the values at a given pixel location (though both methods could be used to reduce noise in the final result).

Here, let's look at a couple of 100% crops side by side between my median stack example and a base image:





Pretty neat, right? (Seriously, look at that last image - you can't even make out "Fast Focused Fearless" in the single shot)

There's a few obvious caveats, though. This is only really effective for static scenes (we'll see why shortly), and the images must be aligned very well for it to work without smearing any fine details. So it should be shot from a tripod or very stable place to minimize movement between shots, or the shots should be aligned in post (using Hugin's align_image_stack - see here for an example of how to do it).

How to do it

There are two ways you can go to achieve this. The fast way, and the slow way.

First make sure your images are well aligned - shoot on a tripod if at all possible, and/or align the images with software as needed. Take as many as you feel like waiting on.

The fast way is with Imagemagick. Once you've aligned all your images (or they are spot on already), put them into a directory. Then in that directory:

convert *.jpg -evaluate-sequence median OUT.jpg

The slow way is using G'MIC in GIMP. Load up each of your aligned images as a layer in GIMP, then run G'MIC.


Then go to Layers → Blend [median] and make sure the Input Layers are All visibles, and optionally output to New layer(s).

Be prepared to wait, I've found the G'MIC version of this blend is 10x+ longer than doing it through Imagemagick. (Though I did poke David about this - so the G'MIC team might optimize this blend mode later).

Removing People

Using a Median filter to combine multiple images has been used to remove spurious objects from a scene. A common example is if you desire to get a shot of a famous landmark or tourist area, where there tends to be a lot of people around.

You can just shoot multiple shots (try for an odd number), and combine them with a median filter to remove the spurious objects throughout the scene.

For instance, here's my well-used space marine traversing my desktop:


As you can see, the final frame is after combining all of the images with a median evaluation. Voila! No more space marine!

In Conclusion

This is a really neat method to use, once you realize it's available to you, and where it can be best utilized.

If you're shooting static scenes (stock photography, still life, etc.), there's really no reason not to go ahead and set your camera to fire off a handful of frames quickly (burst mode!). Setup on a tripod, burst away, and you can significantly reduce the noise in your images with little effort.

If you want to capture scenes with many people/objects moving about, and want a clean image of an environment, just setup on a tripod again, and snap away. With enough frames, it'll make combining the images and removing those objects very easy to do.

One of the design goals of Unity was to have an Application-centric user experience. Components like the Launcher consolidate all of the windows into a single icon instead of a set like the GNOME 2 panel. Nothing else in Ubuntu thinks about applications in this way making it a difficult user experience to create. X11 worries about windows. DBus worries about connections. The kernel focuses on PIDs. None of these were focused on applications, just parts of applications. We created the BAMF Application Matching Framework (BAMF) to try and consolidate these, and while it has done a heroic job, its task is simply impossible. We need to push this concept lower into the stack.

First we looked at the display server and started thinking about how it could be more application centric. That effort resulted in Mir. Mir gets connections from applications and manages their associated windows together. They can have multiple windows, but they always get tracked back to the application that created them. Unity can then always associate and manage them together, as an application, without any trickery.

Application confinement also provides another piece of this puzzle. It creates a unified set of security policies for the application independent of how many submodules or processes exist for it. One cache directory, set of settings and policies follow the application around. Apparmor provides a consistent and flexible way of managing the policies along with the security that we need to keep users safe.

To start to look at the process management aspect of this I started talking to James Hunt about using Upstart, our process manager in Ubuntu. Working together we came up with a small little upstart user session job that can start and stop applications, and also track them. I've pushed the first versions of that to a test repository in Launchpad. What this script provides is the simple semantics of doing:

$ start application APP_ID=gedit
$ stop application APP_ID=gedit

to manage the application. Of course, the application lifecycle is also important, but Upstart provides us an guaranteed way of making sure the application stops at the end of the session.

Upstart can also help us to guarantee application uniqueness. If you try and start an application twice you get this:

$ start application APP_ID=inkscape
application (inkscape) start/running, process 30878
$ start application APP_ID=inkscape
start: Job is already running: application (inkscape)

This way we can ensure that a single icon on the launcher associates to a set of processes, managed by the process manager itself. In the past libraries like libunique have accomplished this using DBus name registration. Which, for the most part, works. Using DBus registration relies on well behaving applications, which basically guarantee their own uniqueness. By using Upstart we can have misbehaving applications, and still guarantee their uniqueness for the Unity to show the user.

We're just getting started on getting this setup and working. The schedule isn't yet final for vUDS next week, but I imagine we'll get a session for it. Come and join in and help us define this feature if it interests you.

Here are some fanart images we received from Ksenija Kuzjaeva:

 

I've written about how to drive small DC motors with an Arduino, in order to drive a little toy truck around. But an Arduino, while great at talking to hardware, isn't very powerful. It's easy to add simple sensors to the truck so it can stop before hitting the wall; but if I wanted to do anything complicated -- like, say, image processing with a camera -- the Arduino really isn't enough.

Enter Raspberry Pi. It isn't a super-fast processor either, but it's fast enough to run Linux, Python, and image processing packages like SimpleCV. A Raspberry-Pi driven truck would be a lot more powerful: in theory, I could make a little Mars Rover to drive around my backyard. If, that is, I could get the RPi driving the car's motors.

Raspberry Pi, sadly, has a lot of limitations as a robotics platform. It's picky about input voltages and power; it has no analog inputs, and only one serial port (which you probably want to use for a console if you're going to debug your robot reliably). But my biggest concern was that it has only one pulse-width modulation (PWM) output, while I needed two of them to control the car's two motors. It's theoretically possible to do software PWM on any pin -- but until recently, there were no libraries supporting that.

Until recently. I've been busy for the last month or two and haven't been doing much RPi experimenting. As I got back into it this week, I discovered something delightful: in the widely available python library RPi.GPIO, Software PWM is available starting with 0.5.2a.

Getting the right RPi.GPIO

Just what I'd been wanting! So I got an LED and resistor and plugged them into a breadboard. I ran a black wire from the RPi's pin 6, ground, to the short LED pin, and connected the long pin via the resistor to the RPi's pin 18 (GPIO 24) (see the RPi Low-level peripherals for the official GPIO pin diagrams).

With the LED wired up, I plugged in my serial cable, powered up the RPi with its Raspbian SD card, and connected to it with screen /dev/ttyUSB0 115200. I configured the network to work on my local net and typed sudo apt-get install python-rpi.gpio to get the latest version. It got 0.5.2a-1. Hooray!

I hurried to do a test:

pi@raspberrypi:~$ sudo python
Python 2.7.3 (default, Jan 13 2013, 11:20:46) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
>>> import RPi.GPIO as GPIO
>>> GPIO.setmode(GPIO.BCM)
>>> GPIO.setup(24, GPIO.OUT)
>>> led = GPIO.PWM(24, 100)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'PWM'

Whoops! But Raspbian said it was the right version ... I checked again with aptitude show python-rpi.gpio -- yep, 0.5.2a-1. Hmph!

After some poking around, I discovered that help(GPIO), after printing out an interminable list of exception classes, eventually gets to this:

    VERSION = '0.5.1a'

In other words, Rapsbian is fibbing: that package that Raspbian says is version 0.5.2a-1 is actually version 0.5.1a. (This is the sort of thing that makes Raspberry Pi such a joy to work with. Yes, that's sarcasm.)

Okay. Let's try removing that bogus Raspbian package and getting it from pypi instead:

apt-get remove python-rpi.gpio
pip install --upgrade RPi.GPIO

Then I tried the same test as before. Success! And now I was able to set the LED to half brightness:

led.start(50)

I was able to brighten and dim the LED at will:

led.ChangeDutyCycle(90)
led.ChangeDutyCycle(25)

I played with it a little while longer, then cleaned up:

led.stop()
GPIO.cleanup()

If you're experimenting with RPi.GPIO's PWM, you'll want to check out this useful 2-part tutorial:

• RPi.GPIO 0.5.2a now has software PWM – How to use it
• How to use soft PWM in RPi.GPIO 0.5.2a pt 2 – led dimming and motor speed control

What about motors?

So PWM works great for LEDs. But would it drive my little robotic car?

I unplugged my LED and wired up one of the SN754410 motor drivers circuits I'd wired up for the Arduino. And it worked just as well! I was able to control the motor speed using ChangeDutyCycle().

I'll write that up separately, but I do have one caveat: GPIO.cleanup(), for some reason, sets the pin output to HIGH. So if you have your car plugged in and sitting on the ground when you run cleanup(), it will take off at full speed. I recommend testing with the car on a stand and the wheels off the ground.

Update: the motor post is up now, at Driving two DC motors with a Raspberry Pi.

Being a developer myself, I’m constantly looking at how to improve my way of working. When it comes to mobile development, the best way to improve your life is by using Mono (Xamarin.iOS and Xamarin.Android).

That’s, in a nutshell, the talk I’ve given today at Apps City: an introductory tour on Xamarin.iOS and Xamarin.Android.

Slides are over here, though they’re very light on details and unlike my previous talk, I haven’t had time to annotate them.

In the past 3 months we've worked on a full re-render of our Open Movie in 4k - exposing the...

A couple of weeks ago I asked people to run a command which uploaded all their auto-EDID display profiles to me. This was a massive success with 1858 profiles being added to a large dataset. These were scanned by the cd-find-broken tool, and results plotted on my G+ page. As there’s been so much new data I’m updating the graphs:

I’m actually using this data to make sure we show something sane in the client UIs. Some interesting vendors are not included, e.g.:

• “System manufacturer”,3
• “To Be Filled By O.E.M.”,4

This is a chart of vendors Doing It Wrong™ by including random data (or implausible data) as the display primaries.

This shows what program created the Auto-EDID ICC profile. Unknown is probably a mixture of oyranos and also early versions of gnome-setting-daemon which didn’t set the extra metadata.

Last graph I promise. This shows a chart of all the vendors who do not populate the serial number in the EDID blob. I’ll explain why this is bad.

When we construct the device ID for colord, we use the vendor{-model}{-serial} as part of the key.  This allows you to use different ICC profiles even if you’ve got two “identical” external panels attached. Without the serial number, “lenovo-foo” looks the same as “lenovo-foo” and colord treats them as if they were the same panel. This sucks if the panels were not bought at the same time and have identical backlight burn time. Ohh, and we can’t use the connection name (e.g. DVI-1) as it would suck if you had to reassign all your profiles if you moved the connector to DVI-2…

This isn’t always a disaster: Laptops. We only need the make and model to ensure this is unique on the system as you can’t typically have two internal panels installed. This explains the Lenovo, Samsung, Dell and Apple entries I think, so don’t get out the pitchforks just yet. Unfortunately there’s nothing in the ICC profile that says “this is a laptop” so we can’t be more selective and hence this graph isn’t super useful. But, even on laptops, vendors should really be doing something semi-sane with the serial number, even if it’s just the batch number.

A new 0.1.34 colord was released this week. Thanks again to everyone that uploaded profiles.

 

Not so many links this time, I forgot to take notes…..

There was a meeting of GIMP guys at the LGM 2013 and Michael Schumacher took some notes. I like especially the part about getting good knowledge about GIMP out.

Pat David published some time ago a method to average images with ImageMagik. I stole one of his new results to illustrate this posting. A bit creepy, but you should have a look at his Playboy centerfold collection!

Really dry, with a blue suit and tie – but gooood! IBM has a nice introduction to Scribus, “the” Free and Open Source Desktop Publishing Program.

Not sure which Creative Commons License to choose? Petapixel has a graphic guide.

Rosie Hardy is a professional photographer and uses GIMP. Libre Graphics World shows some of her dreamy self portraits. She sells tutorial DVDs, BTW…….

This exhibition in Berlin sounds interesting, It’s not Nikon, but I’ll have a look.

And a new camera design, stolen from the bugs. (Thanks, Bob!)

 

 

 

• Report from the GTK+ Hackfest

  Last week we had the GTK+ Hackfest in the OLPC office in Cambridge.

  My intentions for the hackfest were to finish the merge of GtkPlacesSidebar into the master master branch — it's a new public widget that will show up in GTK+ 3.10.

  

  Over the past months I have worked on finishing the details of the sidebar: merging all the code from Nautilus, polishing the API with the help of the GTK+ team, writing reference documentation. During the hackfest I worked on some of the last user-visible details in the sidebar, particularly the way drag-and-drop feedback gets shown.

  After I pushed the merge into GTK+, Cosimo gave me the green light for merging this into Nautilus, and so the thing is done now! It feels good to have shared code between Nautilus and GtkFileChooser at last.

  Some things are pending:

  • In the file chooser, when you click on the Trash item in the sidebar, you get an error message saying that "trash:/// is not a local file system". Even though files in the trash live in your normal Unix file system, GIO says that trash:/// is not native and doesn't have a local path associated to it. We have to see how to get GIO/GVFS to mount the trash into a FUSE mount automatically.

  • There is still an ugly gtk_places_sidebar_set_show_desktop() API. I'll remove it and turn that into a GtkSetting, so that the sidebar can automatically adjust to the surrounding environment's policy about whether to show the Desktop folder or not (e.g. show it for XFCE, don't show it for Gnome).

  • Add a GtkSetting for showing XDG directories (Music, Photos, etc.) or not. XDG doesn't want to show them by default, and prefers to let users bookmark those folders directly; Gnome does.

  • Once GTK+ gets an API for notifications, the places sidebar should be able to notify you when a volume is being mounted (and is taking a long time to do so). Right now that code is disabled; it came from Nautilus, and it pretty much uses libnotify directly.

  Meanwhile in Cambridge

  For me going to the Boston area is a treat. It's a lovely city, with good public transportation, good restaurants, and with a manageable size.

  I had a chance to meet Steve Branam, of the fantastic Close Grain blog — a fellow woodworker and software developer. Steve started a hand-tool woodworking school a while ago, so if you are in the Boston area and are interested in learning, shoot him an email.

  

  Also, thanks to my friends Alán and Dori, for letting me crash at their house and keeping me well fed :)

For a while I've had a little project for debugging the desktop. Basically it starts tracking all of the DBus events on the user session startup so that you can figure out what's going on. This is especially an issue for indicators, where they're started at login, and sometimes it can be hard to track what is happening.

Previously it was pretty hard to inject into the startup of the session. Getting in the middle of building a very long command line was risky and pretty fragile. Not proud of what I had to do. Now that I have Upstart user session running, I took the opportunity port this debugging script over to Upstart.

Now I have this one simple configuration file that can be dropped in /usr/share/upstart/sessions and gets started immediately after dbus:

description "Bustle Boot Log"
author "Ted Gould "

start on started dbus
stop on desktop-end

script
	rm -f ~/.cache/bustle-boot-log/boot-log.bustle
	mkdir -p ~/.cache/bustle-boot-log/
	timeout -s INT 30 bustle-pcap --session ~/.cache/bustle-boot-log/boot-log.bustle &
end script

The beauty of this is that I can inject this small little script in, and have Upstart figure out all the startup mess. I also have minimal impact on the natural desktop boot which is critcial for testing. Simple things to make debugging easier.

Way back in November, 2011 I had written a tutorial for PetaPixel that walked through how I created the image of my daughter bouncing out of her crib:


I realized that the tutorial only existed over on PetaPixel, and that I should probably just put a copy of it here for anyone interested. So here it is.


An earlier post here on PetaPixel showcased the wonderful image created by Indylab of a flock of cell phones and the method used to create it. In a rather snarky comment, I said to get back to me when they started tossing babies, and linked to my daughter merrily jumping in her crib with her toys. Mike was kind enough to approach me about writing up a small walk-through on how I created my image, and who can honestly turn down a chance to show off their baby daughter looking so cute?

Conception

I had this image in my head for quite some time before I actually got a chance to shoot it. It was the result of two things mainly:

1. A desire to practice post processing images for compositing.
2. A desire to buy a tripod.

My wife let me buy a tripod (for other long-exposure experiments including light painting), but only because I justified it with “a neat idea” for a picture with our daughter (the “I have a great idea for a photo of our daughter, but it will require me to buy more camera gear” defense).

My desire to attempt this shot was born out of how cute I think my daughter is, and her personality is almost always explosively positive and joyful. So in my head I was imagining her just bursting with happiness so much that she literally would be jumping right off her crib. It only logically follows that if she was jumping out of that crib, her stuffed animals would be as well!

Execution

I only had a rudimentary vision of what I wanted the final image to look like, but it was enough to nail down the overall idea. In thinking about framing up the image, I liked the idea of her crib being squared up straight on in the image. I wanted the focus to be on her and her animals, and didn’t want anything else detracting from that.

I set up my tripod and camera (Oly E-P1 w/ 17mm f/2.8) in her room and framed up my shots. I had a DIY softbox for my flash precariously balanced on the bureau off screen to the right (wirelessly triggered), and a large window directly behind the camera lighting the scene.

To start things off I needed a single image of the scene without any of the flying objects in it. This image would be the base I would use to later mask out anything I didn’t want (namely, me holding her). I used a spare outtake shot of one of the stuffed animals that was nowhere near my scene as my base.


Next set of images were of me holding her over her crib in various positions. Luckily she’s a really good sport about it, and a lot of tickling and kisses between takes didn’t hurt (hint: most models do not take kindly to this, use caution).

Multiple takes were done in order to have the highest chance of a good image of her, and to give me multiple textures to use in post later to assist in masking me out of the image. The trick is to pre-visualize what level of work will be required in post, and to accommodate that when shooting.

For instance, I knew it would be a pain to clean up the edges around her clothing where I was holding her later, so I tried to minimize my hands and arms obscuring her too much.


The rest of the images were quite easy - throw stuffed animal into frame, and fire! Rinse, repeat as necessary (again, multiple shots really pays off here - each animal probably had about 8 or so images made).

The trick to making life easier in post is to make sure that the lighting and exposure is controlled to be as consistent as possible between shots - you really want everything lit with a consistent power and direction.

Post Processing

This is really where the vision begins to come together for me. I’ll usually fire up my image editor (GIMP in my case, PS for those of you with a little extra cash), and set my first image of just the background environment as my base layer.

This first image with nothing on it becomes the background against which I will begin masking out objects I do not want from subsequent layers. I loaded up each of my other shots as layers in the image to get a rough idea of placement within the scene (some stuffed animals would overlap each other in some shots - I picked through all the images until I found ones that I liked).

Then I start working on removing myself from the image. With an environment background this is relatively quick to add a layer mask in GIMP and paint over myself on the image to show the base image through in a big, rough way (the only place I slowed down was nearing the edges).


The devil is in the details, they say, and nowhere is this more apparent than when trying to make a clean edge mask from a background.

There really is no quick and easy shortcut to getting good results here - a small radius brush and patience is your friend. Too hard a brush and the edge looks fake immediately, too soft a touch and the edge looks fuzzy and fake immediately. Somewhere in between is a happy medium, and that’s what I was aiming for.


Luckily, I remembered to take multiple shots, so in places where the edges were not cleaning up as well as I would have liked I “borrowed” portions of the other shots to make the edge cleaner (the side of her body by the bib is from another shot, as is her sleeve). When working on edges like this it really does pay off to have multiple takes to draw from!


Once I had blocked myself out of the image, I continued the process by adding layer masks to each of the stuffed animals, and painting them back into the visible image (by modifying the layer masks). No overlapping animals made this a bit easier, but you’ll notice that something key is missing from this version of the image.

Shadows!

That whole devil and details thing again. The trick now was only to create some fake shadows for Beverly and her animals that didn’t have shadows (the doll at top left already had one).


The shadows are key in lending a sense of realism to the final product. They were made by simply approximating the shape of the shadow, filling with an appropriate shadow color (sampled from other shadows on the back wall), and blurring to taste. After that I just adjusted opacity by eye until it all seemed reasonably well blended.

Overall I was happy with how this image turned out, and it really was fun creating it (despite what looks like a lot of tedious work). I’ve since done others along a similar vein, but this first one still makes me smile when I look at it...

1991

You: “I’d like to install a file server for the LAN – can I have the root password for the server, please”
Admin: “You’re kidding, right? Submit a ticket, we’ll install it when we get around to it”
crickets

1996

You: “I installed a Samba file server for the LAN on my own Linux machine”
Admin: “Gah! You messed up my workgroup. What happens when you turn it off? Bloody amateurs…”

2000

You: “I’d like to install a bug tracker for the dev team”
Admin: “The existing servers are overloaded – you’ll need a hardware req. Lodge a ticket, and get management approval first.”

2005

You: “I’d like to install a bug tracker for the dev team”
Admin: “I’ll create a VM for you to use. Lodge a ticket”

2013

You: “I’d like to install a bug tracker for the dev team”
Admin: “You have a self-service account on OpenStack, don’t you? What are you talking to me for?”

 

A week or two ago I was the guest of Volkswagen, in their hometown of Wolfsburg. They had asked me to lecture on in‑house software projects, friction and usability. Great question, could fill many an hour answering it. With one hour at my disposal, I picked one main aspect. Here we go.

the fashion trade

Usually I design interaction for software products; off‐the‐peg software so to say: desktop applications, in browsers, and since 1997 also mobile. A recent twist are services, for instance social networks or B2B websites.

A quite different world is that of software projects; bespoke software, made to measure for clients and—hopefully—its users too. Comparing software products and projects, there is remarkable effect that I want to address in this blog post.

slidin’ down

Below we see from left to right a continuum of software specialisation: from general (email, web surfing), via specialised (software for doctors, or engineers) to bespoke projects. Plotted against that is their usability, in general:

I have blogged before about this ‘armpit of usability,’ its cause and effect. Today I will go into why software projects are located at its smelliest end. For this, we need to take a look at the three worlds that collide in software projects, what they need, and offer.

clients

The first world we will take a look at is that of clients. This is logical because it is clients who instigate software projects (there are also illogical ways to start a software project—e.g. have to spend the budget before year’s end, ask supplier how—but I will disregard these).

A first client need in software projects is to get ‘it’ built; ‘finished and working.’ This alone is already a cause of many a conflict in software projects. I will show later how to get a much better handle on this issue.

people, get moving

Another client need in software projects is to save money. At least, it used to be in the past decades, when software automated a lot of mechanical, brain‐dead labour, especially in office environments. Additionally, looking at a software project in this way is very spreadsheet‐friendly. The temptation of this should not be underestimated.

But time has moved on and just about all mechanical jobs have been rationalised away. What remains is creating value. This is exactly what people do: deal with situations with flexibility, provide a human touch to communication, solve issues and create new ways to do things. Machines and software do not stand a chance there. Over the years I have made this value creation the core of my design praxis.

intermezzo: what about value?

Let’s take a short detour and see some examples of value creation. We start with a plain project description:

‘We need a new order‐taking system.’

Then we ask where the value is:

‘We need a new order‐taking system, tightly integrated with manufacturing and warehouse operations.’

No, that is not it. That is still a very mechanical description of what needs to be achieved. Try again:

‘We need a new order‐taking system that allows users to unbureaucratically engage with any customer wish.’

There we have it: value. Feels really different than the previous two, doesn’t it? Introducing software that realises this will be of clear competitive advantage to this client.

‘We need a new order‐taking system that allows users to be order makers, instead of order takers.’

Another statement with value; not better, not worse, just different. This demonstrates that defining value is a strategic choice for clients.

Flesh out the two statements above to three paragraphs, answering ‘what is it we are making, who is it for and where is the value?’ and you have what I call a vision. And vision is exactly what I expect from management and leadership in a software project.

back on track

Where were we? Ah, value is definitely a client need in a software project. And by formulating that in a vision statement we have moved to the first thing clients have to offer.

We did already see that clients offer that software projects exists at all. And therefore they have to offer funding, because projects without funding turn out to be sad affairs, in my experience.

tech

The second world that we will take a look at is that of technology, i.e. the in‑house IT department or the external suppliers. All engineers, developers, technical architects, DBAs and functional analysts are part of this world.

Cut to the bone, the sole reason these in‑house IT departments and external suppliers exist is to hoover up those software projects and budgets that clients have to offer. It is their first, and prime, need. This is a marked difference with the world of software products, where technology departments are achievement‐focussed.

XOR

The second need the tech world has is that of clarity. From the zero/one definition of a bit upwards, in black and white terms. What needs to be built and when can we call it finished? This is compounded by the need of the tech world to frame and communicate everything in technical terms.

As such, the tech world is completely at ease working from the statement we have seen before:

‘We need a new order‐taking system, tightly integrated with manufacturing and warehouse operations.’

Given enough time and budget, they can bring this to a good end by themselves. But they are completely lost with the value part in this statement:

‘We need a new order‐taking system that allows users to unbureaucratically engage with any customer wish.’

Yes, the sales types of the tech world will nod understandingly when clients express the value they need. But when the actual work starts, their colleagues will hem and haw until the statement is reduced to something like the first one, i.e. technically precise, but without value.

truly, always

What the tech world has to offer is the engineering and building of software. Everyone knows that in order to get software, it needs to get built, i.e. code developed. The brutal reality of software making is that everything else I describe in this blog post is perceived by clients as optional, even down to the proper engineering part: ‘just bang some code together.’

The tech world expertly plays this ‘you need to get it built’ card. They play it to get (just about) all of the available budget, and to bury deep under the ground anything they don’t ‘feel’ like doing.

users

The last world that we will take a look at is that of users. And here the circle closes, because what users have to offer is value creation. We can now see what software is:

It is a means of value transport, provided by the client and built by technology. The software is there to meet its users, pick up the value they create and bring it back to the client:

But to pick up that value, the users will have to get on the bus. Paying them is not enough, neither is a direct order. These will make them endure the software, but they will not even consider getting on the value bus.

How do you entice users to get on the bus? You do it by observing the needs of these users and addressing them in the software. What are these user needs? Well, that is exactly the question the IT industry has been struggling with for the last 50 years.

Morse code

What happens traditionally in software projects is that (indirectly) the three worlds—client, tech and users—sit down to discuss what users need. It is literally three different worlds meeting, three different cultures, speaking three different languages:

You can see that the intersection of all three is very small. It has a name: discussing features. Features, features, ever more features. A very human phenomenon is feature hoarding. Just like kids and toys, there can never be less features. No, that is a regression.

Everything gets phrased as a feature request—the only means of communication available. Often users are asking that an existing feature gets improved (e.g. finally made findable, or usable), but it gets phrased as an additional feature.

gimme some dough

Features are a commodity, think staple foods like rice, corn and wheat. Sure, not enough and users will starve. But increase supply beyond enough and you have glut. In real life, people’s attention turns to better food when they have enough. In the software world, the need for a better meal is answered by a huge buffet of mediocre food.

The biggest mistake the software industry makes is listening to these feature requests and supply what users want. This is the prime reason supposedly tailor‐made project software ends up being the armpit of usability. Remember, the goal was to find out what users need. There is a solution for this, it is called usability.

intermezzo: what about usability?

Another detour. There are two definitions for the word usability that you have to know:

1. Measure of how usable, i.e. fit for use, something is. It is qualitative; this makes the tech world nervous because there is no hard numbers.
2. A group of empirical professionals who measure usability and survey user needs. Their general background is psychology. Tech‐splanation: they are specialised in this type of hardware called humans.

This is incredibly useful. Usability professionals can be engaged to deliver an exact map of a software project users’ needs and measure whether software is actually fit for use. The effort and cost of this scales with the size of the project. In general it is peanuts compared to what development hoovers up.

back on track

Where were we? Ah, knowing users’ needs is fully within reach, a question of just do it. Now we need one more thing. We need to connect the world of clients, technology and users; to translate between them and hook up the needs and offers. There is a solution for that, it is called interaction design.

That is what I do as interaction architect. It involves making the plan for the bus. For clients I realise the value transfer; for tech I make clear what needs to be built; for users I ensure their needs are met.

To show how this works I will now present my recommendations for software projects, in nine easy steps:

1. you got to have a vision

Before kicking off a project, even getting that budget, why not make it crystal clear what value is going to be created and formulate a project vision? I help my customers all the time to discuss, clarify, reach consensus and formulate one; this fits nicely in a one‐day workshop.

It serves as a first feasibility check, getting a convincing vision together. And it can be immediately used to ‘sell’ the project internally and get a modest budget for the next steps. Costs involved? One–two man‐days for the workshop.

2. start with user needs

Right here, at the very beginning of the project, is the right moment to get the user needs mapped out. These are already a useful foundation for strategic platform—desktop, browser, tablet and/or smartphone?—and architectural decisions. Why take these without knowing what is needed?

Usability specialists survey and observe your project’s users and bring back the facts. As mentioned, you are still not spending any serious money at this point.

3. integrate usability + interaction

Now is the time to integrate usability and interaction design with your project. This does not happen by itself. The software industry has the tendency to bolt on interaction design somewhere at the bottom of the development pyramid and stick usability research in a drawer. Sorry, but that is not going to help you.

Usability professionals are the only objective partners a client has for knowing what users need and if the software is really working. The interaction architect is the partner for realising your project vision of value creation. Processes will have to change too; you cannot make software like you did ‘last time’ when the results should really not be like last time.

4. design it first

With your vision, user needs and platform choices known, the largest open question of the project—what do we need to build?—can be answered. A first, rough design of the user interaction can be made by an interaction architect (‑team for larger projects).

This will include a solutions model: a large‐scale solution for realising that value creation, plus a design strategy for working out the complete software in detail. This will take the whole project out of the dark, into the light.

It is a good idea to have your prospective tech partners on board during this design stage as discussion partners. Technical feasibility has a profound impact on interaction design. And vice versa: interaction design has the same profound impact on the architecture and design of back‑ends.

5. test it first

Yes, not a line of code needs to be written to find out if the interaction design is meeting your users’ needs—and by extension, if the goals you set for value creation are fulfilled. A usability test with your users can be performed with a paper prototype. I have seen many of these and they simply work.

These tests are practical, quick and lightweight, involving six users, maybe up to twelve if your user group is very heterogeneous. Anything beyond that is project bloat, making it less agile. If you do insist on having it tested on a real computer/tablet/mobile screen, then a prototype can be made. This should take three days, not weeks or longer.

6. refine + test again

The reason we made a rough design in step 4 and performed practical, lightweight testing in step 5 is that we are going to iterate. From the analysis of the tests the interaction architect keeps the parts of the design that work well and redesigns the parts that performed badly.

These changes can be sweeping, because up to now relatively little time, budget and commitment have been invested.

Then it is time for another round of usability testing and it will show that giant step have been taken towards a fully working interaction design. If still any big issues are found, then repeat this step of refinement and test.

7. make interaction spec part of the contract

You still have not spent any serious money up to now. You do have a refined interaction design specification that shows what has to be built. It has been tested to fulfil your users’ needs and to realise your vision of value creation.

Now is the time to take this specification to your tech partners, the in‑house IT department or the external suppliers, and ask for a quote. It will be much easier to provide an estimate on this basis and it will be more accurate. You will also be able to define much better contractually what ‘finished and working’ means.

8. test + test

That’s two different tests. The first one is the usual, functional testing of what is being built. Doing this against the interaction design specification ensures that you get exactly what you expected. Passing these test gives the tech partners an exact moment to call it finished.

The second type of testing is usability testing of alpha versions of the built software. It checks for more subtle usability issues and validates the overall interaction design. Again the interaction architect resolves the issues and refines the design. The project impact of this is low, because all the bigger issues were dealt with before development started.

9. agile? interaction architect is co‑owner

Agile development was invented in + for the world of software projects. Working agile does not change much of the eight steps above. In step 4 one certainly needs to get to a solutions model, to knock the project into shape.

More detailed interaction design can be postponed, to be delivered just‐in‐time for the start of an implementation sprint. Usability tests are performed on the evolving software, as described in step 8.

In the piecemeal work that agile entails, it is very easy to lose track of a coherent user experience, one that meets your users’ needs. Making the interaction architect software co‑owner in the agile process, highly involved in planning of the next sprint and further sprints, solves that.

postscript

And that’s it. I have shown that it is fully possible to set up software projects where the needs of all the parties involved are met. The clients’ need to get it built and for value creation; the tech worlds’ need for clarity on what needs to be built and of when it can be called finished.

Last, it is straightforward to find out what software users’ needs are and to meet them through interaction design. At that point you can build the value bus, one that users are pleased to take, to bring their value home:

bus symbol from openclipart.org

Cycles SSS, 3D Print tools, GPU based Image color conversions, and lots more! Help us testing it.

For those who impatient about the upcoming release, we providing a testing linux binaries! Please test and feedback!...

You can now pre-order a video/DVD training to learn Blender modeling and the new 3D Printing Tools...

I've started to prototype and lay the foundations for the indicators to use the Upstart User Sessions. It's an exciting change to our desktop foundations, and while it's still very fresh, I think it's important to start understanding what it can do for us. For right now you're going to need a patch to Unity and a patch to indicator-network to even get anything working, not recommended for trying at home.

Previously for indicators the way that they've worked is that a small loadable module was loaded by the panel service that had indicator specific UI in it. That plugin also took care of the responsibility to restart the indicator backend, respawning it if it crashed. While this works and it has created a robust desktop (most people don't notice when their indicator backends crash) it has had some downsides. For one, it makes it difficult to build and test new backends as you pretty much have to restart Unity to stop the previous service from getting respawned. Also all the debugging messages end up coming under the DBus process in ~/.xsession-errors because we were using DBus activation to start them.

With upstart user sessions we're now getting a lot more power and flexibility in managing the jobs in the user session, it makes sense that indicators would start to use it to control the backend services. This comes with a set of advantages.

The first one is that there is better developer control of the state of the process. It's really easy to start and stop the service:

$ stop indicator-network
$ start indicator-network

and the ever exciting:

$ restart indicator-network

All of these ensure that the same commands are run each time in a recreatable way. Plus give the user and/or developer full control.

Upstart also takes the output of each process and puts it into its own log file. So for our example here there is a ~/.cache/upstart/indicator-network.log that contains all of the junk that the backend spits out. While this is nice to just make xsession-errors cleaner, it also means that we can have a really nice apport-hook to pick up that file. Hopefully this will lead to easier debugging of every indicator backend bug because they'll have more focused information on what the issue is. You can also file general bugs with ubuntu-bug indicator-network and get that same information attached.

In the future we'll also be able to do fine tuned job control using external events. So we could have the indicator network backend not start if you don't have any networking devices, but startup as soon as you plug in that USB cellular modem. We're not there yet, but I'm excited that we'll be able to reduce the memory and CPU footprint on devices that don't have all the features of higher end devices, scaling as the features are required.

Those that know me know that I love diagrams and visualizations, and so I'll have to real quickly say that I'm excited about being able to map our desktop startup using intlctl2dot. This gives a Graphviz visualization of startup and how things will interact. I expect this to be a critical debugging tool in the future.

What's next? Getting all the indicators over to the branch new Saucy world. We also want to get application indicators using a similar scheme and get a fast responsive desktop. Hope to have a blog post or two on that in the near future.

Here are quite unexpected and extremely rough drafts of the main antagonist in Morevna’s story.

First, thanks for everyone that contributed ICC profiles. I’ve received over 800 uploads in a little under 24 hours, so I’m very grateful.

TLDR:

Total profiles scanned: 800
Profiles with invalid or unlikely primaries: 45
EDIDs are valid 94.4% of the time

This resulted in the following commit to colord:

commit 87be4ed4411ca90b00509a42e64db3aa7d6dba5c
Author: Richard Hughes <richard@hughsie.com>
Date:   Wed Apr 24 21:47:14 2013 +0100
    Do not automatically add EDID profiles with warnings to devices

I’ll explain a little about what these numbers and the commit means. The EDID reports three primaries, i.e. what real world XYZ color red, green and blue map to. It also tells us the whitepoint of the display. From basic color science we know that

• If R=G=B, we should be displaying a black/gray/white color without significant amounts of red green and blue showing
• The reported gamut of colors should not be bigger on real hardware than theoretical archive spaces like ProPhotoRGB.
• If R=G=B=100%, then we should have a good approximation of D50 white
• The temperature of the display should not be too cold (>3000K) or too warm (<10000K).

There are actually 11 checks colord now does on RGB profiles, similar to the checks done above. If any of the 11 checks fail, the automatically generated profile is not used. The user can still add it manually if they want and then of course it will be used for the monitor, but we don’t break things by default for 5.6% of users.

If anyone is interested, the results were generated by this program, and the raw results are available here. My personal take-home messages you can take from this file are:

• Sometimes blue and green are the wrong way around (Samsung SyncMaster)
• Vendors need to use something other than random binary data (AU Optronics)
• If you don’t know what a whitepoint is, don’t try and guess (Sharp and Lenovo YT07)
• Projectors generally don’t really know/care what values to use (OPTi PK301 and In Focus Systems)

There’ll be a new colord release with this feature released in the next couple of weeks.

Download the Video! (26:07 49.7MB)

In the last Episode I looked under the hood of JP(E)G and PNG. This time it gets a bit more practical – which is better for what?

I tackle two examples from the GIMP Magazine web site and test, if they would be better saved as JPG or PNG. The Plugin “Save for Web” is really usefull for this task.(The image for this blog entry is a PNG by the way, showing JPG compression artifacts. As a JPG it would be five times the size. )

I “developed” a method for comparing two layers – just set the top layer mode to “difference”, make a new layer from visible and check that with the threshold tool for pixels, that are not completely black. After locating the problematic zones in an image with this tool, one can decide what settings are “good enough”.

Conclusion: It depends. It depends on the file, your use case, your level of “good enough” and your compassion for people on a mobile device in EDGE-Hell.

The show starts with a little extension of the last show, Pascal mentioned some options for saving a JPG file that I had overlooked.

The TOC

00:00:00 Start of video
00:01:00 Progressive mode in JPEG
00:04:09 Progressive mode is not fully supported by browsers
00:04:23 Optimized mode
00:05:56 Baseline?
00:06:17 The quality setting
00:07:09 GIMPMagazine and MTG header image – PNG or JPG?
00:09:23 Checking for quality loss in JPG
00:10:03 Comparing two layers with difference mode
00:10:48 Using the histogram for analysis of the amount of difference
00:11:25 Locating the differences
00:13:50 Trying 85, 75 and 90 as quality settings
00:16:13 When in doubt, compare different settings
00:16:36 Save your work as XCF.GZ
00:17:12 Second example – a drawing
00:19:56 Conclusion
00:23:19 Stay at 4:4:4 for subsampling with photos
00:25:16 Final words of wisdom
00:26:07 End of video

Meet the GIMP Video Podcast by Rolf Steinort is licensed under a Creative Commons Attribution 3.0 Unported License.
Permissions beyond the scope of this license may be available at http://meetthegimp.org.

A favour, my geeky friends:

gnome-settings-daemon and colord-kde create an ICC profile based on the color information found in the EDID blob. Sometimes the EDID data returns junk, and so the profile is also junk. This can do weird things to color managed applications. I’m trying to find a heuristic for when to automatically suppress the profile creation for bad EDIDs, such as the red primary being where blue belongs and that kind of thing. To do this, I need data. If you could run this command, I’d be very grateful.

for f in $HOME/.local/share/icc/edid-* ; do
    curl -i -F upload=@$f http://www.hughski.com/profile-store.php
done

This uploads the auto-EDID profile to my webserver. There is no way I can trace this data back to any particular user, and no identifiable data is stored in the profile other than the MD5 of the EDID blob. I’ll be sharing the processed data when I’ve got enough uploads. If you think that your EDID profile is wrong then I’d really appreciate you also emailing me with the “Location:” output from CURL, although this is completely optional. Thanks!

Crossposted from Questioncopyright.org

 

The splash screen contest is over and results are announced now!...

In my previous post for the Open Source Portrait (Postprocessing), I had mentioned during the skin retouching in GIMP section that there was a method that I had used in the past for helping to make skin imperfections visible for healing.


It is a similar method described by Calvin Hollywood (again), that he calls "Check Layers". He explains what they are and how he uses them in the video below:


If you don't want to watch the video, the basic idea came about from my experience when converting images to B&W. That is, the Blue channel of a color image is not flattering at all for skin (unless you have flawless skin). Conversely, the Red channel usually has very pretty skin tones (and hence it's common to overlay a Red channel on your image and set it to Overlay blend mode to enhance this).

What Calvin Hollywood shows in his video is using a Photoshop adjustment layer to turn the image into grayscale, and to turn down the contribution from the Red channel, while increasing the Blue channel. This results in a more contrasty image that favors the blue channels, and will make skin imperfections much more visible.

The problem is that we don't have adjustment layers in GIMP...

The Solution

Well, I had to play around a bit to get things working, but I finally got there.

The trick was to remember that I wanted a view of the Blue channel, in monochrome, and in a way that any touchups I did to the base image would be instantly reflected in my grayscale Blue channel view.

Here's how to do it (manually, I have also written a script-fu you can download to do this automatically - see below):


When I'm done adding layers, this is what my layer palette would look like:


I can now work with a healing/clone brush on my base layer, and I'll see the changes reflected in real time on my canvas in GIMP.

If I want to see the progress of my work on the full color image, I can use a simple shortcut: Shift-Click (⌘-Click) on the base layer visibility to isolate it as the only visible layer, and again to turn all layers back on.

Here is a quick video of me walking through using this method:


A nice bonus to this method is that it will also work above a set of Wavelet Decompose scales, meaning you can use a normal wavelet workflow, and still use this "Check Layer" to get a view of what you're doing against the Blue channel.

Finally, it can be tedious to create all of these layers manually each time you want to use it, so I've written a Script-Fu to automate it. You can find it at registry.gimp.org:

Are you a student? Google might sponsor you for a cool coding job on Blender this summer....

In GNOME 3.10 we’ll have translated ICC profiles thanks to all the translators. This should make Alexandre Prokoudine happy indeed.

For applications, libcolord provides a CdIcc GObject if you don’t feel like dealing with wchar_t‘s and ‘mluc‘ objects yourself. Applications that deal with ICC profiles and want to get the localized versions of the description should probably look at this example code in C or in Python.

Comments, as always, welcome.

• Dmitry Orlov summarizes Mats Alvesson and André Spicer's A Stupidity-Based Theory of Organizations. A good afternoon read with lots of food for thought.

  Functional stupidity is organizationally-supported lack of reflexivity, substantive reasoning, and justification. It entails a refusal to use intellectual resources outside a narrow and “safe” terrain. It can provide a sense of certainty that allows organizations to function smoothly. This can save the organization and its members from the frictions provoked by doubt and reflection. Functional stupidity contributes to maintaining and strengthening organizational order. It can also motivate people, help them to cultivate their careers, and subordinate them to socially acceptable forms of management and leadership. Such positive outcomes can further reinforce functional stupidity.

• Have you donated to Yorba's crowdfunding campaign to develop Geary, a new, free software email client? I have.

  As the Yorba people explained in their last keynote at GUADEC, they have been working on experimenting with funding models for free software. This crowdfunding campaign is the latest experiment, and I urge you to participate. Give them a little money. You just can't have people writing software full-time without them also having a way to make a living, and this crowdfunding campaign is the way they intend to make their living while they write the first versions of Geary.

  Is this undermining Evolution? I don't think so. Evolution is relatively old software. It is really good, and also pretty bad at times — the results of lots of technical debt. Normally I would say, Yorba is crazy for writing an email client from scratch, and they should just give their love to Evolution. But they have proven themselves to be competent to write something like Shotwell, the photo manager I use every day, so this is good evidence that they can write Geary.

  So, go to Yorba's crowdfunding campaign page and donate to Geary!

Ben Simonds, a well respected Blender user and co-director of Gecko Amimation Ltd, has written and excellent new book. Blender Master Class, published by No Starch Press.

from No Starch Press:

Blender is a powerful and free 3D graphics tool used by artists and designers worldwide. But even experienced designers can find it challenging to turn an idea into a polished piece.

For those who have struggled to create professional-quality projects in Blender, author Ben Simonds offers this peek inside his studio. You’ll learn how to create 3D models as you explore the creative process that he uses to model three example projects: a muscular bat creature, a futuristic robotic spider, and ancient temple ruins. Along the way, you’ll master the Blender interface and learn how to create and refine your own models.

You’ll also learn how to:

• Work with reference and concept art in Blender and GIMP to make starting projects easier
• Block in models with simple geometry and build up more complex forms
• Use Blender’s powerful sculpting brushes to create detailed organic models
• Paint textures with Blender and GIMP and map them onto your 3D artwork
• Light, render, and composite your models to create striking images

Each chapter walks you through a piece of the modeling process and offers detailed explanations of the tools and concepts used. Filled with full-color artwork and real-world tips,Blender Master Class gives you the foundation you need to create your own stunning masterpieces.

DVD includes files for each project in the book, as well as extra textures, brushes, and other resources.

Covers Blender 2.6x

A number of excellent reviews of Ben’s book have been written and are well worth checking out. Although everyone has a somewhat unique perspective, the general consensus is that Ben’s book is a huge success and a must have for any serious Blender user.

Reviews of Blender Master Class

Adventures in Blender

Blender Cookie

Reyn’s Blog

As of right now (April 17 at 12:00 midnight UTC) the Fedora 19 Supplemental Wallpaper Election is open to all Fedora account holders who have signed the Fedora Project Contributor Agreement and are an approved member of at least one non-cla group. (So no, you can’t sign up for an account today and vote. )

We have 52 gorgeous and openly-licensed contributions from the Fedora community. The top 16 – ranked according to your votes – will be included in Fedora 19 as supplemental wallpapers. What are supplemental wallpapers? They are wallpapers that we package and ship with the release that users can choose from if they decide not to use the default wallpaper (the latter is created collaboratively by the Fedora Design Team.)

This election will be open for three days only, and will close at 11:59 PM UTC on this Friday, April 19th. So don’t wait – if you’d like a say in which wallpapers we include in Fedora 19, go ahead and vote now!

We’re using the Fedora voting system for this election; it’s not ideally suited to such an election (it can’t display images inline where you rank each wallpaper) so we are recommending the following workflow for this election:

1. Scope out all of the wallpapers. There are 52 wallpapers. View them all on the wiki submissions page and note your favorites in order.
2. Log into the election app. Visit the F19 supplemental wallpaper election page and log in using your Fedora account credentials by clicking on the ‘Log In’ button in the upper right. Then, click on the ‘Vote Now’ link at the bottom of the list of wallpapers.
3. Rank the wallpapers and submit your vote! The higher the rank you give a wallpaper, the more likely it is to win. There are 52 submissions, so one thing you can do to save yourself time in the voting process is to rank your favorite 16.

Here’s just a tiny sampling of some of the submissions we’ve received:

Vote Now!

Major props to gnokii and Toshio for planning and setting up this election for us!

I’m just back home from the Libre Graphics Meeting 2013, which was once again awesome!
It happened in Madrid this time, at the Medialab-Prado.

There were a lot of interesting talks and workshops, mixing coder and artistic topics.
All kinds of graphics-related activities were represented, including image manipulation, typography, illustration, animation, design, and more.
The Krita team was well represented with Boudewijn Rempt who presented the new Krita Foundation, David Revoy who made a workshop showing his painting workflow on Krita, Ramon Miranda who presented his DVD project, and me who made both a workshop and a talk to present Krita Sketch.

My workshop was a little hard to follow for several reasons: people had to compile Krita Sketch for linux as there aren’t any linux packages yet, which was already quite tricky, but then even more as the network there was way too slow for this big event…
Same for windows users, as the installer file which took a long time to download ended being corrupted.
So at around half of the workshop I switched to Krita desktop, and made people install it as it was easier.
The good thing in this at least is that then people already had the software installed to follow David’s workshop the next day.

In my talk I presented quickly the story behind the Krita Sketch project, and shown the new dark-neutral-grey interface theme that replaced the colorful previous interface for next version release (it’s already pushed in Krita sketch git branch, if you want to test it…)

It was very cool to meet more people from the Synfig team this time, with Carlos Lopez (the main coder), Konstantin Dmitriev (Morevna project), and a few other users.
We could have a great brainstorming workshop together to look at how Synfig can be improved, both in terms of usability and new features. Awesome things to come!

Also about animation, the main coder from Tupi, Gustav Gonzalez could come for the first time at LGM to present his software and discuss with other coders and users to gather ideas to improve it (including some features collaborating with Krita..). Again, promising!

Many cool people were there: the Gimp team (many thanks to them for the great party on Friday night ), the Libre-Graphics-Magazine team with a nice new 2.1 release, some people from Mypaint, Scribus, Inkscape and Libre-office teams.

Also several independants and smaller projects were present, like Tom Lechner with his always-more-crazy Laidout software, Camille Bissuel and Cedric Gémy from the to-come project of node-based image editor Mikado, PyCessing, Claudia Krummenacher who raised some interesting questions about print vs ebook and liquid layout, Dave Crossland and Ben Martin showing the great new more-than-welcome improvments of FontForge, Jakub Steiner who made an interesting use of Blender for a 2D animation work, Tavmjong Bah who presented the future of SVG features, the Piksels and lines orchestra who made a fun performance using libre graphics software to produce pictures and sound, and many, many others…
Sorry to not mention everyone, the list is too long (there were 65 talks/workshops this year, not counting all the open-podium lighting talks).

I’m very happy to can have been there this year again, so much thanks to KDE e.V. who supported me for this event!
And of course again so much thanks to Femke Snelting and the Medialab-prado team who made an awesome work organizing this event.

Photos above from Carlos Lopez and David Revoy‘s albums ; More photos of the event HERE and HERE.

The links for the gap between #190 and #191. I accept suggestions under info@meetthegimp.org. Even blatant plugging of your own stuff, if I like it.

The competition isn’t sleeping. And the sound will get better soon! Short and on the point – exactly where I suck.

A link to a German site (from Bremen! ) with more quick tutorials. Get more Drama into shots with sky in them in 3 minutes.

Monitors for Photography – A Primer from On Taking Pictures.

An academic paper about Noise, Dynamic Range and Bit Depth in Digital SLRs. Looks interesting and is here also as a bookmark for me.

Darktable, the RAW converter and management program, has released a new version, 1.2. Cool stuff about camera specific noise and much much more! And they seem to get masks …..

Do you have a scanner, paper documents to process and run Linux? Then Konrad Voelkel has something for you: “After having bought a new flatbed scanner, I re-investigated how to scan and OCR pdfs, how to produce DJVU files that are incredibly small and how to get metadata right. It turns out what I really ever wanted was to create PDF/A compliant documents (I just didn’t know what PDF/A was before). But let me explain the details after presenting you the quick solution. At the end, I have a shell script that scans directly to PDF/A.”

The Rule Of Thirds on Steroids – Alfred Eisenstaed’s compositional system in an analysis of some of his images and a Degas painting. I am not sure if this is over-analysed or not, but it’s an interesting read.

My income is in the top 1%! Where are you on the Global Rich List?

Not a lake. Look at the “beach” on the left side.

What are we taking photos of? A survey of questionable statistical value but from an interesting site for teachers. Perhaps Germans include more under “random stuff” than other people…..

GIMP is now a Professional Photo Editing Software, available in a bundle with Blender and much more for only GBP 2.89 or US $4.37. Whow. Or better not, it’s free on other sites.

This is an animation we made for a project by Espaço Projetos. See also still images and the storyboard. All was made with blender and rendered with the internal engine...

I realized how important storyboard were when I saw David Revoy's amazing work on the Tears of Steel movie. Until then I hadn't realized this was something actually doable, draw the whole movie before doing the 3D. I discovered it is not only perfectly doable, but also incredibly useful. This is the storyboard we did for...

The Past

My first ever libre software gettogether was GIMPCon in 2000. The location at the CCC gave it the proper underground vibe. That gathering later became what is now Libre Graphics Meeting when the GIMP and Scribus folks thought there’s some possible synergy to benefit from.

The future

It may sound like a little blasphemy for a GNOME person to say LGM is my favorite conference. I dig GUADEC for its mix of developer and user oriented talks and workshops, but at LGM this synergy seems to be working even better. There’s probably a trend towards attracting more designers than engineers, and I don’t know of a tech conference where there’s pretty much 50:50 gender mix (perhaps in Madrid there were more women than men even).

I want more conferences or gettogethers like this. Feedback from an animator struggling to finish a task is million times more valuable than online polls asking for a feature that exists in other tools. Small community projects struggle greatly with focus and motivation. These user

developer sessions should not mean folding every single suggestion into Inkscape feature and SVG spec, but seeing tools used is the best we have for user testing.

There were some humorous mailing list like moments too (I hope video archives will be posted, the sessions were recorded). We had a nice example of miscommunication between Boudewijn and Mitch during the GIMP Q&A, but there is room to turn that “but printing spot colors is way more expensive than CMYK, stop ignoring your users” to “it’s the actual workflow, retaining control over individual channels during the process, that makes CMYK a subset of stop color process, the output/print process remains the same.” when talking off a mailing list. People sometimes need to talk face to face to turn those faster horses into cars. I have lost all faith in non-technical or controversial topics ever resolved on a mailing list.

Workshops

I also really enjoyed the “get your hands dirty” sessions such as David Revoy‘s Krita speedpaint workshop that are the carrot-at-the-end-of-the-stick for potential new designers giving libre graphic toolchain a go. Seeing amazing art created with our tools is an amazing motivator that allows to overcome some bumps on the way and actually find strength to find unfamiliar solutions or actually bite the lip and start the dialog with the developers (it’s harder than you think). I don’t think my painting skills will improve any time soon, but the workshop did expose a significant omission from the Wacom settings for non-screen tablet users. It felt the Krita developers are on a good course working closely with David to shape the tool and getting amazing promotion and an actual product in return, in a similar way the open movie projects dramatically improved the quality of Blender.

Type

A significant number of talks related to type. Ben Martin and Dave Crossland presented the collaboration features of the new Font Forge. This sounded really intriguing for me, because a lot of the design process is tedious and horrible and things like metrics are a torture that I found much more bearable when we did it with Patrys the other day.

Ana and Ricardo made me feel guilty about never finishing or publishing some of my fonts, because I felt they are too raw but then never gotten to finish them. They mentioned their new foundry and some utilities like the autospacer, giving you a template workflow rather than starting from the dangerous and feared blank slate.

If you ever needed some hand holding for designing your own type, Dave pointed out an extremely nice guide to me.

Getting Started

I gave a short talk on the work we did on Getting Started, but in an expected way was dragged away before I could show some guts of the project. As there’s been interest to see behind the scenes more, I’ll try to blow the dust off the design team youtube channel and do a screencast.

LGM Rocks

I really had a blast seeing everyone again, and came back with a list of things to do and also the energy to do so. Big thanks to the organizers and in particular the GIMP folks for their continuous support of the event.

Hola! We understand that the published character template is pretty much unuseful without a tutorial. So, here I’m publishing a screencast recorded from my workshop at LGM.

You can download the full tutorial in ogg-theora format here: http://archive.org/details/SynfigCharacterTemplateTutorial

Enjoy!

We've been considering the possibility of moving out of the Bay Area to somewhere less crowded, somewhere in the desert southwest we so love to visit. But that also means moving to somewhere with much harsher weather.

How harsh? It's pretty easy to search for a specific location and get average temperatures. But what if I want to make a table to compare several different locations? I couldn't find any site that made that easy.

No problem, I say. Surely there's a Python library, I say. Well, no, as it turns out. There are Python APIs to get the current weather anywhere; but if you want historical weather data, or weather data averaged over many years, you're out of luck.

NOAA purports to have historical climate data, but the only dataset I found was spotty and hard to use. There's an FTP site containing directories by year; inside are gzipped files with names like 723710-03162-2012.op.gz. The first two numbers are station numbers, and there's a file at the top level called ish-history.txt with a list of the station codes and corresponding numbers. Not obvious!

Once you figure out the station codes, the files themselves are easy to parse, with lines like

STN--- WBAN   YEARMODA    TEMP       DEWP      SLP        STP       VISIB      WDSP     MXSPD   GUST    MAX     MIN   PRCP   SNDP   FRSHTT
724945 23293  20120101    49.5 24    38.8 24  1021.1 24  1019.5 24    9.9 24    1.5 24    4.1  999.9    68.0    37.0   0.00G 999.9  000000

Each line represents one day (20120101 is January 1st, 2012), and the codes are explained in another file called GSOD_DESC.txt. For instance, MAX is the daily high temperature, and SNDP is snow depth.

So all I needed was to decode the station names, download the right files and parse them. That took about a day to write (including a lot of time wasted futzing with mysterious incantations for matplotlib).

Little accessibility refresher: I showed it to Dave -- "Neat, look at this, San Jose is the blue pair, Flagstaff is green and Page is red." His reaction: "This makes no sense. They all look the same to me. I have no idea which is which." Oops -- right. Don't use color as your only visual indicator. I knew that, supposedly! So I added markers in different shapes for each site. (I wish somebody would teach that lesson to Google Maps, which uses color as its only indicator on the traffic layer, so it's useless for red-green colorblind people.)

Back to the data -- it turns out NOAA doesn't actually have that much historical data available for download. If you search on most of these locations, you'll find sites that claim to have historical temperatures dating back 50 years or more, sometimes back to the 1800s. But NOAA typically only has files starting at about 2005 or 2006. I don't know where sites are getting this older data, or how reliable it is.

Still, averages since 2006 are still interesting to compare. Here's a run of noaatemps.py KSJC KFLG KSAF KLAM KCEZ KPGA KCNY. It's striking how moderate California weather is compared to any of these inland sites. No surprise there. Another surprise was that Los Alamos, despite its high elevation, has more moderate weather than most of the others -- lower highs, higher lows. I was a bit disappointed at how sparse the site list was -- no site in Moab? Really? So I used Canyonlands Field instead.

Anyway, it's fun for a data junkie to play around with, and it prints data on other weather factors, like precipitation and snowpack, although it doesn't plot them yet. The code is on my GitHub scripts page, under Weather.

Anyone found a better source for historical weather information? I'd love to have something that went back far enough to do some climate research, see what sites are getting warmer, colder, or seeing greater or lesser spreads between their extreme temperatures. The NOAA dataset obviously can't do that, so there must be something else that weather researchers use. Data on other countries would be interesting, too. Is there anything that's available to the public?

Blender Foundation's partnership & bizz network had its final upgrade. Find your freelancers,...

In addition to the basic character template released yesterday, we are publishing another one – it’s Sita from the “Sita Sings the Blues” animated movie by Nina Paley.

Click here to download full package with both characters

The character is traced and rigged by Nikolay Mamashev.

License: CC-Zero 1.0

Enjoy!

As it was promised, today we’re releasing all files for our character template. That’s it – we’re publishing the basic charater for you to play with and reuse. Under the terms of CC-Zero 1.0 license, of course.

Click here to download the latest version

Also, there is a github repository for those who love to clone, fetch and fork. ^__^

To use the template you will need the latest versions of Synfig Studio and Papagayo, which we have updated as well. Please get them at the software page.

But there’s not all. During the last period we worked hard testing the template and end up with more than one character. So we decided to publish them all. That means instead of single sample character you will get a library of characters. Expect more characters to be added in just a few hours.

Workshop

Also, if you remember, today is the day of my workshop at LGM, where I will be explaining how to use this template. Everyone who is planning to participate in the workshop, please working files here.

Please don’t forget to install the latest versions of Synfig Studio and Papagayo (from the software page).

For the people who cannot attend the workshop, I’ll try to record the screencast, combine with the video and publish it online. That surely take some time, but let’s hope that will work out finally.

That’s it, stay tuned!

Download the Video! (36:10 68.8MB)

Download the Companion File! (4.6MB)

The last episode was for absolute beginners, this one is for Geeks. I try to explain (and understand on the way) how images are stored in PNG and JPEG files. PNG (pronounced “PING”) does this lossless, the image can be retrieved in the same quality as the original. PNG works wonders with graphics with a lot of lines and clear colour areas, comics and logos for example, but it creates monster files out of photos and similar images. JPEG looses details, aquires artefacts and generally mangles the image. But it has so beautifully small files and the losses are in most cases invisible – except in the area where PNG is good. So both have their niche to live in.

How is this done? I try to explain this without the math, using analogies, plaing with GIMP to reenact some stages and reducing the complexity a lot. If you want to know the exact facts, read up in Wikipedia, which was also my source of information, or look for other sources. I hope that I never crossed the border between simplification and telling wrong stuff – but I am really not sure. The math is really over my head, last time I had to tackle such a level a Pentax ME Super was still a new camera model. I am happy about any comments that improve my understanding – and all other comments too.

The TOC

00:00:00 Intro
00:02:22 Basics about digital images – pixel, RGB
00:05:25 Storing the colour values in the computer
00:06:24 Palettes for reducing the image size
00:06:50 Run length encoding as simple compression method
00:07:20 PNG, JPG and a WARNING
00:08:44 The PNG format
00:10:12 HexDump and structure of a PNG image
00:13:32 Compression in PNG
00:15:15 PNG is suitable for …
00:16:26 JPG analysed – file structure
00:18:13 First stage: Change the colour model to YCbCr
00:18:54 Decomposing an image to YCbCr in GIMP
00:20:32 Reduce the colours
00:22:20 Testing the concept with GIMP
00:26:17 Splicing into blocks and DCT
00:28:41 quantization
00:29:53 Summary
00:31:20 Testing the compression
00:35:19 Final words
00:36:10 End of video

Meet the GIMP Video Podcast by Rolf Steinort is licensed under a Creative Commons Attribution 3.0 Unported License.
Permissions beyond the scope of this license may be available at http://meetthegimp.org.

Last week the Fedora Board had an open, public meeting in IRC to discuss Fedora’s user base / target audience. Robyn announced the topic ahead of time and invited folks to join in. You can read the full meeting minutes, but I’ve gone through them and tried to pull out all of the interwoven threads of discussion and summarize it here for you as well.

Where we are now

The current Fedora user base is anyone who is:

• A voluntary Linux consumer
• Computer-friendly
• A likely collaborator
• A general productivity user

Also worth mentioning are:

• Fedora’s mission statement:
  

  The Fedora Project’s mission is to lead the advancement of free and open source software and content as a collaborative community.

• Fedora’s vision statement:
  

  The Fedora Project creates a world where free culture is welcoming and widespread, collaboration is commonplace, and people control their content and devices.

• Fedora’s core values:
  • Freedom
  • Features
  • Friends
  • First

Okay, now what?

With all of this in mind, Robyn opened the meeting with a few initial discussion points:

• Does our user base, as currently defined, still hold true for us as a project in describing who we want our users to be?
• Is what we are producing right now appropriate to meet that user base? If not what can we change to meet it?
• Do our mission and vision statements still hold true?

Welcome to 2013 – what’s happened since 2010?

Starting with the first point, Robyn noted that it has been some years since we as a project re-examined the user base definition and determined whether or not it is something that still helps us achieve our mission and vision for the project. Our current user base definition and set of mission and vision statements were drafted in 2010. Robyn asked, “What has changed in the past three years that might make this list more or less relevant?” The changes meeting participants suggested were:

1. Cloud (gholms) A potential set of contributors seem more interested in cloud images than desktops – they seem to be people who want to be involved in Fedora. (brunowolff)
2. More desktops – there’s been an explosion of different desktop environments… Cinnamon, Mate, etc. (mattrose)
3. Growth of Github – Github has grown from something like 100k accounts to 3 million users and 5 million repositories. Are those folks likely collaborators who care about open source? I would say yes. (rbergeron)
4. ARM & maker culture – The rise of ARM, raspberry pi, and maker culture. Are those folks more likely collaborators more easily targeted? Possibly. (rbergeron)
5. The rise of Android and ChromeOS (vwbusguy)
6. Tablets – tablet devices have grown in popularity (vwbusguy)
7. OS X – Mac OS X now seems to be the developer platform of choice, even amongst open source developers. “MacOSX still the easiest way to just get shit done, both as a user and a dev.” (mattrose) “Linux is staying at 2 percent of the desktop market.” (rbergeron)
8. Rise of social networks (misc)
9. Virtualization – Virtualization is much more prevalent (mattrose)

The changing nature of open source contributions

A bit further on, but relevant to the change that’s taken place in the technology and open source community since 2010, there was a discussion thread about how the nature of open source contributions itself has changed.

In talking about the 5 million people on github producing open source software, Robyn pointed out that for them “packaging really sucks.” She also said, “I don’t know that they understand the value [of packaging]. I don’t know that swinging the pendulum back is that easy.”

She continued, “Open source contribution has largely changed from ‘I work on the Linux operating system’ to ‘I get stuff done for my dayjob’ and ‘I scratch my own itch.’ To people whose experience is basically ‘github’ as far as open source contribution – which I would argue is far more likely to tap as a set of potential contributors than “ANYONE ON EARTH IN USER BASE” – packaging is a hell of a lot more work.”

“So there is a new, gigantic community of people building cool stuff with open source for which Fedora as it stands is completely irrelevant,” said mattdm. “That gigantic, growing community isn’t a fluke – it’s just the result of the general trend in computing.”

“I have to wonder:” replied Robyn, “Are we okay with knowing people are using Fedora, or are benefitting from Fedora, WITHOUT IT BEING the bright shiny thing on their desktop? Or saying Fedora in a big logo on it?”

“If they mention it in their docs on setting up their app/tool/service, yes,” responded skvidal.

“Our mission is to lead the advancement of free and open source software and content” mattdm said. “Increasingly, the movement around free software is going elsewhere. Not just from Fedora; from working on distros. Not because we suck; in fact, because we did such a good job that it’s boring. Interesting problems are now at a higher level.”

Brunowolff brought up another point, “I am not sure developers really understand what free software is really about. I have had some interactions with upstream for some things where they really didn’t understand licensing and claimed their stuff was GPL when they were using non-free assets. They seemed to think if they could get something from a public web page, that it was free.”

What good has the user base definition done for us?

There was also a thread of discussion that centered around how having a user base definition for the past 3 years or so has affected the project. Several discussion points were brought up:

• It only seems to apply to the default desktop – should it?

  inode0 also said, “Redefining Fedora to be something other than a live desktop is the correct place to start as what that is defined to be will guide the rest of this.”

  jreznik asked, “Do we know the user base of current gnome and target audience and as it’s our current default offering – does it match ours?”

• Do we have any control over it?

  “Are we able to steer it, or are we completely in a position to follow our upstreams?” asked jreznik.

  mattdm answered, “We should have a user base statement of our own, and select upstreams that fit it.”

• Why do we have a single defined character? Why not a target set of use cases?

  AndyP asked this question.

  “We do now, each spin has one even if it is implicit,” answered inode0.

• We want contributors

  “The user base we want is contributors,” vwbusguy pointed out.

  “I think we *all* want Fedora to have more contributors,” Robyn added.

• Many contributors ignore the user base

  “We have a fair number of contributors that don’t care about the user base as stated, and just ignore the wiki if they even know it exists,” pointed out mitr.

  “But you don’t have to spec out every user, just every core feature; specing out users limits your userbase.” pointed out AndyP.

• What about sub-communities?

  “Each sub community is in charge defining it’s target audience; of course, many sub-communities might be competing for the same target audience (like the desktop environments are doing)” VikingIce said.

• If we want more contributors, we’re not doing a good job at attracting them.

  dan408 pointed out, “Contributors don’t appear out of nowhere. Is there a book on Fedora I can read? Do I install fedora and then start reading every wiki page and become a contributor? There is no clearly defined path on a) how to become a contributor and b) how to plan to attract contributors c) a good place for contributors to start to learn the Fedora bureaucracy.”

How about the mission?

andreasn asked, “Is it a important mission of Fedora to spread free software to the masses?”

“Yes,” answered Robyn, “But does that mean that Fedora has to be their desktop? Can Fedora be *on* their desktop? Can they use Fedora to develop with? Are we okay with our technology being used to spread open source culture, even if we aren’t getting credit?”

“In fact,” responded mattdm, “that IS the mission. Producing a Linux distro is just one of the projects we happen to undertake.”

“This is about making *us happy*, and having something that we think people want to contribute to,” said Robyn.

“I was mostly curious in the context of target of ‘likely collaborators,’” responded andreasn, “as that is sometimes used as a bat for making things less non-hacker-friendly.”

Chicken or egg – do we define the potential contributors we want, or the contributors we already have?

“Can we… step back a little,” asked mitr, “and make sure that the board agrees whether it is attempting to define a vision for (existing or potential) contributors to follow, or to codify a vision that reflects contributors we actually have?”

Looking at the contributors we actually have Robyn said, “I think that Fedora has proven to be a valuable platform for people who want to take it an extend upon in HOWEVER THEY WISH to achieve their user ends. OLPC does this with the XOs and sugar.”

“OLPC and XO is in a different position,” responded jreznik. “Their target is pretty clear, one hardware…”

“It is absolutely true everywhere startup and cloud-focused that I look: Mac on the desktop, Linux in the cloud,” mattdm pointed out.

Robyn then provided a few scenarios in which people are using Fedora as a platform for building upon:

• Arista Networks uses Fedora for their EOS for their switches.
• Red Hat uses Fedora as the basis for RHEL.
• There are a lot of people who use Fedora to build things. ARM devices, etc., you name it.

Then there was a bit of discussion as to what makes Fedora a good base to build on. “The reuse is tied to our insistance on using free software,” said brunowolff. “With Ubunutu you have to worry about what you can reuse.”

Fedora could be a better base platform, though; mattrose pointed out, “If we want Fedora to be a base for other things, we have to be *way* more solid than we have been.”

At this point, then, a lot of the discussion began to swirl around the concept of Fedora primarily serving as a platform to build other things on top of.

Sub-communities & being a platform

There was a long conversation thread interwoven throughout the meeting about Fedora’s subcommunities.

“What I’ve always liked best about Fedora,” remarked gregdek, “is the ability to empower sub-communities to do awesome things. I’d like to extend that ability. And I’d like to see a structure that allows sub-communities to identify common problems and work together on them.”

“Nobody said it was going to be easy,” responded VikingIce, “but before we can do that we need a stable release (synced core or base OS) which they themselves can then build upon.”

“How does ‘Fedora as a platform’ relate to the ‘user base’ focus we have now? Does it replace it? Change it?” asked gholms.

gregdek answered, “It puts user base focus on individual sub-communities. Where, in my opinion, it should be.”

vwbusguy related gregdek’s idea to the Android community. “I like the idea of vanilla android vs vendor forks as a model,” he said. “Vanilla Android is both user-friendly and easily-customizable for forking.”

mattdm warned, “As someone with experience in making derivative distributions, if we really want to be friendly to that, that has huge impact on how we do many things (our updates policy, for example.)”

What exactly is meant by sub-community though? gregdek provided some examples: “Sub-communities will include more than just DEs. They’ll also include cloud platforms, web development platforms, mobile platforms… and so on,” he explained.

“Sub-communities also define their own target use case by their own existing nature,” added VikingIce.

mattdm had a very good question about conflicting and intersecting subcommnunity needs. “What happens when sub-communities’ needs clash?” he asked. “That’s kind of the point of having one default target originally.”

“That’s the kind of problem that the Fedora board should be regularly dealing with, and making decisions,” answered gregdek.

jreznik questioned this. “So you prefer subcommunities but wants one central board thing to make decisions?”

“One central board to handle disputes and apply scarce resources to common problems, yes. That’s exactly what I want,” gregdek responded.

“Yep, I agree in this way but I don’t see we hit such issues very often,” said jreznik.

“I think we hit them all the time,” gregdek explained, “Like ‘better package build tooling,’ which could benefit everyone.”

jreznik replied, “Better packaging tools are not a Board decision – someone has to do it. The Board can’t say ‘from today, you’re not Mate packager, but you’re working on tools…’ It even does not work in companies; I expect dan408 would leave such company.”

So the points and suggestions that were made during the part of the discussion were:

• Fedora’s subcommunities, in order to grow, need Fedora to be a more stable base for building upon than it is now.
• Fedora may need to revisit many of its policies (the updates policy was given as an example) in order to be friendlier to folks using it as a base to build a derivative distro on top of.
• If the Fedora project’s target / user base is technologists making derivative distros and/or using Fedora as a platform on top of which to build other technologies, then the subcommunities that come out of building on top of Fedora should determine their own respective user base targets.
• When conflicts arise between sub-communities, it could be the Board’s job to resolve those disputes. However, the Board doesn’t actually have a whole lot of power to do this in reality.

Changing the user base definition

There was also some discussion about, if we were to change the language of the existing user base definition for Fedora, how would we change it?

[We need to add something about 'cloud' and/or 'derivative distro maker,' in my opinion," said rdieter, after the platform discussion. "Or heck, we can even explicitly say 'maker of Fedora spins."

"So we'd be serving as a basis for derivatives, kinda like debian?" asked misc.

StillBob pointed out, "that is what made it cool for us tinkerers and hobbyists."

"Absolutely," said gregdek.

The conversation drifted from there, however, so there were no other concrete and specific suggestions made for changing the current user base definition language after this point.

Current perception of Fedora

There was also a thread of conversation about how Fedora is currently perceived. This thread came up because it was thought that Fedora's current perception might affect any future plans to change who the project is for and its priorities: If the project is known for being a specific thing and we decided to do something very different, for example, we'd face a lot more struggles in convincing folks interested in the new, different thing to join the community.

There were two main current perceptions of Fedora that everyone discussed:

1. Fedora as GNOME OS / as a desktop product

   DiscordianUK stated, "The market such as it is perceives Fedora as Gnome-OS."

   "I think that's probably largely fair to say," Robyn replied. "I'm not saying it's correct; I'm just saying that I think that is the perception."

   vwbugguy added, "Yes. We have a strong KDE and XFCE community and it seems like they kind of get the back seat with our labeling."

   "Yep," said gregdek. "Have for years."

   "We have many desktop environments," DiscordianUK pointed out.

   inode0 suggested that one of the core problems might be that Fedora is a Linux desktop distribution.

   "That's kinda paradoxal," misc responded to inode0, "since people think that Fedora is 'RHEL beta,' but few people use Fedora on a server, and few people use RHEL as a desktop."

   "Is it a problem?" jreznik asked inode0. "Do we want to be more [than a desktop distribution]? Do we have the contributors to we need to be more?”

   Robyn responded, “Yes. And we have many, many use cases that go beyond ‘as what’s on my laptop or desktop machine as the primary OS.’”

   “So… maybe instead of targeting a user-base, target use-cases?” suggested rdieter.

   “But we should attract more people who want to build other things too,” said inode0, “and we aren’t because of our desktop focus.”

   The conclusion of this thread of conversation appeared to be that Fedora is currently seen as a desktop-focused Linux distribution, and that this perception may be weakening our ability to serve, as discussed earlier, as an effective platform/base for building things on top of.

2. Fedora as a RHEL testbed

   “The largest perception I see in the wild (after a decade!) [of Fedora]” said mattdm, “is’”that’s the RHEL beta test thing, right?’”

   A little further on, there was more in-depth discussion about this perception.

   “I’d like us to stop pretending Fedora is not build for RHEL,” said mitr.

   “Making fedora serve as a base for RHEL is an extremely important use case in terms of the sustainability of the project,” said mizmo. “That doesn’t mean it has to be the only use case. I also don’t see anybody pretending it’s not a base for RHEL.” (ed. note – that’s me. )

   “If it is one of our strengths,” gholms pointed out, “we should play to it.”

   “Certainly!” responded mizmo. “Having a stable platform that is used for a widely popular enterprise Linux is absolutely a strength.”

   mitr pointed out, “The user base on the wiki and people who use RHEL have pretty much nothing in common.”

   “That’s actually not true at all,” responded mizmo.

   “Target use case: ‘make derivative spin/distro’” said rdieter.

   “Being seen as RHEL beta is harmful,” said misc, “as I am pretty sure there is less contribution from external company due to that ( when compared to debian, for example.)”

   “I don’t see RHEL as a problem,” DiscordianUK stated.

   “I don’t think RHEL beta is accurate,” said brunowolff. “It is more used for technology development, some of which succeeds and some of which fails.”

   “Well, as i said, RHEL targets mainly servers, and I think I am in the minority who run Fedora on server,” said misc. “That’s not a great way to test a beta.”

   The conclusion here, then, seemed to be that even though it is a very real perception that Fedora is merely a ‘RHEL testbed,’ it also directly conflicts with the other very real perception that Fedora is a ‘desktop distro.’ The conflict comes from the fact that RHEL is primarily a server, not a desktop, so if Fedora is a ‘RHEL testbed’ then how can it also simultaneously serve primarily as a desktop?

   It was also suggested that serving as the base that RHEL is build upon is a strength, and that strength could be used to expand Fedora’s utility as a base platform.

Who determines Fedora’s direction? The project board’s futility

A theme that came up a couple of times was how much the project board could actually do to change anything.

“To some degree we don’t get to decide what we will be,” said inode0. “We start somewhere and the community takes us along for the ride.”

“The board do not control people,” said misc.

rdieter responded, “but we can say ‘no’ to things.”

“Only if the board is asked,” StillBob pointed out.

“The board can be proactive too,” said rdieter.

StillBob questioned this. “How many things are happening without being asked?”

“If no one notices or is hurt,” rdieter explained, “it’s not a big deal. When it causes problems or conflict, [the board] steps in.”

“We can occasionally reset the starting point,” inode0 said, “but ultimately people contributing will again reframe the direction we go from there.”

Use cases vs. userbase

One very long thread of conversation started by AndyP was changing the user base definition document so instead of referring to a specific user we are targeting as a project, it referred to a set of use cases we had prioritized and committed to supporting.

“Targeting the universe is the opposite of strategy 101,” Robyn said. “YOU CANNOT BE ALL THINGS TO ALL PEOPLE.”

“If you focus on a user base, I think people look at it and think that if it’s not them, it’s a problem, and they disagree with it and ignore it,” mizmo said. “If you focus on a set of use cases we want to support, and they are cool things our community wants to do, it might be easier to build support for them.”

“If the community wants to do them already,” asked mitr, “why would we need to define the use cases in the first place?”

“If they aren’t defined,” answered mizmo, “then they are harder to get support for. For example, if we decide that building cool robots using Fedora is a priority use case, then we can get funding to go to robotics conferences and talk about Fedora there.”

“If it’s just a small subcommunity doing robot stuff,” mizmo continued, “it’s hard to get other teams in Fedora like marketing and design and ambassadors and events all supporting it – because the priority is not clear.”

“Or because there is more packagers than marketing/doc/etc team can handle,” misc pointed out.

mizmo continued, “Without priorities, everything is equally able to be ignored / put to the bottom of the pile. With priorities, it’s easier to get resources to the things we think are important.”

“That’s talking about some prospective community that doesn’t exist,” responded mitr. “OK, I was thinking in context of existing contributor base.”

“No,” replied mizmo, “There is actually a robotics community within Fedora. I wasn’t making up an example.”

VikingIce added, “But what’s important is what matters to the subcommunities, which are the people doing the work in the first place.”

What can the board do, anyway?

“Marketing is part of the problem,” said vwbusguy. “If people don’t know that a robotics community even exists, for example…”

“Anyway,” mitr said, “the only thing the Board can directly affect is marketing money? How realistic is that it will significantly change what most of our contributors want to build on?”

mizmo disagreed. “That isn’t the only thing the board can directly affect. It’s not just money. it’s how we talk about the project, what conversations we decide to enter into and which we abstain from.”

“Perception matters a great deal,” gholms added.

“It’s about building the relationships with those communities best served by the prioritized use cases to expand Fedora’s reach into the mainstream of those communities,” mizmo continued.

“Realistically there are the dozens/hundreds of people building RHEL and they are not going away,” mitr responded.

“Okay, and so what?” asked mizmo.

“So they can and will drown out some other use cases,” said mitr.

“How/why?” asked mizmo.

“Yep. We have to build better relationships,” said Robyn, stepping in.

No edicts from on high, please

mizmo asked, “Does anybody disagree with the idea that we all want fedora to be used in building cool things? Because if we all agree with that, then the next step is to figure out what cool things.”

“I agree completely with that,” answered inode0, “but I disagree that the board or any other small group should define the set of cool things.”

“I think that the ‘cool things list’ may be ‘here’s what we’re doing the best at RIGHT NOW,’” Robyn responded. “We can’t tell people what to do. But we can certainly foster an environment that it easy for them to do really great things.”

“Well, we can’t be everything – that’s what we are now, that’s not so successful is it?” asked mizmo.

“We aren’t everything now,” inode0 responded.

“We are a complete chaotic anything goes bazaar,” mizmo disagreed. “I consider that everything.”

inode0 pointed out that he thinks we are pretty close to exactly one thing now.

“By being everything we are nothing,” mizmo responded.

“It isn’t about being everything,” said inode0. “It is about whether 10 people are smart enough to declare we are now X.”

“I don’t think anyone is saying that anyone is going to do that,” mattdm said.

mizmo agreed, saying, “I don’t think they should do that. Rather, I think we should take a look at what people are doing with Fedora now that is cool and elevate those things that are the most promising, call them out, and get them resources.”

“Well, if we say these are the 3 use cases we care about – I think that is what we are doing,” inode0 said.

“If the board comes down with those use cases from the mountain, sure,” mattdm said.

mizmo responded, “It depends at what level you’re defining the use case. A use case can be quite broad or very specific.”

Building on, or building a base

“On, or as a base?” asked andreasn.

“Either,” answered mizmo.

“Does it matter?” gholms questioned.

“Well,” andreasn responded, “one is building a clear operating system that includes tools for making, say, blueprints for robots on, the other would be a base operating system for robot software.”

Who doesn’t want to build cool things?

“What would be the opposite of that statement?” asked mitr. “People who want to build uncool things? People who want to… watch youtube movies?”

“Does there have to be a direct opposite of the statement for it to make sense to you?” asked mizmo. “The user base is a good alternative for comparison. E.g., Fedora being for people who build and make things, not people who consume or do ‘general productivity’ tasks.”

“No,” mitr said, “but it needs to be more specific than “90% of breathing people” (I know the 90% is exaggerating.)”

mizmo agreed, “Right, that’s why I’m saying the next step would be to define which type of cool things we want to focus on enabling people to build. Or think about what folks who aren’t currently using who fit our core values and would benefit from free software and try to engage them.”

Big changes make a mess?

“So, if we declare this the key use case, the release cycle changes *follow*. Making that the driver is *backwards*.” said mattdm.

“The whole /usr move, gnome3, systemd and anaconda changes have made a mess of the last few releases,” said mattrose.

“Well,” responded andreasn, “One has to evolve or die.”

“Yeah,” agreed mattrose, “but it was still a mess.”

Users vs. Contributors

“Looking on it – we maybe hit clash between contributors (who contributes to Fedora for some reasons) and users (who just wants to use it)…” said jreznik, “and there are not enough contributors to say, it’s the only audience.”

“We should blur the divide between users and contributors as much as possible,” vwbusyguy said.

mattrose added, “I think more users would contribute if it were easier. I don’t think anyone is ‘just a user.’”

What do we want, anyway?

“I think your point follows well too,” said herlo to inode0. “There’s no real value in discussing the user base until we know what we want.”

“Well, I recognize myself in the userbase,” said misc, “but yeah, we are not using it to define what we do.”

“What we are producing is a desktop distribution – see the website,” said inode0.

mizmo suggested, “We can change the website. The messaging of the website is all F11/F12 era.”

“It is the substance that is limiting,” responded inode0, “so we can think about how much of this can be accomplished via marketing/website stuff – some surely can.”

“How does being a collection of desktop linux systems do any good for anybody?” mizmo asked. “Are there people in the world whose goal in life is to try multiple desktops? I can’t imagine there are enough for Fedora to then matter much in the world? Trying different desktops out isn’t really doing anything.”

“Desktops should be one thing Fedora is used to create,” inode0 said.

“What about servers then?” asked andreasn.

“They’re there, but secondary,” said vwbusguy.

VikingIce said, “If you want to make people contribute and participate it needs to be fun and fulfilling for them to do so; the more sub communities we have, the more they are likely to find something they feel is fun and rewarding to participate in.”

“It’s going to be fun and fulfilling if what we’re doing MATTERS,” said mizmo. “Serving as a multidesktop distro doesn’t matter. How many multidesktop distros are out there?”

Summary

I think the overall conclusions you could draw from this discussion are:

• We could replace the user base document with a definition of prioritized use cases Fedora is meant to support.
• There is value in defining a set of prioritized use cases in that it helps the various teams and groups within Fedora determine more intelligently how to expend their limited resources in supporting any specific use case.
• The board can help support a given use case not just with funding, but with direction, messaging, marketing, and other influence.
• The project board shouldn’t just come up with a set of use cases and declare the community should focus on those; rather, they should review all of the use cases Fedora is being used for today and prioritize, promote, and find resources for those determined most important.
• Whichever way we end up going moving forward, the Fedora website should reflect that direction. It currently is very desktop-centric.
• Whatever we decide Fedora’s ultimate purpose is, we should make sure it’s something that matters so people will care about it. Perhaps being a ‘multi-desktop distro’ isn’t really something that matters.

Other discussions

There were a few other loosely-related discussions that took place during the meeting.

Upstream

jreznik brought up the tension Fedora experiences in terms of deciding its own destiny vs. being at the mercy of upstream.

“As a distribution,” jreznik started to explain, “we really has to be more in touch with upstream, especially that upstreams that influences our offering and to know, where they lead…”

“Upstream is defined again by subcommunities like each DE,)” said VikingIce, “So Fedora can never be any closer to upstream than the subcommunity makes it.”

“Agreed,” said Robyn in response to VikingIce. “And when we have disconnects between communities, or we aren’t in trust of them, we have found different substitutes. Mariadb / mysql seems to be a reasonable extension of that idea, I think. It’s not about making us a great platform for mysql; it’s about us having a community that is happy about the communities it works with.”

Content

There was a brief discussion about what Fedora can or should do in advancing free content, since our mission statement mentions free content.

“Our mission is to lead the advancement of free and open source software and content,” mattdm said.

“I am not sure we are leading on the content part, to be honest,” said misc.

“I’d really like to see that content part!” jreznik added.

Mmsc replied, “Isn’t it the job of a already existing community (like wikipedia, etc.,) so maybe we should think how we can complement them?”

“I mean it more in the way – propagate that content, show people free content, open data works great with our values etc.,” jreznik responded.

An easy-to-modify platform

The conversation then circled back around the concept of Fedora serving primarily as a platform for people to modify.

The principle of freedom makes Fedora more compelling

“I think that the best way to get more people to contribute is to have something that is easy-to-use / modify / reshape for their own ‘end user purposes’ – and to have an enduring promise and commitment to freedom that we yell out from the skies,” said Robyn. “There are 1 billion places for people to contribute. It is easier than ever. Standing for something and having a reason more than ‘easy-to-use’ affects people’s hearts, makes them have a relationship with us, etc. And frankly, it helps them overlook problems like ‘oh god updates just ruined my day’ too.”

“Yup,” agreed vwbusguy. “The FOSS emphasis is a big draw for contributors, IMO.”

“It lets them want to put up with ‘must upgrade once a year,’” added Robyn.

“And we shouldn’t sacrifice that for the sake of being ‘user friendly,’” said vwbusguy.

“Honestly: Fedora as a platform rather than “Fedora as the perceived gnome-os” is probably better as a base for RHEL anyway,” Robyn mentioned.

“The reality is that Fedora *is* a platform,” said gregdek. “A great one.”

Not perceived as a platform

inode0 pointed out one issue, “The reality is no one really perceives it to be a platform and perception has a lot to do with who comes to look around.”

VikingIce explained the issue is “because we are sending the message ‘we have a default’ and by doing that we ‘this is what we want you to do’ instead of encourage people to explore, try, and if they dont like what they see here are the tools for you to create what you like to see.”

Building products?

“The good thing about the desktop offering,” pointed out andreasn, “is that it is a clear product. The server should be a clear product, too.”

jreznik said that he “would even not object with GNOME OS based on Fedora – even as a separate project for example same as RHEL is.”

“rbergeron’s wording as ‘platform’ makes more sense to me…” said mitr. “Anything can be used to build a derivative, but that doesn’t mean the base does anything particularly well.”

“Wording doesn’t matter to me,” said rdieter, “As long as it’s a clear (and important) documented use-case.”

“I would like for us to be a kick ass guest,” said Robyn.

The implementation of a platform will be sticky

“I can stand behind the idea to build a platform,” said mitr, “but the implementation will be a minefield.
Are we willing to walk through it?”

“We must be,” gregedek responded.

“A platform for what?” mizmo asked.

“Everything,” VikingIce answered.

“So now we are back to being everything again,” mizmo sighed.

“For building $stuff on,” mitr explained. “Like, an API that actually makes sense instead of the 10 million libraries we have.”

“Do we want as a project to be that one who ships the final product people can use, or do want to be a catalyst to allow other projects to build on top of it? GNOME OS, RHEL, cloud images…” asked jreznik.

What our the next steps?

“What are our steps at this point?” asked Robyn. “Do we agree that $userbase as defined is not matching up with what we are producing, and that we are not making great strides in reaching that userbase with a product or messaging?”

Everyone basically agreed with this point.

Agenda for the next meeting

“It seems like common pattern here is platform – could we start next meeting with it? What such a platform could look like?” asked jreznik.

“Maybe platform plus (use cases as they connect platform to subcommunities)” suggested gregdek.

“There’s little brainstorming exercises; I have a book of them. Maybe I’ll go through it and pick out some I think might work for us and suggest them on the list?” suggested mizmo. “I think if the next meeting focuses on building an artifact, the discussion will be a bit less chaotic.” You can read those brainstorm exercise suggestions here.

Material for the next meeting

“I am going to write up thoughts on ‘what has changed,’” said Robyn. “I think a lot of times people don’t really look out the window at the rest of the world. And a few other thoughts as well. I have this enormous bunch of writing that is bordering on novel-size.”

Research to gather

“I think it would be useful to know why people contribute to Fedora *right now* – what are they passionate about?” Robyn said. “I wonder if a call for people to blog / write about their interests would be useful (and nice to see in general.)”

“There’s a thread on devel list now about what people use Fedora for,” mizmo pointed out. “I think it would be cool to do a widespread blog thing on that.”

“Yep,” said Robyn. “I think they’re different, slightly, though – contributing and using – though largely the devel list is going to be contributors.”

“Maybe a meme,” herlo suggested. “Name 3 things for which you use Fedora.”

“Fedora Haikus,” said Robyn. She then asked herlo, “Do you want to do a Fedora “3 reasons you use it” thing more in social-media land (Facebook, etc)? I think a lot of folks *don’t* read devel list – and it would be fun and concise.”

“Maybe,” replied herlo. He said he will think of a “fun little gag that might catch on.”

“What about 3 things you wish you could do with Fedora?” asked mizmo. “Or 3 dreams you have for Fedora?”

“Why I use Fedora in 3 words (for twitter),” suggested AndyP.

“We need a good way to find out a few bits of things: Why people care, why people use, why people contribute,” Robyn concluded.

Packagers vs. other contributors

“In fact,” said misc, “I think packagers are over-represented, in the sense people try to become packager from others team.”

“While we need more packagers,” added brunowolff, “I think non-packager contributors are more valuable as they are harder to find.”

“I don’t know that ‘make it easier’ converts people to contributors, though,” said Robyn.

“‘Contributors’ is kinda vague,” DiscordianUK added.

“But non-packagers probably find dealing with breakage harder. They aren’t in as good of a position to be able to directly fix it,” brunowolff pointed out.

What’s next?

I think the board is planning to have another open meeting to discuss this topic further. If you’d like to continue the discussion and join in on the next meeting, check out the Fedora advisory-board mailing list.

In my previous post on postprocessing my Open Source portrait, I had shown a couple of contact sheets that I had generated to help me narrow down which images I liked. That contact sheet looked like this:


Contact sheets are a great holdover from the days of film, when you wanted a big overview of all the shots on a strip of film. After developing the film, you could just lay a sheet of photo paper under the enlarger, lay your strips of film on top, put a glass plate over the whole thing to hold them down, and then expose with white light for a small amount of time.

This would produce a single sheet with all your images as thumbnails:


This is probably redundant these days with the ability to look at a directory listing as thumbnail images, but I still find uses for this type of image.

My personal photos are kept on a backup server. That computer has no monitor, keyboard, or mouse. The main way I access it is through shares on my network. If I'm off-site, I'll access my network using SSH.

The upside is that it's wayyy faster than using a GUI. The downside is that there's no GUI...

The machine I'm SSH'ing into does have my Dropbox account linked, though. So what I do is run Imagemagick Montage on the machine I remote into, and have it generate a "contact sheet" for me, placing it into my Dropbox folder.

Wait a few minutes, and voila! Instant contact sheet for me to peruse on my local machine. Here is what my montage command looks like:

montage -verbose -label '%f' -font Helvetica -pointsize 10 -background '#000000' -fill 'gray' -define jpeg:size=200x200 -geometry 200x200+2+2 -auto-orient P21603{65..70}.JPG ~/Dropbox/contact-dark.jpg

Yes, it looks scary. I promise you, it's not. As usual, let's have a look at the command line option by option to see whats going on...

montage -verbose -label '%f' -font Helvetica -pointsize 10

Fire up the montage command. Set it to -verbose output to see whats going on.

Label all the thumbnails with the filename, using the font Helvetica at a point size of 10. See, not too bad so far!

-background '#000000' -fill 'gray'

Set the background color to black (#000), and the fill color for the label text to gray.

-define jpeg:size=200x200

This one is interesting. I found that if I tried to run the command on a full directory of jpegs, I would quickly run out of memory. This is because imagemagick will read in each file and keep the full size image in memory until it's done. Holy Mackerel!

So this option tells imagemagick to resize the jpeg as soon as it's read in, and to only keep the smaller version in memory. This significantly speeds up the process of generating the contact sheet.

-geometry 200x200+2+2

This just tells imagemagick to set each thumbnail size on the final output to be 200x200 pixels, with a 2px border around them.

-auto-orient

Rotate any images to their correct orientation as specified in their metadata.

P21603{65..70}.JPG

Now this is interesting. I'm not sure if this will work in Windows, but it does on a BSD/OSX/*nix shell. I can specify a numerical range of images that I want to be in my final output.

The above command will basically be expanded so that the input files are:

P2160365.JPG
P2160366.JPG
P2160367.JPG
P2160368.JPG
P2160369.JPG
P2160370.JPG

If you wanted to just do all the images in the directory, you could use the normal glob syntax for all JPG images:

*.JPG

I did this to limit the final size of the output contact sheet to a range of images. For both final size as well as memory limits on my machine (especially if I had hundreds of images in my directory.

I could also have done it by using the glob syntax. For instance, if I wanted all the images in the 600-699 range, I could have used:

P21606*.JPG

Or any variation on that (I'm not going to get into the syntax here, but there are plenty of references around for it).

~/Dropbox/contact-dark.jpg

Output the final image "contact-dark.jpg" to my Dropbox folder.

That's about it. That command puts out a nice contact sheet for me to quickly eyeball and find images that I like. From there I can narrow it down and look more closely at the final picks.

I could even go so far as to use this command as part of a shell script that can recursively walk through all of the folders of my photos, and to output contact sheets for each one if I wanted. I may get into that at another time...

It’s time again to start thinking about articles, tutorials and images forIssue # 42 of Blenderart Magazine.

The theme for this issue is “Crossing the Digital Divide”

One of the appeals of creating in digital space is that anything is possible, allowing for greater creative freedom. The challenge is to get your creation out into the real world. So in this issue we are going to look at the many ways that you can bring your creations/products across the Digital Divide into the real world.

Looking for tutorials or “making of” articles on:

• Custom Milling and similar processes
• 3d printing
• Creating blue prints or products spec sheets to manufacture from
• Any creative method of getting your project out into the real world

*warning: lack of submissions could result in an entire issue of fuzzy bunnies, puffy hearts and a galley filled with random images off my hard drive ….  …… goes off to check number and variety of images on my hard drive …. just in case. 

Articles

Send in your articles to sandra
Subject: “Article submission Issue # 42 [your article name]“

Gallery Images

As usual you can also submit your best renders based on the theme of the issue. The theme of this issue is “Crossing the Digital Divide”. Digital and Real world images would be a great submission. Please note if the entry does not match with the theme it will not be published.

Send in your entries for gallery to gaurav
Subject: “Gallery submission Issue # 42″

Note: Image size should be of 1024x (width) at max.

Last date of submissions May 5, 2013.

Good luck!
Blenderart Team

During the ongoing SUSE Hack Week I had the possibility to make the CoreText-using code in LibreOffice work well enough to be usable. Thus a 64-bit build of LibreOffice is now also fairly usable, at least as long as you don't use any exotic functionality, knock on wood.

As such, it has been possible for a long time to build LibreOffice for OS X with a current Xcode 4.x and its Clang compiler, also as 64-bit code.

LibreOffice has traditionally used the ATSUI API to display text on Mac OS X. ATSUI was deprecated years ago and superseded by CoreText. ATSUI is still present in the OS, but only for 32-bit code. 64-bit code has to use CoreText. Which is a good thing, of course; it forces developers to finally stop using obsolete API if they want to produce 64-bit code.

Naturally, CoreText is also what iOS provides, so it was necessary to get the CoreText engine into shape also for the benefit of the iOS porting effort.

Note that this work has been available in the LibreOffice source code repository continuously, even while known to be far from usable. I don't believe in the "check in the code when it is ready" way of working in an Open Source community.

There are still some known glitches. For instance, the placement of glyphs on a line that you are editing is slightly "nervous". Glyphs might jump back and forth a pixel when you add or remove characters. I will work on fixing this.

Those who are interested can find daily builds.  ("Daily" should be taken with a grain of salt; whether builds have been uploaded for a given day or not depends on whether I remember to keep my tinderbox running, and in what shape the master branch is.)

If you want to build a CoreText-using LibreOffice yourself, use the --enable-coretext option. To build a 64-bit LibreOffice, use --enable-64-bit.

Thanks to Norbert Thiebaud for his initial work on using CoreText.

Blender’s Video Sequence Editor (or VSE for short) is a small non-linear video editor cozily tucked in to Blender, with the purpose of quickly editing Blender renders. It is ideal for working with rendered output (makes sense) and I’ve used it on many an animation project with confidence. Tube is being edited with VSE, as a 12 minute ‘live’ edit that gets updated with new versions of each shot and render.  I’ve been trying out the Python API to streamline the process even further. So… what are the advantages of the Video Sequence Editor. Other than being Free Software, and right there, it turns out there are quite a few:

1. familiar interface for blender users: follows the same interface conventions for selecting, scrubbing, moving, etc. Makes it very easy to use for even beginning to intermediate users.
2. tracks are super nice: there are a lot of them, and they are *not* restricted: you can put audio, effects, transitions, videos or images on any track. Way to go Blender for not copying the skeuomorphic conventions that makes so many video editors a nightmare in usability.
3. Since Blender splits selection and action, scrubbing vs. selection is never a problem, you scrub with one mouse button, select with the other, and there is never a problem of having to scrub in a tiny target, or selecting when you want to scrub. I’ve never had this ease of use in any other editor.
4. simple ui, not super cluttered with options
5. covers most of the basics of what you would need from a video editor: cutting, transitions, simple grading, transformations, sound, some effects, alpha over, blending modes, etc.
6. has surprisingly advanced features buried in there too: Speed control, Multicam editing, Proxies for offline editing, histograms and waveform views, ‘meta sequences’ which are basically groups of anything (movies , images, transitions , etc) bundled together in one editable strip on the timeline.
7. as in the rest of Blender, everything is keyframable.
8. you can add 3D Scenes as clips (blender calls them strips) making Blender into a ‘live’ title / effects generator for the editor. They can be previewed in openGL, and render out according to the scene settings.
9. it treats image sequences as first class citizens, a must!!!
10. Python scriptable!!!! big feature IMO. (uses the same api as the rest of Blender)

Disadvantages are also present, I should mention a few:

1. UI is blender centric! so if you are not a blender user, it does not resemble $FAVORITEVIDEOEDITOR at all. Also, you have to expose it in the UI (only a drop down away, but most people don’t even realize it is there)
2. no ‘bin’ of clips, no thumbnail previews on the video files, though waveform previewing is supported.
3. lacks some UI niceties for really fast editing, though that can be fixed with python operators, and also is getting improvements over time.
4. could be faster: we lost frame prefetching in the 2.5 transition, however, it is not much slower than some other editors I’ve used.
5. not a huge amount of codec support: Since Blender is primarily not a video editor, supporting a bajillion codecs is not really a goal. I believe this differs slightly cross platform.
6. bad codec support unfortunately means not only that some codecs don’t work, but that some of the codecs work imperfectly.
7. needs more import/export features (EDL is supported, but afk only one way)
8. some features could use a bit of polish. This is hampered by the fact that this is old code, a bit messy, and not many developers like to work with it.

Needless to say this is all ‘at the time of writing’. Things may improve, or the whole thing gets thrown into the canal

So what have I been up to with Blender’s video editor? Quite a bit! Some of it may end up not-so-useful in the end, but experimentation could yield some refinements. The really good thing about using Python, is that I can ‘rip up’ complex things and rearrange / redo them. So the experiments don’t result in a huge waste. Lets have a peak.

Automatic Updates – take 1- ogler.py:

In the beginning of the project I thought to use Blender’s scene support to create a ‘live’ edit, that did not use video or image clips at all, but instead, referenced actual animation shots directly. This would be done by linking the shots into the edit as scenes, then using Blender’s scene strip support to edit them live as opengl previews. In my more optimistic moments, I imagined pressing ‘render’ directly from the sequence editor, and rendering the entire movie at once.

Early tests were promising, and in fact, for very small (say under 10 shots) this approach could work quite well. However, things were getting slow for Tube, as our shots were a bit too slow for editing live, and I wanted the speed of movie clips without the loss of the dynamic connection. Chris Webber, lead developer of GNU Mediagoblin, swooped to my assistance, and created ogler.py: A sequence strip addon that renders out the linked scenes into opengl previews, and then swaps them in the edit, but can swap them back to scene strips. so you can edit in the scenes, oglify them and edit fast, and then de-oglify  to keep the connection live anytime you want.

Sadly, once tube got to around 30-40 shots, this became unworkable. Even loading the file with all the linked scenes would take for ever, and I started to run out of ram. It became clear that the memory requirements for the full movie  (around 70 shots) would be too big to just link into one file. Sadly, I oglifyied for the last time, deleting the scene links as I went, leaving burning disconnection and lament, where once was a harmonious connected live edit.

Automatic Updates – take 2- smash_all.py:

After that, updates were not automatic. As shots were animated, I’d open the scene file, open gl preview it (henceforth, the verb is boomsmash) and refresh the edit. Sometimes I’d download a preview directly from an animator, or from helga, and skip the whole boomsmashing thing. With multiple animators working this got a bit tiresome and error prone, and slowly the videos files would drift from ogler’s handy folder, getting scattered on my harddisk, whereever they were dropped initially. Also, we started getting in rendered shots, so these found their way on the edit. These are managed quite well by Helga, as image sequences on the server. I would drop them into the sequencer via the mounted network folder, and they worked surprisingly well – fast, but not realtime. However, I’d every now and then drop a local render in too, complicating things again.

At this points I started to have two problems: One the setup was far too chaotic, and only worked on one workstation. Two, it was slow, and I need realtime performance to do more careful and artistic editing down the line. I decided to solve the organization problem first, as having a working edit is of paramount importance when reviewing and modifying animation shots, for the obvious reason that they have to work together in the edit.

I wrote a simple script called smash_all.py. First time you run it, it boomsmashes the entire list of shots into one folder- and saves the timestamps of the blend files it just rendered. Subsequent runs, it will only do this for changed files (by checking the timestamps), allowing me to run it to automatically updated progressed animation shots. Nice side-effect, all the movie files are consistently named, and live in one folder. The actual process runs for a bit, but, it can be run in the background with no user intervention.

The script is an addon, but currently has hardcoded shot list, and folder locations, it wouldn’t be hard to make a config file it could import instead – in any case, all the paths are at the beginning of the file, easy to edit. We could improve it by getting the user’s home folder from the OS module, making more paths relative to the blend file, and getting a few folders as options. I’d love to hear suggestions, as I’m not sure what the nicest thing would be.

Speed: Sequencer Proxies and proxy_workflow.py:

Blender as I mentioned has a built in ability to do proxies for editing slow footage (examples are hi resolution footage, exrs, footage that lives on a network folder, etc). They are a great way to speed up your edit, and might be a cool way to do an offline edit (I’m trying to see how possible this is with some help from python). Proxies are either movies or image sequences, and can be at 25 to 100% of the resolution of the original- but in jpg or avi jpeg formats, very fast. Each strip has a toggle to enable proxies, and then a bunch of options for desired sizes, timecode, and folder/file locations.

Since the strips I was using were at least partially on the server, I wanted the proxies to be local to my disk for speed, not on the same server with the rendered footage. So I needed the custom folder option, but… setting a custom folder for each and every clip one by one is just not an option for a lazy programmer (more seriously, it isn’t a good option for anybody). Since I plan to explore several workflow enhancements for proxies, I opted to make an single addon (proxy_workflow.py) that contains right now just a single operator, that gets a menu item, and a hotkey (ctrl-shift-a for now). The operator creates a folder ‘Tproxy’ next to the edit.blend file, and populates it with (hopefully unique) subfolders based on the path of each strip. You simply select all the strips you want to proxy, and it will create proxies (but only for movie and image files) in the selection. It also gives you a popup so you can select the sizes required, without having to go strip by strip. Maybe in the future we can make the path an optional entry, for custom workflows.

A known problem: if the same source image or video is used for multiple strips, it will not proxy it, but it will create the custom folder correctly. Simply select one of the strips and do rebuild proxies and timecodes, and all will be well.

Speed: Future work:

It seems that even with local on disk proxies, the edit hits the network for the source files every time you scrub over to a new clip. This means scrubbing within one strip is fast, but the moment you ‘step’ over an edit, you get a little lag, dependent on the network speed. At the Drome, this is almost imperceptible, but at home… the edit literally just hangs. I can think of a few solutions.

1. bug report/whine to blender coders (or check the code myself) and see if this can be fixed in Blender. No need to check the source if you are using a proxy.
2. temporarily change the source folder to some dummy location, and save the original location in a custom property, and use an operator to toggle back and forth.
3. build the proxies, but then use them *as* the source, and switch back with an operator.
4. do the ‘offline’ part completely outside of blender. just make (low fidelity) copies of everything, local to the edit, outside of blender, and work with that. Export an EDL, or just swap the ‘real thing’ in later. I would prefer to do things within blender, and not have to resort to this.

One would be best I think, unless there’s some reason this lookup to the original file needs to happen that I didn’t think of.

Proxies and Alpha:

This wasn’t done for Tube (it was a midnight hack for a commercial project under deadline) but I ended up using it on Tube. Simply put:

Since proxies are .jpg files they don’t have alpha channels. This can be an issue depending on your edit, if you want a smaller sized proxy of the alpha/image. To solve this I wrote an operator that uses imagemagick to create .tga proxies (bigger, uncompressed, and faster than .png or .exr files) instead, but then renames the extension to .jpg. Blender happily loads them as proxies, but the alpha still works.

Where’s the code?

You can find the code, in its current, unpolished and silly state, on gitorious

 

 

After Richards recent patch about adding a colour management system to wayland, I was interested to build a Oyranos CMS connection module for wayland. The patch is in a initial stage, but might get to a similar level like what is already in CompICC and KWin colour servers.

First I substituted all openSUSE-12.3 distro packages with the adequate packages from tobijk and obtained a version 1.0.6 . Keeping the distro Mesa package resulted in a missed EGL Wayland extension and some crashes. On the Wayland website are some instructions on how to setup the environment. Especially the XDG_RUNTIME_DIR variable needs attention. I skipped the part of adding a special weston-lauch group and run the application simply by root. However the a symbol in cairo was missed “cairo_egl_device_create”. After cloning and building pixman and cairo following the Wayland instructions everything went fine. Here a simple ~/.config/weston.ini file to start with:
[wayland-desktop-shell]
locking=true

[launcher]
icon=/usr/share/icons/oxygen/32×32/apps/utilities-terminal.png
path=/usr/bin/weston-terminal

Weston launches on my system into a multi monitor setup with nouveau. There is still heave tearing, while moving the terminal. After Strg+Alt+Entf (Ctrl+Alt+Del) weston quits.

Watching people weave into and out of our lane while they texted on the freeway (where are all the cops who are supposed to be cracking down on that this week?), Dave came up with an idea: a competition where you drive some sort of course -- start with an autocross course, or maybe add twists like parallel parking -- while simultaneously texting. Your score is a combination of your time through the course, fewest pylons hit, and the accuracy of your texted replies.

He was thinking of a show we used to see at a pizza place we frequented a few years ago, "Cash Cab". The premise: there's a special taxi that drives around New York City rigged with video gear, and if it picks you up, you get a chance to play a "Who wants to be a millionaire" style quiz show in the time till the driver gets you to your destination.

I have to admit, although Dave's combination of Cash Cab and autocross sounded intriguing, it didn't sound like something I'd actually want to do. Although I see plenty of drivers who seem to love the challenge of parallel parking or negotiating rush-hour traffic with one hand (or no hands!), it's not my thing.

But here's a modification that did sound fun to me: you wear a hands-free headset, and while you negotiate the course, someone asks you quiz-show type questions and you have to answer while you're driving the course. You can still use both hands to drive; just not your whole brain.

It's an exercise in concentration and filtering distractions. Can you figure out what part of the course needs your fullest attention, and which parts you might be able to take nearly as fast while thinking about the quiz question? It's a biathlon for motorheads.

The scientifically minded part of me wants to take a little extra time and add a free run through the course for each contestant at the beginning and end of the event, with no quiz questions. That way everybody gets a baseline time for the course, and it's easy to find out how much the distraction hurts our driving. Some studies say that a hands-free phone is just as distracting as a handheld one. Wouldn't you love to find out exactly how true that is for you?

I know it'll never happen -- it's hard enough to reserve autocross sites without the additional complications of an untried event format. But I'd sure love to try it. If any researchers with funding for distracted-driving studies are reading this and want to use the idea, count me in as either a helper or a study subject.

I'm calling it QuizCross. You heard it here first.

Caldera (2012) from Evan Viera on Vimeo.

CALDERA is a project close to our heart, not least for being made by many dear friends and being the co-spawn of our time at Bit Films of Hampshire College. Now that the film has gone through festivals and entered the wilds of public viewing, congratulations again to the entire crew for all its well-deserved acclaim! (Below, some information from Evan reminds me how much debate Caldera has stimulated, and how interesting its been to see the way interpretations meet and diverge.)

SYNOPSIS
Through the eyes of a young girl suffering from mental illness, CALDERA glimpses into a world of psychosis and explores a world of ambiguous reality and the nature of life and death.

DIRECTOR’S STATEMENT
CALDERA is inspired by my father’s struggle with schizoaffective disorder. In states of delusion, my father has danced on the rings of Saturn, spoken with angels, and fled from his demons. He has lived both a fantastical and haunting life, but one that’s invisible to the most of us. In our differing understanding of reality, we blindly mandate his medication, assimilate him to our marginalizing culture, and entirely misinterpret him for all he is worth. CALDERA aims to not only venerate my father, but all brilliant minds forged in the haunted depths of psychosis.

HISTORY
CALDERA was helmed by Evan Viera (Director/Composer/Co-Writer) and Chris Bishop (Co-writer/Animation Supervisor/Story Artist) and was produced at Hampshire College. CALDERA was the first film to go through the Bit Films Incubator Program, where founder and professor Chris Perry (co-producer/editor) invites orphaned independent films to be made on campus with the College’s students and resources. MANY students and industry professionals generously donated their time to the making of this film. (See Vimeo link for full list of credits and awards).

Get the production files here

licensed CC BY SA 3.0, you are free to use these so long as you use the same license, and attribute Bassam Kurdali | URCHN.org

Hope you have fun!

Over the past couple of months, Satabdi has been working during her Outreach Program for Women on geocode-glib, and Zeeshan more recently joined us to help with cleaning up some of the code.

As Satabdi's program is now finished (though not her involvement!), and a new GNOME development cycle has started, I'll try to explain where geocode-glib fits in, and answer some questions on the future of Geoclue.

(Reverse-)Geocoding

First and foremost, geocode-glib is a geocoding and reverse geocoding library. It uses Yahoo! web services for this, though we're investigating using Nominatim for this in the future.

This replaces the convoluted implementations for those two services in geoclue (3 if you include Address as a service). The API should be mostly stable now, and we'll soon start porting a few applications to it (Evolution and Empathy come to mind).

The library also includes a GeocodeLocation object. This will be useful later.

GeoIP

geocode-glib, thanks to Satabdi's work, includes a GeoIP server, to be installed on GNOME servers eventually, which uses data from MaxMind to  locate a user connected to the Internet from the IP address. We also have a client library to access this server.

This is usually good enough to locate a user in a city, or a country, which would help us with many integration points in GNOME, such as the upcoming Date and Time panel re-design.

But this code isn't really for you, app developers.

Geoclue

A fine project, but the codebase is showing its age (dbus-glib!), and the decision, well, not to take decisions on which backends to use for various services make it fragile. This is a maintenance problem, both for in terms of making sure all the services are kept working, and that geoclue itself is kept stable.

So we'll start a reimplementation of Geoclue. The goals are:

• Trimmed down API, just for positioning
• Smaller, but more integrated, selection of ways to get the positioning (GPS from your integrated WWAN modem, Wi-Fi AP data, IP address, no discrete GPS or manual location)
• Power-saving, by aggregating requests from all the applications
• and finally, privacy, where only applications that you allow to request your location can get it, and only with an accuracy as needed for the application.

The code currently in geocode-glib for IP geocoding will likely move there when the project has been kickstarted.

I hope this clears any misconceptions people might have about geocode-glib, or, more likely, about the future of geoclue.

Today a new cool feature arrived in Krita development version (many thanks to Boudewijn Rempt who did it): the “LayerGroupSwitcher”.
Basically it’s just two little shortcuts (not assigned by default), that switch to next or previous group layer, hiding the previous group and showing the current one.
With this it’s much faster to work on an animation or image sequence using group layers to separate frames.

The main problem I have with this method is the lack of an automated light-table, so as a workaround for now I use a clone layer of previous/next frames inside my current group, with lower opacity and a red or blue color over it (check the screenshot for layer stack details…)

A very quick test anim to show that it works, download it here.

Going to sleep last night I started thinking about inflation, which meant that I got to sleep later than I'd wished, but it also lead to some interesting thoughts about where the US economy is currently. Popularly inflation is considered bad, or something that needs to be controlled through monetary policy. And that we have. In the US we've seen record low inflation rates, to the point where we've lowered interest rates to where it's practically a useless lever on the economy. It seems to me that we need higher inflation.

Inflation powers the creative destruction that makes capitalism work as an economic system. For value to increase relative to inflation we must reprice things, and they must continue to have more value to the people in the economy. If weak products just stick around, with their current value in tact, they effectively stagnate as they don't get ground under the treadmill of inflation. This is the evolutionary gauntlet that destroys those who are not fit to compete. Perhaps capitalism is driven less by an invisible hand and more an invisible treadmill.

We can as a country control inflation and increase it artificially through policy in government. Policy programs like farm and transportation subsidies ensure that food prices don't rise. Starting to remove many of these would force farmers to charge more, which in turn would effect derivatives like meat and dairy to raise prices, effectively pushing inflation into play.

The economy is an ecosystem of stored value, consumers and producers. By eliminating inflation as a mechanism inside that ecosystem we've allowed the balance to be shifted and created a system that is off balance. We should adopt legislative policies to increase inflation.

I’ve started snapping and posting photos again.

With the exception of the zoo photos from last year, most of these are from the recent months. A few are even from the past week or two.

You can view larger versions by clicking on each photo
or by visiting my photo collection at Flickr.

Many months ago, I released a high-quality vector version of Tux that I made in Inkscape as SVG and PNG.

Somewhat recently, I needed to make a black and white version for a project.

You can get both the color and black and white versions in both SVG and high-res PNG at the Tux github repository.

These versions of Tux are licensed under the public domain, but if anyone asks, Larry Ewing made the Tux mascot in the Gimp and I made these versions in Inkscape.

Here are the links for this Tuesday – a bit late, I managed to set the timer the wrong way…..

[UPDATE] I forgot one important link: A new version of G’MIC, numbered 1.5.5.1, has been released. It is really impressive. And David Tschumperlé’s car broke down and leaves him in a bad financial situation. David is the guy behind G’MIC, you know what to do with his donation buttons, don’t you?

Patrick David has a close look at skin faults. With Blue Light. And provides even a script for that. After reading that you know why RED light is more romantic…..

Do you remember LightZone? A really good program for Linux and MacOS, but proprietary code? No costs but threatening to charge in the future? It is now Free Software! Check it out – I want some opinions if I should go into it!

GIMPHELP.ORG has a script collection that has all compatibility problems with 2.8/2.9 ironed out. And more stuff.

Lens Fun is a library for correcting Lens Errors in digital images. And there is a plugin for GIMP to correct lens distortions using that plugin.

Setting up the Wacom Tablets in Gnome – I have to confess I just found that…..

Shotwell got way better RAW files magagement and a very special changelog entry.

The Bayer Filter is the usual way to get colour into the colour blind sensor and eat a ot of light on the way.. Now Panasonic has something new and brighter, Physics at it’s best. Let’s hope that they do better than the Foveon Sensor.

No DSLR, variable weather, playground and patient little blonde girl at hand for test shots? Try the camera simulator.

Nikon has a new firmware out for my camera!

“The world’s best interview show about photography and all things creative.” His own words. But I like it very much!

Up to next Tuesday with an epic battle between JPG and PNG