publications

GIMP redux, full GEGL ahead

22 January 2012, 17:36

Recently I have been receiving requests to clarify the GIMP UI strategy surrounding GEGL, so I thought I’d write a catch‑up blogpost about my 2010 LGM lecture. There I tackled this GIMP UI challenge: a first outline for a UI for a fully GEGLed GIMP. The thinking about this UI, and the discussions with Øyvind Kolås (the GEGL‐meister himself), have been going on for years. Its introduction will be the most profound change to GIMP in the foreseeable future.

two minutes of fame

I started off my lecture with introducing GEGL, the graph‐based image processing engine that is slowly, but surely, being integrated into GIMP. I could spend quite some time taking us through the complete GEGL graph (linked) below:

…and this is only a small one. Instead, here is the essence of it in four easy steps:

1. there are input boxes that load an existing image, or render some vector shapes or text;
2. there are chains of operation boxes that perform things like blur or change opacity of whatever gets fed into them;
3. there are composer boxes that take two inputs and put one over the other, combining them in a certain way (think layer modes: normal, dodge, multiply);
4. there are output boxes that either display the grand result on a screen, or export it to graphics file formats like png or jpeg.

so…great

Thus GEGL processes graphics by hooking up the boxes, inputs–to–output. Why does that matter? Well, because it is non‐destructive: the images in the input boxes are never modified.

If the structure of above graph is written to a file—apart from the input images, all other boxes are just snippets of XML—and a year later it is re‑opened in GIMP, then each of the operations and their parameters; each of the vector shapes or text can be freely changed. Even the input images could be swapped out for different ones. The result is a changed image composition, without any loss of quality.

It is exactly this promise of non‐destructive editing that played a big part in me joining the GIMP project years ago. I could see how that could lead to the end of some of the major workflow bottlenecks in today’s graphics software.

UI modelling

The integration of GEGL in GIMP is a disruption; it changes the rules of what one can do and how one can work. This is not a bad thing, it is a refreshing change. An interesting question is: how does the user interaction of GIMP have to change, in order to harnesses all this new power? In general there is a big urge, especially with developers, to just display the graph on the screen:

I call this the boxes and hoses model. If it looks familiar to you, it is because it has been around for decades: it is called visual programming. Which again explains why developers tend to choose this type of solution. One day a direct representation of the graph will appear in GIMP, as something extra. This is because the product vision defines GIMP as (also) being ‘a platform for programming cutting-edge image processing algorithms, by scientists and artists.‘

activity centre

To find out what the main UI in GIMP should be, we take from the product vision what the main activities are that GIMP is made for: ‘high-end photo manipulation’; ‘creating original art from images’; ‘producing icons, graphical elements of web pages and art for user interface elements.’

As a next step, it pays off to look at the nature of these activities. Users start with images or basic shapes (vectors) and apply image manipulation operations, one after another, to achieve the desired result. Users organise their work in layers and GIMP composites the result. Schematically that looks like this:

In short: a work (a composition) consists of layers, each with its sequence (in time) of operations. Now we got the start of a model for the UI. That list of layers we know already, as the layers dialog. The sequence of operations for the layer, we can call that the operations dialog:

disclaimer

Keep in mind that the user interaction shown in the image above, and all the ones below, is not a true mockup. It is more a diagram—with in part grotesque proportions—to show the principles of how the UI works.

We can see that the four GEGL elements are covered: The image material to start with: loaded pixels or rendered vectors; the layers that control the bulk of the compositing; the chains of operations; the output to the screen in the big image window.

Yes, the image window is the place for judging one’s work and for doing the actual work, hands‑on. The image window deserves a couple of times more screen space than any GEGL graph manipulation. Reversing this relationship (as shown earlier) is completely disregarding the nature of the activity.

back to the future

Adding an operation works as before: use a toolbox tool or invoke a menubar item. Here Gaussian blur is invoked and it appears at the top of the operations list:

Now it gets more interesting: revisiting the past. No matter if it was done five seconds or five months ago, one can recall any previous operation applied to this layer and readjust it. Here the curves for this layer are revisited. While adjusting, the output updates through the complete chain of operations, including colorise and blur:

A lot of layers dialog behaviour can be reused for the operations dialog. ‘Eye’ toggles can be used to show/hide the operations:

Drag and drop can be used to rearrange the order of operations. The result of that may turn out to be more subtle than you think. Because GEGL processes everything in 32bit floating point, it will be much harder to get the rounding and clipping artefacts you get with 8‐ or 16‑bit integer processing. Only when an operation does not commutate by nature (i.e. the order matters), then it gets interesting to experiment with the order of operations.

Of course copy and paste of operations, between layers of the same or different files works. Dragging and dropping of operations on another layer copies or moves them, a modifier key (shift or ctrl) will sort that out. And before I forget: selecting some operations in the operations dialog and invoking ‘Make macro’ would be a good, natural way to get that started.

the holy trinity

Before we continue with more GEGL user interaction, here is a pop quiz. I took this b+w photo of the brilliantly named Kloten airport and coloured part of it red:

My question is: how did I apply that red?

1. directly with a tool from the toolbox;
2. making a selection, then invoking a menu item;
3. using a layer with a layer mask.

Well, I have forgotten how I did it (it’s been a while) and you will never guess. My point is that it does not matter. All three methods listed above are a combination of an operation (apply red) and a greyscale mask, controlling where it is applied and how much. All three methods are fully equivalent, it does not matter to the software—or the viewer.

It does matter to users. Given the context, composition structure, the graphics material and the end‑goal, each user knows exactly which of the three methods she/he prefers. There is a million different use cases and only the individual user on the spot can take the right decision. It follows that each of the three methods is equally important and needs to be equally available to users. This I call the holy trinity of image manipulation.

pagan practices

However, at the moment, you quite often see the following: ‘if you want this feature, you’ll have to use it on its own, extra layer.’ This is layer abuse. I get misquoted on this so let me clarify: users never abuse layers, developers do. Here are some examples of layer abuse:

• the only way to do a non‐destructive operation is via an adjustment layer
• only one vector shape per vector layer;
• only one block of text on a text layer;
• the output of a filter plugin is always put on a new layer;
• the result of using a toolbox tool is always put on a new layer.

The problem is with ‘only,’ ‘always’ and ever more layers, whether users want them or not.

reformation

The abuse listed above is straightforward to fix. Quite a bit of it has to do with enabling users to redo or revisit the image manipulation. That is solved by the operations dialog.

Furthermore, there can be as many vector shapes and text blocks on a layer as one likes. Just show them—and stack ’em—as sub‑layer elements in the layers dialog. And when then one of these sub‑layer elements is allowed to be actual pixels, then it is clear that the whole notion of special vector/text layer can disappear:

Layer abuse has to stop. Developers should never force users to use another layer. Only users decide how many layers they want to use, purely as their own personal way to organise their work.

more blessings

So apart from that no image manipulation is exclusive to a layer, what are further implications of the dogma of the holy trinity?

paint with anything

Yep, with anything, also all the plugins that appear in the Filters menu. Also the obscure ones that you and I, and anyone on the GIMP team have never heard of. Just dip your brush in it and smear it on the canvas. Thinking of combining it with paint dynamics just blows my mind. It just takes one tool (Filter brush?) to enable this.

adjustment layers with anything

You see, I have nothing against accomplishing things with layers. It is perfect when you got a collage made out of dozens of layers and then want to apply some treatments to the whole thing. It just takes one adjustment layer with any number of operations to get that done. Again, with anything.

behind the mask

As mentioned, all three image manipulation methods consist of an operation and greyscale mask, controlling where it is applied and how much. The interaction for these masks can be analogous to that of layer masks:

This means that both the parameters of the operation and also the ‘where and how much’ can be revisited and adjusted, a second later or a year later.

in triplicate

By now you may be thinking ‘wow, every image manipulation must be possible in three different ways, does that mean that one day GIMP will contain three times more stuff than today?’ Well no. I have already mentioned two measures—Filter brush, adjustment layers with anything—that will make large strides towards fulfilling the holy trinity. And even today the trinity is partially in place at GIMP.

Take for instance composition, putting pixels on top of pixels. Sounds like the exclusive domain of the layer stack, no? Well, even today you can use toolbox tools to do the same thing: the Clone tool and its 90%‑identical cousin, the Heal tool. And the menu item to compose is called Paste. Yes, the current layers dialog interaction while pasting should go. The GIMP team is agreed on this for years. Instead paste is an operation on the current layer:

weird science

There is a fifth element to GEGL graphs, that I have been keeping under wraps in this blogpost until now: cloning. This is taking an in‑between result in the GEGL graph, anything from a simple vector to a huge sub‐tree, and ‘teleporting’ one or more clones of this result to another position in the graph:

The original and the clones can have the same or a different position on the canvas; undergo the same or completely different operations; be composited in the same or a completely different manner. The magic is of course in that when the original (the input to cloning) is updated, every clone immediately updates, with all further operations and compositing applied on top. This is going to be liberating, because of the amount of work this saves.

Let me give an example. Let’s take the scan of a snowflake and fix it up with a number of graphics operations. We clone the result 99 times and spread these over five layers to compose our snowscape. We make ever flake a different size and a different colour. Already laborious, no? And now, we decide we are not satisfied with how refined the snowflakes are. Solution: fix the original with more/less/different/updated operations, all 100 flakes will immediately show the improved refinement—in their different sizes and colours.

send in the clones

My plan for the user interaction of cloning is to make it a variant of pasting: Paste as clone. This includes doing further operations on the pasted (as clone) material, before closing off the paste (you can always revisit the paste operation and modify all of it). And as Ville Pätsi pointed out a while ago, there needs to be a way from each clone to access the original. A button or link on the Paste clone operation in the operations dialog might do the trick.

There is more tricky stuff coming up with this cloning, like cloning layers or layer groups. And to go fully meta on this: I am asking myself why chains of operations cannot be cloned and applied to different input material. But Øyvind is not up for that.

two more things

To wrap all this up I have two benchmarks that have developed out of the GEGL discussions. They are alternate manifestations of the holy trinity and they are serious tests of the direction the GIMP user interaction is taking.

First, in a future version of GIMP, if users really envision their work as one single layer—not that unusual with photographs—then they will simply be able to close the layers dialog. Their work will not be impeded in any way by this, everything is still available to them (twice, as toolbox tool and menu) with no limits in the sophistication with which they can express themselves:

Second, in a future version of GIMP, if users are really not interested in switching operations on/off; rearranging operations or revisiting the past, then they will simply be able to close the operations dialog. Their work will not be impeded in any way by this, everything is still available to them with no limits in the sophistication with which they can express themselves:

You could even combine the two benchmarks and GIMP would still work, without a hitch.

aftermath

Directly after the lecture at the LGM, Øyvind Kolås pointed out one flaw, one thing I had not thought of: those greyscale masks, that play such a central role, are not pixmaps. They are GEGL sub‐graphs themselves. Which creates the possibility of near‐endless drill‐down: operations with greyscale masks, which contain operations with greyscale masks, which contain… et cetera.

Is that a fatal flaw? Is that going to blow up my plan to reduce the complexity of the GEGL graph to a linear list of operations? Do we just have to confront users with the whole graph? Let not kid ourselves about the complexity of that graph. In practice, I’d say that a simple GIMP file starts at ten times the number of boxes in the example at the top, quickly moving to a hundred times and then beyond.

not my problem

To developers—especially the ones that are working up to their elbows in GEGL graphs—this problem looks like one of navigating the graph and making edits. But to me it looks like another problem needs to be solved: how can users navigate their working context? Already today GIMP users are doing this navigation. Which layer, which layer mask are they editing, or is it the quick mask?

It will have to wait for another day, but when this context navigation is going to be designed, the one thing not to lose sight of is the image window. Everything evolves around it, including this navigation, and feedback of the working context has to be inside it. I certainly think we can do a better job than currently happens with the layer masks.

And when this context navigation has been designed, taking into account the holy trinity and the two benchmarks, then the operations dialog can show the simple list of operations performed in that context, in their natural order.

Labels: GIMP, GIMP redux, lecture, practical, product vision

—ps

30 comments, link‐ins, forward this posting:

GIMP redux, single‐window mode

18 September 2009, 19:19

This blog entry covers the final part of my talk at the libre graphics meeting this year, after dealing with the schmuck and squaring a circle. It will also be pure falsification of history, Soviet‐style: I used my talk to kick off a discussion and to start the design process. Most of the interesting things I am showing you today were not even conceived when I delivered my lecture.

real history

Here is what was presented at LGM: First, I set the mood by showing a selection of single‐window contributions from the UI brainstorm:

The high number of contributions in the single‐window category confirms that this is a major issue where action needs to be taken. The many forms the contributions take shows us that a measure of flexibility and configurability is needed.

Next, I reminded everyone that it is a fifty–fifty world: about 50% of GIMP users love the multi‐window interface of today and do not want to lose it, about 50% of GIMP users would love to move to a single‐window interface.

one switch

With the world fifty–fifty split, we will serve them with one switch in the Windows menu, switching between multi‐and single‐window mode. I used the mock‑up with the beautiful orange sports car from the brainstorm to demonstrate the basic idea (no real UI design implied here).

When set to single‐window mode, each document will appear in a tab:

the toolbox and inspectors can be ‘torn off’:

here the toolbox is side‐docked back and it is shown how the inspector floats:

and last, inspectors can be made multi‐column. Here, another column has been created to allow more dockables to be organised:

The eagle‐eyed will see that there is quite a bit of fudging in those images, so don’t sweat the details.

three problems

I closed off the talk with three things that were bugging me at the time:

no tab tear‐off

tearing off a tab and making that into a separate window—as seen on web browsers—would make our single‐window interface into a multi‐window interface. How annoyingly inconsistent.

no side‐docking, to multi‐windows

both toolbox and inspectors are unique for the application and by nature there are multiple window instances. That means it is unnatural to dock the toolbox and inspectors to windows. It is however possible to introduce multi‐column inspectors for multi‐window mode.

no image comparison

With tabs, only one image is visible at the time. Thinking about clever plans to see two images side‐by‐side in split panes, one sees immediately the confusion rising: which is the image that the menus perform operations on. Which one is shown in the layers dialog?

tomorrow starts now

So far, so predictable. Here is where the interesting stuff starts. After my talk I had a good round of brainstorming with Martin Nordholts on the tear‐off and comparison problems. The result of that is what I call the polaroid.

To demonstrate it, let’s say one is still working on that lovely orange sports car and in a second tab we have loaded this image of a cool Ferrari Berlina:

Now we want to compare our orange creation to the Ferrari. All we have to do is to tear off the Ferrari tab and presto: a polaroid of it appears:

This is not a GIMP image window. It is not even a window, the window manager will know nothing about it. We avoid making it look like a window, down to ignoring the theme colors and executing the control strip at the bottom in paper white. You can move and resize the polaroid to your heart’s content, as long as it fits inside the GIMP window. You can zoom, pan and look at it, and that’s all.

voluntary confinement

That last point will be very hard to do, because everybody will be thinking of one little feature they would like to add, for themselves. But we have to be strict here to avoid mass confusion: every toolbox tool, every menu item, every dialog (in an inspector) only operates on the front tab—the orange car in this case— and never on a polaroid.

For example, when I discussed these plans with GIMP‐usability contributor Ellen Reitmayr, she asked: ‘so can you then select and copy a bit of image from these [polaroids]?’ Good question. After realising that this would mean interacting with the layer stack and selection tools, the answer has to be no.

It is however possible to open multiple polaroids of the same image. And also of the image in the front tab, where one is working on:

As you can see they can overlap and they will have to have their own stacking order. Just click on a polaroid to raise it to the top. The final thing you can do with a polaroid, is to close it…

the decline and fall of tabs

This is how things were more or less when I returned home from LGM. At that point there were still three things that were bugging me about using tabs in single‐window mode:

1. too easy, too fast: the tabs got adopted from web browsers, without much thought;
2. it would be rather logical to use a thumbnail on the tab itself to identify the image;
3. sign of the times: the web browser folks themselves are looking at solutions beyond tabbed browsing.

And pretty soon I was looking at the image parade you see these days in many a photo app and viewer, mainly triggered by a visual association with a row of tabs with thumbnails on them:

There are some really interesting possibilities, when we replace tabs with that. Let’s try it out:

We see three open images and like you would expect, clicking on an image makes it the active image (the ‘front tab’) and dragging any of them up or down enough ‘tears’ it off to become a polaroid. A mouse‐over tooltip will display more info for each thumbnail, for starters: the filename.

history repeating

Now let us go a step further and not only show open images in the parade but also recent files that have been opened or worked on, the history:

Everything is in strict chronological order: open a file and it moves to the front of the parade. What I find very intriguing is that the notion of which file is open starts to blur. Having a file being loaded from disk becomes a side effect of clicking it to make it the current file. Similarly GIMP can decide to start closing files with no unsaved changes when there are too many of them open and memory gets tight.

My current thinking is that it is not necessary to mark files in the parade as being open. The concept quasi disappears for users. The white stars indicate unsaved changes.

One or more graphics files that are dropped on the parade get added—cued up if you want—right after the open files. Just as useful will be that a folder dropped on the parade cues up all the graphics files in it. Current work + history + cued up work + polaroids has a lot of potential, I think.

the Midas touch

I realised that it would be an eyesore and an absolute waste of space to introduce a scrollbar for the image parade. Still, it is going to scroll. It happens to be that in the last couple of years I have been working for two large companies on the interaction fundamental’s of iPhone competitors.

So how about using touch UI? A flick or a drag along the parade scrolls it; a push slows down, then stops the scrolling; a tap on a thumbnail makes it the current file; a flick or a drag of a thumbnail perpendicular to the parade creates a polaroid: it is perfectly doable, using mouse, trackpad or tablet.

non‐preferential customisation

All we need now, is some more flexibility. First, I think everybody will have their own idea what the right size for the image parade is. From pretty small:

to pretty big:

I think any size in between those has its purpose and why could that not depend on what one is doing next? Simply grab the dividing line between parade and canvas and adjust to fit your mood. Next, does it has to be at the top of our window? Left, right and bottom should also work:

I foresee every GIMP user having their own sweet spots, when it comes to combinations of size and orientation of the image parade for the type of projects they do.

raising the dead

It will not be necessary to introduce new items in the preferences dialog for anything I have shown you here. In that light I called during my LGM talk preferences ‘the graveyard of many a good idea.’

For configuring the image parade I have already built in a settings pop‑up in all the screens you see above. The top/left/right/bottom setting will be in there, as will be one for controlling the amount of history. Something along the lines of: 48 hours; a week; a month. And for those who never look back: a setting for no history at all.

red hot anticipation

To wrap up, for about 50% of GIMP users the good news is that single‐window mode is coming, complete with tear‑off toolbox and inspectors; multi‐column inspectors; polaroids; image parade with history and cued up work; touch UI and quick and easy customisation.

And it is coming faster than you’d think. Martin is ready to develop it for version 2.8 and this blog post was hotly anticipated to outline my complete plan.

For a different 50% of GIMP users the good news is that multi‐window mode is here to stay. It will benefit from multi‐column inspectors being introduced. But I actually expect that once single‐window mode is out there, there will be pressure from the community to have a look if multi‐window mode cannot be done a bit more, well, modern.

Labels: GIMP, GIMP redux, lecture, practical

—ps

82 comments, link‐ins, forward this posting:

GIMP redux, squaring the CMYK circle

19 June 2009, 17:14

Before we return to the schmuck, there is going to be a small intermezzo.

indexed

In the future GIMP will lose its indexed mode. As I wrote last time: creative work is RGB work. Ages ago I made a solutions model how GIMP could still support producing indexed images. This means doing the creative work in RGB, here shown at 200%:

When it is time to prepare an indexed version, a projection screen can be pulled over the image window that shows how the user‐controlled indexed set‑up works out, in this case a modest 16 colors:

The core of the solution model is that this projection is again a surface, that can be worked on, to make the corrections that are specific to this indexed set‑up. The non‑destructive nature of GEGL makes it possible to reapply these corrections after more creative development, or to adjust them at a later stage.

It is from the projection that an export to indexed file formats is performed.

a coin drops

Cut to the chase: it was while reading the GIMP review on ars technica by Dave Girard, where he used ‘vinyl’ and ‘audio masters’ to describe CMYK and RGB. Suddenly I could see the parallels with the indexed situation.

going to press

Here is my solutions model for preparing artwork for the printing press in GIMP.

By now it should come as no surprise that all creative work is going to be in RGB. This has also the benefit that at all times all GIMP plugins work, without a chance of color shifting conversions. Here is a schematic representation of creative work on a jazz poster, built out of four layers:

jazz posters, found at: polish jazz art in nyc

At any stage during the project, when there is a need to work towards the printing presses, a press projection can be pulled over the image window that shows how the user‐controlled plate set‑up works out, in this case a five‐plate job:

The layer stack—used in the creative development—is not used in this view. Instead what matters is the user’s plate set‑up, which is displayed and controlled as a similar stack. Each plate is fully editable: painting, curves, gradients, (lots of) plugins, anything goes. This gives us the required full control over the plates.

Note also that the colors in the press projection are already slightly different than that of the normal view, because the color profile of the printing press is taken into account.

it’s all a set‑up

Everything hinges on the particular set‑up of the press projection. This is where users freely set—as required—the number of plates and what ink/paint/lacquer is used for each plate. Any color will be possible and we can support metallic paints and matt/glossy transparent varnishes, using a bit of animation on the projection.

The set‑up is also the place where the more tricky stuff is supported: overprint and trapping, rich blacks, combined ink limits: it is probably only the beginning of how advanced this has to get. I had not forgotten about this.

CMYK + spot

In general the plate separation is calculated from the composite image that feeds into the press projection. However there will be full flexibility to map the content of any layer directly to any plate. For instance that light blue text in our example: it can be directly mapped from its text layer to the light blue plate, bypassing the composite.

Here is also the one and only time that CMYK will play a role in GIMP: as a small configuration file that is a default (OK, the default) for the projection set‑up. Nothing more, nothing less.

agile development

Since the press projection can be freely pulled over the image window and then flipped up again, GIMP will be able to fully support the required creative workflow. The mosaic below shows GIMP tracking in 16 steps real‐life work on either the creative concept or on the printing plates:

The non‑destructive nature of GEGL makes that whenever the press projection is pulled down, the updated artwork is re‑separated and all previously made plate optimisations are re‑applied on top. When the underlying artwork changes significantly, then every existing plate optimisation step can be validated by users and where needed adjusted.

The result is maximum creative flexibility and minimal rework of the plates over the life‐cycle of the file. Ah yeah, of course the whole press projection will be saved in the GIMP file. At the end, it is from the press projection that an export is performed to the file formats appropriate for shipping to the printers’.

what about CMYK files?

When a received CMYK file is to be used in new creative work, we already saw that ‘it needs to be imported and converted to RGB.’

When further fine‐tuning for the printing press is the goal, then the solution is to shove the CMYK file straight into a press projection, as a static, pre-defined separation. Each plate is then still fully editable as outlined before.

the non‑issue

That concludes my current take on ‘not quite the CMYK’ issue: bringing artwork to printing presses. Actually at LGM it turned out to be a hot topic in quite a few talks held by several projects. My contribution of squaring this circle fell neatly into place there.

Stay tuned for the last part of my LGM talk: a single‐window interface for GIMP.

Labels: GIMP, GIMP redux, lecture, practical

—ps

6 comments, link‐ins, forward this posting:

GIMP redux, enter: the schmuck

20 May 2009, 09:56

‘What about schmuck?’ Katrin Alt said, when I explained to her about my work on GIMP. —Excuse me? ‘You know, what about CMYK.’ —Ah, that is a long story.

So started my talk at the libre graphics meeting this year. I will cover it in three separate blog entries, the first one being about schmuck.

hot debate

GIMP’s lack of CMYK mode is one of the hottest topics in the comments sections out there. Also fiery is the resistance by GIMP’s maintainers to introduce such a mode. In March the CMYK issue returned during a long thread on the GIMP developer mailing list. Quite a few users who seriously use and need color separations chipped in. It gave me a chance to understand the activity, both from a technological and users’ side.

The first thing to understand about the CMYK issue is that it is not about CMYK. The issue is bringing artwork to printing presses. And I mean serious printing presses, with operators, print runs and hydraulic parts. Not that very expensive, high‑spec printer that sits in the corner of the designer’s office, that one is still covered by openPrinting.

flex plate

Unlike for the printers that you and I use, with printing presses the plates that do the printing are freely configurable. Any number of plates can be used with literally any kind of ink/paint/lacquer, for cost or quality reasons. That there is a world beyond CMYK is something that Øyvind Kolås has been pressing on me, for instance, during a discussion last year at guadec.

During the mailing list discussion mentioned above, Louis Desjardins wrote to have a look at packaging for examples of how complex the plate set‑up can get. So I did, the next time I made a coffee. Turning over the milk carton, I found the marks for a seven‐plate print job, none of which was cyan, magenta, yellow or black.

mind the gap

Now, I am not saying that GIMP is the application for designing milk cartons, but the complexity of printing such a cheap commodity really shows that hardwiring a CMYK mode into GIMP would be a serious case of under‑design. Why go through all the trouble of introducing that when it cannot deal with a simple poster, printed in black + orange, or the milk carton?

2. control

The second most important thing to understand is that preparing artwork for the printing press means needing total control over the plates. This not only means a flexible plate set‑up as outlined above. It also requires that every bit of experience that a user has with the particular printing press can be used to fine‐tune each plate. I am not underestimating what this is going to take: basically the full GIMP functionality, including any plugin.

3. creative work

The third thing to understand is that creative work is on‑screen work. We must focus on the loop that exists between users, the tools they use and the image that appears as a result, again inspiring the next step of users. If I may be so bold: during creative work the image does not exist on disk, or in RAM, it only exists on the screen.

The natural medium of the screen is RGB pixels. That is why I say: creative work is RGB work.

4. what about CMYK files?

If one receives a file in CMYK format, we know by now that it was destined for the printing press—actually, one particular printing press that is is supposed to be fine‐tuned for. With that knowledge there can be two reasons we are touching it at all:

1. it needs further fine‐tuning for that press, best done in CMYK;
2. it is a found‐image that goes into a new creative work, for that it needs to be imported and converted to RGB.

5. workflow

The last thing that we have to understand about the activity is how eclectic real‐life workflow is. In theory it is simple: one creates artwork, separates it for the plates, then prints it on the press. That is also the clean model when it comes to color models.

Creative users live a bit more iterative: start creating; set up the separation to see what is possible in the end; fine‐tune that; create some more; fine‐tune some more; get feedback and adapt the creative work with that; get a print proof and do a wholesale overhaul of the separation and fine‐tuning; some last‐minute creation; print it on the press.

It is easy to see that the rigid theoretical workflow does not support creative real‐life. The rigid workflow is the the norm in software today and it inhibits creative users to work as freely as they can imagine.

form‑fit

Now that we fully understand the activity, we can work on squaring the circle. Read all about it next time.

Labels: GIMP, GIMP redux, lecture, practical

—ps

5 comments, link‐ins, forward this posting:

GIMP redux: intro

12 March 2008, 11:39

Lately, a couple of things have started to orbit each other:

GIMP UI analysis

This is the current phase of our redesign project. And although a consensus has formed among my team about the gist of it, not having it written down as a coherent system means that no coherent improvement can be made to the GIMP UI. Only with a finished analysis can I drive the roadmap that stops GIMP going the way of the dinosaur.

what’s up?

People have been writing me—thanks btw.—asking when they are going to see the results of the redesign project. Renovating a big application is going to take time. In the meantime, it is a good idea to show where we are going. Our project wiki is a place to see us work, but it is not a great narrative to read.

libre graphics meeting 2008

I was already asked for the topic of this year’s lecture. What could I cover that would advance the deployment of interaction architecture in ‘pro’ graphics applications? And for that matter, advance ‘pro’ graphics applications in general?

the big picture

Last and foremost, a nagging feeling that the long list of meso‐level issues in our rough outline are part of a bigger issue, which has to be addressed first. Not seeing the wood for the trees, I need to helicopter out.

bird’s eye view

So I have set myself a challenge with the title of my libre graphics lecture: ‘GIMP: a new simple interface for a complex application.’ That is the big picture. The GIMP product vision mandates it to be a deep, feature rich application that takes commitment to master.

But at the same time there is plenty of scope to radically cut down the visual noise in the interface, improve user efficiency and increase the room for creativity. Only big steps in these departments will ensure that there is a future for GIMP.

live and let…

I have got two months to prepare for lgm and I will do that right here. In a series of ‘GIMP redux’ articles I will go top‐down through the UI. These blog entries will at the same time pop up in the wiki as chapter seeds. There they will evolve, building up the analysis.

There is room for review and feedback, here in the comments, over on the developer list, or via the brainstorm. That will drive the refinement of the analysis chapters.

So there you go: the big picture of what is going to happen to the GIMP UI will be developed in the next months, in time for the lgm 08. And you will read all about it here.

Labels: GIMP, GIMP redux, practical

—ps

2 comments, link‐ins, forward this posting: