Leonardo is getting closer and closer to the point where you can use it for real work, but there are still a few things missing:

1. HUD-notifications (worked a long time ago but the code has decayed)
2. Custom brush-stamps as opposed to just ellipses.
3. Add, remove and rearrange brush-preset list.
4. Merging and changing Z-order of layers.
5. Better UI for layers.
6. Drag-n-drop from the export bar.

All user tests were conducted in full-screen mode which meant that no user could access the menu bar (this should be changed until next user test so that the menu bar “auto hides” in full-screen mode).

1. All participants requested layers (we have layers but no UI for it, yet).
2. Although no participants explicitly said so, all of them would have enjoyed a brush-preview when they where adjusting the brush settings.
3. All of the participants instantly understood how to use the new color picker (wheel + triangle) and two of the participants loved it more then any other color picker they have ever used.
4. All participants seamed to like the new default eraser (its own context plus pressure sensitive diameter).
5. Two of the participants complained that the diameter slider was “too sensitive to get the exact diameter you want” and one of them requested being able to enter the diameter numerically from the keyboard (current diameter slider: 207 pixels wide, from 0.5 to 1500 with gamma 2.5).
6. Two of the participants did not know what the difference between Flow and Opacity is and could not figure it out even after some testing.
7. All of the participants used the Hardness parameter quite a lot.
8. Two of the participants requested being able to change the background color (currently possible, but only from the console).
9. Two of the participants asked if it would be possible to select and move a portion of the canvas (not currently possible).
10. Two of the participants tried to hit the Z key when they were told to zoom (doesn’t work).
11. One participant tried to “double click” the space-bar when told to snap the view (doesn’t work).
12. None of the participants noticed the “zoom box” at the lower left corner even after they were asked to zoom.
13. All participants seamed to like the rotate-canvas-feature and understood how to move the pivot point.
14. One of the participants asked “what is the current DPI?” (he knew he was at 100% zoom but he didn’t realize that’s how you are suppose to know the resolution you are at).
15. All of the participants loved the draw-straight-line feature but requested more advanced functionality. One of the participants (Kalle) requested being able to draw curves in a similar fashion and told us it’s very important to be able to offset the curve, without changing it, to draw repeating patterns.
16. Two of the participants requested being able to get some sort of “A4-paper reference” that just hovered above the canvas.
17. None of the participants realized that you could move around the color picker and brush settings window.
18. We forgot to test if the user realized that it was possible to pan around the canvas using the rulers.
19. One of the participants thought the F key would be more logical for flip-horizontal then the H key.

1. Martin loved being able to rotate the canvas but didn’t like the shortcut Space+Shift. Martin usually rotated the canvas in a way that made it possible to move the hand in a back-and-forth (as opposed to left-right) direction while painting.
2. Martin loved the draw straight line tool and was able to find the shortcut himself (Shift).
3. Martin used the eraser a lot, both as a painting effect and a way of undoing mistakes. Martin likes to work with an eraser with a large diameter as well a smaller one.
4. Martins brush setting of choice for sketching was a hard round 24 pixel wide brush at 36% zoom with a light blue color.
5. Martin liked to outline his sketch with a hard black brush with a diameter that depends on pressure (not possible on the current version).
6. Martin requested the “multiply blending mode” between layers.

Yesterday, Daniel & Max was over and we did a user test on Daniel. Here is a list on things that probably should get addressed:

1. Daniels initial reaction after lunching the application was something along the line: “What tool, brush and color do I currently have and how do I change it?” Daniel eventually figured all of this out, but it was not obvious from the start.
2. When Max was experimenting around in Leonardo he zoomed out to ~15% and continue painting without realizing that he was at ~15% zoom. This was never a problem for Daniel though.
3. Daniel wanted to draw a straight line but never figured out how to do it (it is obviously impossible for the user to know to hold down Q). Once I told him how to do it he instantly loved the way the “draw straight line tool” worked.
4. When Daniel got the task: “convert your current painting to gray-scale” he did not realize that the command “Luminosity” under Filters does this.
5. Both Daniel and Max wanted to create a new Canvas and start searching for “New…” under the File menu, but is not there…
6. By mistake Max eyedropped white, he then resumed painting but did not realize he was painting with white and asked why nothing was happening.
7. When Daniel was switching to Finite Canvas he thought it was strange that the canvas boundary did not get aligned with his current view.
8. When Daniel should flip the image he flipped it vertically when he was supposed to flip it horizontally (an icon should probably make this much more obvious).

Compositors
(applications that export data that is intended for the end-user)

• Image compositor, exports PNG, JPEG etc. (this is Leonardo)
• Video compositor, exports AVI, MPEG etc.
• Document compositor, exports PDF.
• Code compositor, exports EXE.

Coadjutors
(applications that export data that is not intended for the end-user but rather to be imported by some compositor)

• Surface modeler, exports OBJ etc.
• Voxel modeler, export OBJ with corresponding textures (this is Michelangelo).
• Texture painting, export textures.
• Model animation, exports OBJs etc.
• 2D vector graphic editor, exports SVG etc.
• Spreadsheet editor, exports XML.

1. Users rarely have more then one tab open which make a tab interface just look dumb.
2. There is already a “tab-interface” inside the OS: the task-bar! (Of course, a Chrome style tab systems can do things the task-bar can’t, but the point is that handling more then one project really is something that should be done by the OS or, alternatively, with a multi-process architecture as Google Chrome does it)
3. It would be possible to use Ctrl + Tab to swap between layers instead of projects (tabs).
4. It’s easier to develop a SDI application then a TDI.

1. Xade applications are defined by what they export.
2. Xade applications internal file formats should be viewed as a project file with revision control.
3. Xade applications should be able to import every format that could be of interest for producing what the application export.

So, what is Leonardo?

1. Leonardo only export image files like PNG, JPEG, TIFF, TGA, BMP and OpenEXR.
2. But, Leonardo can import a whole host of formats including 2D- and 3D-vector graphics files. These formats get imported as special read-only layer that can be used either as reference material or rasterised to an image.

This divides Leonardo in to two parts:

1. A still image, layer based compositor.
2. A raster based painting system.

And just to be clear, Leonardo will not do the following:

1. Export vector-graphics or video.
2. Manipulate vector-graphics or video.
3. Have specialized tools for photo editing.
4. Have node based compositing.
5. Paint on 3D-objects.

I have created three new pages to aggregate some good ideas (look to the right under ‘pages’)

User Interface
This is how Xade Leonardo currently looks:

(The Swedish flag should not be there in the final version ;-) )

Since I want to minimize UI clutter I have thought long and hard over what should be visible at all time. I have come up with the following things: Current tool, tool help, current color, file size, zoom level, currently selected layer and if Leonardo is currently doing some background work. You don’t need to show the current brush and radius since the cursor already contains that information.

Although the Leonardo engine can handle Layers, the UI doesn’t show you any information about them right now. So far, my best idea for this is to put small tabs on the right hand side of the canvas where the Layer name is written vertically to save space. I am planing on making layers a “first class citizen” so that it will be possible to drag-n-drop layers between tabs, drop files in and out as layers including recently exported files from the Export bar (not shown in picture above).

One thing that hit me recently is that you want to avoid having sliders on the left and upper part of the screen. This becomes apparent when you use a tablet with a built-in display. Your arm will then cover most of the screen while you are adjusting the slider something you obviously want to avoid.

Color Spaces and Gamma
A couple of weeks back I spent some time teaching myself about Color spaces and Gamma correction. I had some prior knowledge of this but if you would have asked me: “Why doesn’t a standard HSV-Hue shift preserve luminosity?” I would have no good answer. Now I know the answer and I am planning on addressing it in Leonardo among a whole host of other issues. What is amazing to me is that not even Photoshop manage to do all this correctly. I guess they know all these at Adobe but they are stuck with what they got because of backward compatibility issues.

My current thinking is having Leonardo work in an absolute color space like sRGB or AdobeRGB as opposed to just “random”-RGB and storing pixels in linear-space as opposed to Gamma-space. I also hope to be able to do some of the pixel operations in LUV-1976 space (like Hue shifts) which I find a really nice color space although there might be some problems with out-of-gamut colors.

Everybody is familiar with a tone-histogram (the one you get in a digital camera or under Photoshop Levels) which mostly is used for setting the black- and white-point of an image. A couple of days ago I had a crazy idea on taking this to the next level with a density or contour plot of the chromaticity of an image. I think this will be an awesome visualization for Hue/Saturation and Color-correction style adjustments and it will make it obvious to a novice user why a Hue-shift is a modular adjustment.

Destructive vs. Non-destructive editing
Over the past 5 months I must have spent over 60 hours just thinking about destructive vs. non-destructive editing (my favorite occupation while taking a walk along the lake). Now, Leonardo is primarily a destructive image editor but since you want some form of synthesis between different layers the question is how far you go down the path of non-destructive editing? Do you allow blend modes? Do you allow procedurally generated layers?  Do you allow vector layers? Do you allow non-destructive adjustment layers? Do you allow non-destructive warps? Do you allow visibility masks? Do you allow “layer styles”? All of these are still open questions…

Another problem related to this is my personal disgust about “blending modes”, I understand they are extremely powerful for the expert user, but even me, with a strong mathematical background, can’t use them intuitively! On the other hand, I haven’t come up with a good alternative :-(

Node recursion
In a previous blog post I talked about switching to a fixed root system, well, I switched back! I found a way to solve the problem and still keeping a non-fixed-root which I am really satisfied with.

While we are on the topic of node recursions, this is one of the most beautiful things I have ever written:

struct node_s {
    unsigned int cb : 4;
    unsigned int id : 28;
    struct node_s *childs[0];
};

node = node->childs[ bitcount[ node->cb & ((1<<c) - 1) ] ];

(node->bash is a compact child pointer list, node->cb is child-bits and c is the child number you want to get to)

The node data have a very small footprint (notice the struct-hack), it’s super fast and yet the whole thing is relatively simple. Storing you node meta data in this way only takes a fraction of the space it otherwise would! Unfortunately I use quite big nodes these days (128×128 pixels) so this doesn’t really matter that much anymore :-(