Such user interfaces for GEGL should probably not be written in C but in dynamic programming languages like Ruby or Python. Proper bindings for these languages do not exist yet. This C based GUI will give insights into what features are needed to succesfully leverage GEGL in GUI applications. This GUI is a developer toy and behavior, appearance, stability, fileformat and scope of features are prone to change with the phase of the moon.

It looks a lot better than it is, it has a few known crasher bugs, it (or rather GEGL) is a lot slower than neccesary due to lack of caching/intelligent redraw, and more, but at least it works.

Another nice thing is that GEGL now supports loading of OpenEXR thanks to a new file-io operation made by Dominik Ernst. Getting some of the sample images into GEGL and playing with adjustments and blurs confirms that GEGL is HDR capable, but without range remapping ops, it isn't very interesting.

There still is time to brush things up before the conference, but I'm looking forward to demonstrate the current capabilties as well as present the design, use and extension mechanisms of the current GEGL architecture.

Since GEGL was undead it has gotten contributions from 6 new contributors, this seems to indicate that my work to make the code approachable by others is bearing fruit.

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.

./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.

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.

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.

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.

This year I got the opportunity to attend my first SIGGRAPH, as a contributor in the art gallery, exhibiting Nå av da.

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.

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.

<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>

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.

1. Add a new .c file that generates it's reference PNG on stdout
2. Create an empty reference image.

   echo "not a valid PNG" > roi-test-7_ref.png

3. Run the test suite. The test target of the Makefile will now generate PNG's corresponding to images matching the wildcard *_ref.png, as well as do an MD5 comparison on them.

   make check

4. Visually inspect roi-test-7.png, if the rendered test image is not satisfactory, do some magic to the code, hope it works and go back to step 3. If we run

   make recheck

   the pngs will be regenerated and checked no matter the timestamps (thus exercising dynamically linked libraries as well)
5. Make the current rendition of the test the reference when it is rendering correctly.

   cp roi-test-7.png roi-test-7_ref.png

6. Do changes, and restructurings on the code, seeing some tests pass and some tests fail. Make all tests pass when changing something. From time to time changes crucial parameters like tile-size, caching, backend etc. To exercise other code paths.

Screenshot:

pippin@id:~/src/gegl-demo/$ make check
//  snipped away build (gcc) output //
md5sum *_ref.png|sed s/_ref//|md5sum --check -
./buffer-test-0 > buffer-test-0.png
./buffer-test-1 > buffer-test-1.png
./roi-test-0 > roi-test-0.png
./roi-test-1 > roi-test-1.png
./roi-test-2 > roi-test-2.png
./roi-test-3 > roi-test-3.png
./roi-test-4 > roi-test-4.png
./roi-test-5 > roi-test-5.png
./roi-test-6 > roi-test-6.png
./roi-test-7 > roi-test-7.png

Computing checksums:
buffer-test-0.png: OK
buffer-test-1.png: OK
roi-test-0.png: OK
roi-test-1.png: OK
roi-test-2.png: OK
roi-test-3.png: OK
roi-test-4.png: OK
roi-test-5.png: OK
roi-test-6.png: OK
roi-test-7.png: FAILED
md5sum: WARNING: 1 of 10 computed checksums did NOT match
make: ** [md5check] Error 1
pippin@id:~/src/gegl-demo/$ make recheck▊

When pursuing geometrical bugs it is easier and more fun to look at cairo rendered images than scrolling through lines of printf'd coordinates.

One solution is a publicly trusted institution to temporal private/public key manufacture service. New public keys to encrypt data is released daily/monthly, and the corresponding private key after 10 years. The encrypted material can be released into the public domain, as can the public key used to encrypt it. The public will not get the key to unlock this until the future.

After 10 years, one can release temporal locked information with a lock duration of 0-10years. Another option would be to pregenerate a set of disclosure dates, for instance annual.

The security of the process should be maintained through public disclosure, all aspects of key generation, intermediate storage and disclosure procedures should be open source. And the security of the system be protected by international observers.

submerged in
abstract logic

discovering and
reshaping tools

traversing
levels of abstraction

creating
tools from tools
      with tools

reconstructing
deconstructed structures

fetching
iterating processing

orthogonal extent
expansion

The core idea is API enhancement through a man-in-the-middle-attack:

GeglTileStore

The core of the API, implements get_tile(x,y,z) and message(msg_enum, x,y,z,data), which are virtual methods reimplemented by subclasses.

GeglTileTrait

A Man-in-the middle that filters the API, subclasses will override behavior or have other side effects on the behavior of the API. Can provide caching, implementation for "blank" tiles in place of NULL for get_tile(), coordinate translations etc.

GeglTileTraits

A chain of men-in-the-middle.

GeglBuffer

The object that is the "public" side of this API, the rest of the classes are implementation details. Automatically manages it's own source of data, caching, blank tile copy on write and more.

A TileBuffer provides a TileStorage (net, disk or shared mem) as well as a set of associated tratis, and methods do use the associated traits.)

GeglSubBuffer

A trait chain using an existing buffer a source, that provides further offseting/clipping of the region accessed. Buffers as well as SubBuffers act as sub-buffer factories.

GeglTileDisk, GeglTileNet...

Persistent tile providers, tileswap/wire protocol or similar, adding a new one touches minimal new code.

GeglTileCache, GeglTileEmpty ...

Elements of code that need to know what tile communication is performed, and/or manipulates the result. Some might depend on tuning and additional methods in canvas.

Update: The best suggestion for what design pattern it is most similar to is "Chain of command", not a full match though.

code cave

Noun, (plural: code caves)

1. In a computer program, it is an unused block of memory that someone, typically a software cracker, can use to inject custom programming code to modify the behavior of a program. This is one of the many tricks available, and is often used to bypass copy protection or add cheat codes to games.

Hmm...

]]> static_blog http://codecave.org/?weblog_id=static_blog Wed, 26 Apr 2006 14:02:46 +0200 blog bash JavaScript This blog is served as RSS to you, on codecave.org there is a javascript using xmlHTTPRequest, and massaging it into XHTML.

Blogging is done by AJAX monitoring the scratch text file being edited through ssh. When the contents are right the item is published by issuing $ ./blog "id" "Title of item". This bash script inserts the new entry into the start of the feed.

]]>