Panoramic Summer 2
During my roadtrip in the US, I shot a few panoramic pictures, not all of them came out well, and some of them are yet to be fully processed. Here are two random samplings of the Ontario/upstate New York.
Documenting Crappy Performance
I added a simple, but powerful instrumentation framework to GEGL this weekend. The original plan was to use SVG, xhtml+css or cairo for creating nice graphs and diagrams, but I settled on making UTF8art bar-diagrams, using the glyphs with incremental horizontal coverage in 1/8 increments instead.
./unsharp-mask.xml usecs: 6256331 gegl 7.693684 ██████████████████████████████████████████ process 6.345501 ██████████████████████████████████▊ gaussian-blur 3.025135 ████████████████▋ babl 2.601660 ██████████████▏ defined-region 0.000009 prepare 0.000005 other 0.423461 ██▍ png-save 1.130282 ██████▏ babl 0.444080 ██▌ defined-region 0.000005 prepare 0.000004 other 0.686193 ███▊ subtract 0.994492 █████▌ babl 0.927667 █████ defined-region 0.000006 prepare 0.000004 other 0.066815 ▍ add 0.731857 ████ babl 0.626452 ███▌
Other profiling tools like valgrind's Callgrind and KCacheGrind provides even more detailed information about where time is spent, but a condensed and domain specific visualization makes it easier to see what the hot-spots are.
The core of the instrumentation architecture is the following functions:
glong gegl_ticks (void); void gegl_instrument (const gchar *parent_task, const gchar *sub_task, glong usecs); gchar * gegl_instrument_utf8 (void); /*header/source*/
The first function is a clock providing usecs (1/1000000 second), which can be used to measure the execution time of code
The second function registers a named sub-task of an already existing task. (Tasks can be registered by calling gegl_instrument with 0 as the usecs parameter, the name of the root is specified with an initial gegl_instrument call where both parent_task, and sub_task have the same value.
The last function return a UTF8 breakdown of the time usage recorded. Each task should register it's own time, a special child is appended in the reports signifying how much time has not been accounted for by it's siblings (for the operations in GEGL this is the time spent doing raster manipulation, globally for GEGL this value is slightly wrong (even negative), since recursive invokations of GEGL during processing of the load operations leads to double registration of some processing time.)
This instrumentation is now automatically built for the gallery of the web-pages (which are generated in the docs subdir when GEGL is compiled). I hope to get this hooked up with the Automatic regression tests of GEGL at OSDL. To provide insights about the performance on various architectures, as well plotting historic data to be able to track performance changes over time.
Palletized images are a subset of indexed images. I have no personal desire for either, but one is an artifact of the past and the other possible in the realm of GEGL.
A palettized image is a color image that is reduces to a fixed number of colors. For colors that have no exact match in the palette the closest match is used instead (perhaps in combination with error diffusion/dithering to improve the perceptual match, like GIMPs current conversion to indexed supports). This palette reduction can be done automatically on a per layer basis, or as a global filter for the entire layer stack (like GIMPs current display filters.)
In an indexed image every pixel is a number, this number indicates which palette index will be used for displaying the pixel. Some programs add special meaning to the actual number, and disregard the actual RGB value, to the extent where they introduces indexed metamers, different palette indices with the same color value given different interpretation by the program.
For people depending on indexed metamers to be preserved through processing and editing GEGL is bad news, and they should stick with GIMP 2.x or an old copy of DeluxePaint, for most purposes though GEGL will probably seemingly provide even more power when it comes to editing of palettized images.
tarballed BablFish observed
The build environment of GEGL has received some sorely needed attention, and as part of that babl has been polished into a stable state. Babl is a library providing GEGL with color model and data type vocabulary as well as conversions between pixel formats.
GEGL now depends on babl 0.0.4 or newer. This is the first versioned release of babl. Babl in CVS now carries the version 0.0.5, this will be incremented to 0.0.6 prior to creating the next official distribution tarball.
Babl does its job well, but not at the speed it might be capable of. To make babl more useful for GEGL and other system that might use it more and faster conversion extensions must be added.
Collaborative Bluetooth Slideshow
Some of my students might be working on a project using some form of bluetooth communication. It all started out with a desire to learn about Object Exhange (OBEX) as well as some more of the issues of dealing with bluetooth from the commandline in linux.
My experiments lead to a collaborative slideshow display, where users add images from camera phones using bluetooth. I call it BlueCommon and it is held together by ducttape^Wruby. It is probably possible to crash it, and if it fails to send you something it wants to send you I suspect it might get annoingly persistent.
The Nokia 770 is probably a nice platform to run this, or a modified version on.
Roadtrip to SIGGRAPH
I arrived in the US one week early. My nocturnal european behavior made me a morning person, something the suited my unplanned roadtrip. I rented a car and drove to Boston, from Boston, via Niagara Falls, Toronto Canada, upstate New York, Vermont, New Hampshire, Maine and my first encounter with a barber wielding a cut-throat blade in Lynn MA.
The SIGGRAPH experience itself was overwhelming, I've met people working with concepts and media I find very interesting. Made new friends, hung out with old ones, and got disgusted with the american love of freezing indoors at the height of summer.
It was two weeks without the ability to do any coding, I gathered my thoughts, and found inspiration instead. Now I am looking forward to GEGL development which slowly is picking up momentum and more contributors, as well as investigations into higher level uses of the GEGL technologies.
Programming Web Pages
Work has been under way for a while on new webpages for GEGL, I chose to reuse some of the infrastructure I used to build the babl webpages. The tools building the static pages are automake, bash and GEGL itself. Property introspection with gobject provides a nice operation reference. And the gallery is rendered from XML.
I've also made a bootstrapping script that retrieves the sources, and hopefully builds them.
I'm currently in vacation mode. Photography, relaxation and contemplation. Probably also a bit of procrastination; an epic battle with the beast of autofoo is looming in the distance.
The computer has burnt a few cycles stitching magic|scenic views, some of them already added to my panorama gallery.
XML based image processing
GEGL is also capable of serializing general any graph containing sources, filter and composers to such hierachies. Thus the mechanism to implement a toggle between a layer/graph view in an application like GIMP is possible as long as the types of operations are restricted to these.
The image and XML snippet below illustrates a Layer group, containing a layer clone as well as effect layers.
<gegl> <tree> <node class='png-save' path='-'/> <node class='over'> <node class='translate' x='100.0' y='100.0'/> <node class='over'> <node class='clone' ref='gegl'/> </node> <node class='translate' x='16.0' y='16.0'/> <node class='opacity' value='0.5'/> <node class='bcontrast' brightness='-1.0'/> <node class='box-blur' radius='16.0'/> <node class='png-load' path='data/gegl.png' id='gegl'/> </node> <node class='jpg-load' path='data/vinci-fly3.jpg'/> </tree> </gegl>
Det e'kje GEGL alt so glitra
Upon my initial approach many years ago, GEGL didn't do any image processing, and I failed to understand the code base. Both of these things have changed now.
The tests and the implemented (some autogenerated) image processing ops have not found their place in CVS yet but are available as a tarball that builds against current GEGL and babl checkouts. The tarball contains my test suite, which produces a HTML gallery of the generated images.
There is still a lot of work to be done, but hopefully it is now easier for others to join in :) We need to: settle the API, plug memory leaks, swap to disk instead RAM, fine tune the abyss, make optimized non floating point ops that are regression tested against the float version, settle the operation API, document, optimize, integrate with other frameworks, make the system distributed across rendering nodes, multi threading, and more.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!