Fading Memories

We have just returned from a week-long holiday in Egmond. We rented a little summer cottage for an autumn week, just like my parents used to do when I was a kid. And it was lovely -- the sea stirred by the wind, mighty grey clouds, dunes painted gold and gray by quickly changing skies. Beer and pancakes on a terrace in posh-posh Bergen, Dutch-Chinese comfort food in the Egmond Binnen Chinese restaurant, served by a waitress who was surprised that it was possible for kids to actually want to drink tea, a herd of wild horses grazing in the dunes north of Egmond aan Zee and much more.

More images available for them as likes a horsey wallpaper...

We rented bikes for a day and visited the village where my parents were living when I was born (in the hospital in Alkmaar) -- Egmond Binnen. Wonderfully preserved place. This is the church where I was baptized:

The dust removed from my lungs, energy to work on stuff has redoubled. I discovered the existence of illustrators as a likely target audience for Krita and saw Rembrandt's incomparable sketches in the Rijksmuseum.

Spurred on by discussion in bugzilla, Frédéric Coiffier implemented a level filter for Krita, one of the things Krita was notoriously lacking. Yay for Frédéric!

Oh, and I got my aKademy award, as you can see from the above screenshot. This Motorola phone George sponsored is really cool. You can even type Chinese on it. It speaks and understands English. It has gadgets galore. And the Qt interface is so easy to use that finally I've got a mobile phone that I can actually use instead of curse. And take a look at the certificate!

As Cyrille says, the people who really, really need CMYK are a limited group. Still, having CMYK is an important thing because it's the easiest "other" colorspace to implement that still needs icc profiles. (Grayscale is actually quite hard to do correctly, and the very best algorithms to convert to grayscale are horribly patent-encumbered.)

But the real fun starts with L*a*b*. As Photoshop LAB Color: The Canyon Conundrum and Other Adventures in the Most Powerful Colorspace by Dan Margulis shows, the L*a*b* colorspace really allows for some powerful image editing techniques that are nearly or totally impossible in rgb.

Which is, of course, that I'm inordinately proud that Casper Boemann and me have managed to implement L*a*b* for Krita. You can paint on it, tweak channels and everything. There are limitations: the convolution filters temporarily convert the pixels to rgb and back (fixed in trunk) and we haven't got all the filters and dialogs in place that make it easy to use the power of L*a*b* -- but that's something everyone can help with, now the hard work has been done.

KOffice is steadily growing. While we've not reached really gargantuan proportions, Krita has passed the 100,000 lines of code mark in trunk -- and that's with the color library, pigment, moved to the koffice libraries. Krita 1.6 is 108,000 lines of code, while the Gimp is 600,000 lines of code. Some of that is due to C needing more lines of code for the same functionality, some of that is generated during compilation, but there's also a difference in functionality. The Gimp has many more filters and tools: lots of stuff Krita doesn't have. Yet. And I suspect Photoshop to be in the multi-mloc range.

Last time I used sloccount on KOffice, the result was around 630.000. That was October, too. A year ago, kspread was still bigger than Krita by 10.000 lines. A year later, we're at:

Read more ...

Krita 1.6 has been released, and while there may be a 1.6.1 release in November with bug fixes, my own attention has been focused on Krita 2.0 since the end of the summer. Porting to Qt4 is mostly done; now we're starting to use Qt4 features, like the Arthur paint system and the much improved dockers and tablet support of Qt4.

Krita now shows -- faintly -- the bits of layers outside the image area in the borders of the window:

Because of the canvas work, I've disabled the dockers a bit. Qt4.2 gives excellent feedback when dragging and dropping dock windows. It is possible to place dock windows in tabbed rows and everything. There are a couple of gotcha's though:

• It's not possible to define dock windows to startup in tabbed positions.
• When tabbed, the tabs go completely mad because of KDE's automatic underscore accelerator adding -- this can take up to 99% of your cpu.
• It's not (yet?) possible to have the tabs above the docker -- necessary to achieve that perfect Photoshop look!
• While Qt automatically restores the position of the dock windows when you close and restart your application, this sometimes goes wrong
• I haven't figured out how to mix Qt's actions with kxmlgui so there are no menu options yet to show or hide the dock windows.

But I'm quite confident that these problems will be solved by Trolltech before we release KOffice 2.0

Update: Actually, Simon Hausmann mailed me to say TT solved the first problem already in Qt 4.2: http://doc.trolltech.com/4.2/qmainwindow.html#tabifyDockWidget.

The KOffice tool/pointer system is something I'm working on right now. The idea is make it possible to have a different active tool for every pointer device attached to your computer: so, if you've got a Wacom tablet, you'll be able to have, for instance, pan linked to your mouse, paint to stylus, erase to the eraser end of your stylus and maybe the paint tool but with the airbrush paintop to your airbrush. This already works a bit in Krita 1.6, but for 2.0, this will be possible in all of KOffice.

Now if I could wangle an Intuos tablet with a couple of tools, I would not only be able to test whether this code works (better than in 1.6), but I would also be able to make use of all the cool extensions to QTabletEvent in Qt 4.2.

The thread is long, yes, but to say that matters have come to a conclusion, that it is possible to even arrive at an executive summary is premature. As far as I'm concerned, there have been no conclusive arguments in favor of Scott's summary. But since the discussion is now apparently to be held in blog form, here's my summary.

Read more ...

As discussed in my blog on graphics libraries, common schemes for storing large images are tiles, scanlines and blocks of memory as big as the width * height * size_of_pixel. Tiles are the most common, though. Photoshop, JAI, Krita, GIMP, GEGL, MosfetPaint -- these all break up the image in small squares.

The big difference is in how the application or plugin developer accesses the data in the tiles.

Read more ...