Porting Drawpile to QML - part 2

The previous post dealt with rewriting the playback dialog in QML. Now it's time for the real meat: the canvas.

Porting Drawpile to QML - part 1

Drawpile 1.0 is now out and development of version 2.0 is in progress. One of the milestones for version 2.0 is the Qt Quick based canvas.

In version 1.0, the canvas view is implemented as a customized QGraphicsScene/View. It has worked fairly well (surprisingly well, even) but Qt Quick has some irresistible advantages:

• OpenGL acceleration
• Declarative UI markup language! (QML)
• Much easier to port to mobile platforms

Since I had never used QML before, I decided to start by porting the playback dialog over first to get some practice. I chose this part because the dialog is fairly self contained and could therefore be rewritten without touching much else (yay, low coupling!)

DrawPile 0.7.0 is out

After a several year hiatus, DrawPile 0.7.0 is finally out. Get it from Github or Sourceforge. (Source code only release at this time, sorry.)

The major new features in this release are support for layers and the OpenRaster file format. Check out the Roadmap for what’s to come in future releases.

KQueryBrowser

I'm on roll. Just pushed my latest project, KQueryBrowser, to github. KQB is a database query tool for KDE that uses qt-webkit to format the query results nicely. And yes, I know the name is highly unoriginal and follows that annoying K<something> pattern, but at least it's descriptive.

The motivation for this yet another query tool was simply that I did not like any of the other query tools. The command like clients are nice, but awkward when browsing through very large tables. MySQL query browser was great, but was replaced by MySQL Workbench, which is way too cumbersome when I just want to run some SELECTs. Pgadmin suffers from the same problem. And most of the graphical tools use GTK, which makes them look ugly or (in the case of MySQL workbench) simply broken on KDE.

So here's KQB. Looks pretty on KDE, works with multiple databases and lets you get straight to writing queries.

Piqs

I just created a new repository on github for yet another hobby project I've been working on: piqs. It's a lightweight image gallery program with advanced tagging capabilities.

It's an experiment in alternative categorization; rather than sorting images into albums/folders, they are all shown in a single flat view, but that view can be filtered with tag queries. Of course, lots of gallery software have tagging capabilities nowadays, but piqs takes it a bit further. You can set up tag aliases and implication rules and something I don't think I've seen elsewhere: tag namespaces. For example, the tag string "[cat, orange], [dog, yellow], backyard" might be applied to a photo of an orange cat and a black dog taken in the backyard. The search string "cat, orange" will return all pictures with a cat and something orange, but the more specific "[cat, orange]" will return pictures of orange cats only. Further, boolean operators are supported: "cat, !dog" will return pictures with cats, but not dogs. "cat, (!dog|[dog,black])" will return pictures with cats and no dogs, unless the dog is black.

This sort of tagging only really starts to pay off once the image collection starts getting very large, so I've tried to design piqs to support huge galleries. So far, I've tried it with about 50000 untagged images and it hasn't choked yet. To help tag every image comprehensively, piqs can infer new tags based on a set of rules. E.g. the rules "cat --> mammal, carnivore", "mammal --> animal" will automatically add the tags "animal", "carnivore" and "mammal" to a picture tagged with "cat".

Griffin powermate + EMC2

I'm currently designing a physical control panel for use with EMC2 and for that I needed to learn how to use the HAL. HAL is EMC's hardware abstraction layer that provides a sort of virtual breadboard for connecting components, both hardware and software, together. One great thing about it is that it's really easy to write your own userspace HAL components in python. A short tutorial from EMC's documentation shows how. Also, Just Milling Around has a great tutorial on how to interface an Arduino with EMC using a python script.

As an exercise before getting started with my control panel, I decided to write a driver script for a piece of hardware I already have: A powermate jog wheel. My script creates two HAL pins: An output pin that can be connected to axis.N.jog-counts and a boolean input pin to turn the LED on and off.

The powermate HAL script is available here: powermate.py

Improved image carving

JGCGen now has better support for image carving. Since the previous post, I've added two major features. The first is a roughing strategy for removing lots of material fast and in multiple passes so you can carve deeper. The second is the decoupling of image resolution from carving resolution. Stepover distance can now be smaller than a single pixel and jgcgen will interpolate the values in between. Another important change was a rather embarrassing bug fix: the tool shape profiles for flat and ballnose endmills were swapped! No wonder the previous test looked flatter than I expected...

Still on the TODO list: optimize rough path generation to minimize rapids and implement a waterline strategy.

Image carving

JGCGen now includes rudimentary support for heightmap carving. You can see the first test carving below. (source)

 Currently only a simple scanning style toolpath generation strategy is implemented, but different methods can be added easily.
Current limitations are:

• No interpolation. The minimum stepover is image width or height divided by target width or height. This results in the striated look visible in the above image. A workaround is to use a higher resolution image.
• Single pass only. This limits the depth of the image to the maximum depth your bit can handle.

My current plan is to add a strategy for a roughing pass that can be run with a bigger bit before running the finishing pass.

A BF interpreter in g-code

The unfortunately (but aptly) named brainf*ck is my favorite esoteric programming language. The whole language has only 8 commands, yet is Turing equivalent, meaning it has the same computational power as a Turing machine. As amazing as it sounds, this means any computable function can be computed with a BF program! A simple way to prove that a language is Turing complete is to use it to implement another which already has been proven Turing complete. Due to its simplicitly, BF lends itself well to this task.

So, here is a simple BF interpreter written in EMC's RS274 dialect:

(print, PROGRAM START)
o100 while [##<_pc> ne 0]
#1 = ##<_pc>
o101 if [#1 eq 1] (memory increment)
        ##<_p> = [##<_p> + 1]
o101 endif
o102 if [#1 eq 2] (memory decrement)
        ##<_p> = [##<_p> - 1]
o102 endif
o103 if [#1 eq 3] (pointer increment)
        #<_p> = [#<_p> + 1]
o103 endif
o104 if [#1 eq 4] (pointer decrement)
        #<_p> = [#<_p> - 1]
o104 endif
o105 if [#1 eq 5] (loop start)
        ##<_sp> = #<_pc>
        #<_sp> = [#<_sp> + 1]
o105 endif
o106 if [#1 eq 6] (loop end conditional)
        #<_sp> = [#<_sp> - 1]
        o1060 if [##<_p> ne 0]
                #<_pc> = [##<_sp>-1]
        o1060 endif
o106 endif
o107 if [#1 eq 7] (print value)
        #3 = ##<_p>
        (print, ASCII: #3)
o107 endif
g0 x1
#<_pc> = [#<_pc> + 1]
o100 endwhile
(print, PROGRAM END) 

This interpreter doesn't support the input command (but that isn't needed for Turing completeness anyway) and just prints out the output in numeric format. This is pretty boring, so I added a set of functions for carving out letters. See the complete source code.

Generating G-Codes

As I said in my previous post, there is a dearth of CAM programs available for Linux, so I mostly have to write my G-Code by hand or combine output from various code generators. To make this task a little easier, I wrote a preprocessor with some code generation features too: JGCGen.

JGCGen is written in Java and uses Apache Velocity as its templating engine. This allows you to easily combine input files, write macros, generate code with loops, etc. Check out JGCGen's readme for a more comprehensive introduction to what it can do.

The g-code for the little name plate on the image to the right is, of course, generated with JGCGen. Yeah, it's not all that pretty and finished, but the code is only 24 lines long!

Addendum to the last post: You can cut plastic with a 2 flute endmill. Just keep the feed rate high enough to keep the chips from melting and clogging up the blades.

Remote control

Problem: Can't pause/fast forward/rewind video or music while sitting on the couch.
Solution: An IR receiver. Luckily it just so happens, I have an old IRMan lying around (basically a commercial version of [UIR](http://fly.cc.fer.hr/~mozgic/UIR/), albeit long discontinued).
Next problem: The computer is behind the couch, at the other end of the room.
Solution: [Universal IR Receiver Daemon](http://kbinstuff.googlepages.com/uirduniversalirreceiverdaemon). This neat little utility supports the UIR protocol and can send the IR codes over a network as UDP packets. Neat! Now I can connect the IRMan to my conveniently located home server which relays the button codes to my desktop PC.
Next problem: No receiver daemon!
Solution: A simple python script listens for incoming UDP packets, checks if the code matches an action defined in a configuration file, then executes that action. Currently amarok and mplayer are supported. Get the script at the [software odds & ends](http://www.luolamies.org/software/misc/) page.
Final problem: UIRD doesn't want to connect to my IRMan. Solution: Apparently a delay in the initialization routine was too short. Changing "usleep( 1000);" to "usleep( 10000)" in init_irmodule.c seemed to fix the it.

Software odds and ends

Decided to upload some old, but not entirely useless, old programs I've written. You can find them at the odds and ends page. They are not really usable pieces of software, but might serve as a starting point or inspiration for someone. Currently, I have three programs up:

1. Animtext: A text animation creation tool. I wrote this back in high school (or the Finnish equivalent) to generate the end credits sequence for a student film project. Perfect for cheesy amateur hacker films!
2. powermate qt test: A Qt4 based test program for the Griffin Powermate. Accesses the powermate via Linux event interface. (powermate driver is in the official kernel tree)
3. tablet qt test: A Qt4 test program for (wacom) tablets. Useful for checking if Qt (or X) tablet support is configured properly.
   

DrawPile 0.5.0

A new DrawPile release is out, little less than two weeks after I resumed the project. This was mainly a bug fix release, introducing a new more stable and robust server and fixing many bugs and usability problems in the client.
The 0.5.0 release has one new major feature: an annotation tool. The annotation tool is pretty much like the text tool in other drawing programs, except the text always floats above the actual image. Because DrawPile doesn't have its own image format (yet), the annotations cannot be saved. They can, however, be burned onto the image (in offline mode only, more on that below.)

With this maintenance release out of the way, next up is more features!


Drawing long lines, especially thin ones, causes nasty jaggies as DrawPile doesn't support subpixel brushes at the moment. This is going to change in the next release. The latest SVN trunk already contains some preliminary subpixel drawing code. Here is how it compares to the old DrawPile and GIMP:

A pen tool that always draws with 100% hardness and no antialiasing will be added, so pixel editing will still be possible. Another new feature that will probably make it to the next release is composition modes. (Add, multiply, darken, lighten and such)


At the moment, DrawPile's tile engine isn't really being used for anything you couldn't do with a huge contiguous image. Splitting the image into tiles makes it possible (or rather, easier) to do some cool things. For example, tiles make it fairly easy to efficiently implement layers. Having layer support means we can also do things like indirect drawing.
Indirect drawing means drawing into a temporary layer first, then compositing the whole stroke onto the image at the same time. This mode seems to be the default on most other drawing programs. Indirect drawing makes it possible to paint with uniform opacity and, in DrawPile's case, removes the need for preview strokes.

There's also one other thing tiles make fairly easy to do: Undo. Unfortunately, it's not that obvious how undo should work in a multiuser environment, so that's one feature DrawPile isn't getting quite yet.

Finally, as mentioned above, the annotation tool currently cannot burn the text onto the image while connected to a network session. The problem is that there is no way to guarantee that each participant of the session has the same font and the same font rendering engine. For example, on Linux Qt uses freetype, while on Windows it uses GDI.
There is a way around this problem though. When a user decides to bake an annotation, instead of just telling others to do the same, DrawPile sends the rasterized text to the other users and they composite that instead of whatever they have. There are still some practical problems that must be worked out with this approach, but this is most likely the way to go. Incidentally, adding support for sending arbitrary raster data as drawing commands also enables features such as pasting from a clipboard.

Continuing work on DrawPile

After a year's hiatus, I decided to start working on DrawPile again.
First thing I did, was rewrite the old server. The new server is QT based (no more other external dependencies) and built as a shared library that can be embedded inside the client and in a tiny standalone shell.
The protocol also underwent a revamp. The new protocol is much more simpler, but also lacks some of the features the old one had (multiple sessions on one server.) The reason I decided to drop these features was that they weren't being used in the client and were and unnecessary complication.
One nice feature the new server has, is the ability to buffer raster data and drawing commands. The server can then efficiently handle new clients with minimal disturbance to other users, and is more robust to boot.

The latest SVN trunk has the new server and a couple of fixes that should make DrawPile much more stable. The drawing code is still slightly broken though. Next up, a new drawing engine, then the 0.5.0 release!