Older blog entries for pippin (starting at number 24)

Improved Aurora Borealis

I've added a basic local contrast stretching/tonemapping algorithm to the experimental regions of the GEGL codebase. I reused other ops for most of the functionality needed and coded it as a meta-op/macro op/graph op, with only a single specialized op to do the actual remapping. tried reusing as much code as possible. Since then I've been trying to make graphviz based visualization of GEGLs state (the nodes, graphs and properties). This allows to see how the tonemapper works, as well as closer inspection of the samples in GEGL gallery.

Putting together the pieces used to construct the contrast stretcher, would not be possible in a tree view such as the one used by the GEGL editor nor in OpenRaster using the hierarchical stacks, since it needs a node that has three inputs and one output to work properly. (Thus such macros/scripts should be DAGs like in the SVG Filter specification if OpenRaster is going to support this concept.

The tonemapper isn't good enough to properly with some of the OpenEXR test images (ugly sample). Even just adding a fader to allow controlling the amount will probably improve this situation slightly.

(Photograph of Aurora Borealis over Gjøvik by EJH)

Syndicated 2006-12-27 22:45:03 from codecave.org

GEGL Earth

I like large images, sometimes I create my own by stitching them together like the ones in my panorama galley. The image I'm using to stress GEGL at the moment is stitched by NASA instead, and is the hugest image file I've got, the image measures 86400x43200px (~11G uncompressed 24bpp)

Two new features were needed in GEGL before I could try to load such a large (larger than RAM) image. Both of them planned since I was experimenting with horizon as a protoype running on my PDA in the beginning of this year. An tiled image pyramid (mipmap) to enable display on screen without needing to access all image data combined with a swapfile backend for the tile system.

Both the swapping and the logic for updating the pyramid needs some further work, swap to gain some more features, the pyramid to be speedier when regions of the backing data changes.

If I am able to find the time to do what I want I should be able to do a GEGL composited, editable presentation about GEGL in the style of the presentation I gave at LGM in Lyon last year for FOSDEM next year.

Syndicated 2006-12-19 17:49:53 from codecave.org

Code committal aids

To reduce the number of keypresses needed to do a commit to CVS I use the following tools:

prepare-ChangeLog.pl

Which extracts which detects which files have changed, and writes a ChangeLog entry template.

gvim

A text editor to edit code, as well as tuning and trimming the generated ChangeLog entry.

ChangeLog entry template.

cicl

Which does the commit described in the first ChangeLog entry.

This allows me to trim away the changes not yet ready to be commited, the commit script then commits the changes with the last entry from the ChangeLog as commit message.

This termgrab shows how it being used in practise:

$ prepare-ChangeLog.pl
  Updating ChangeLog from cvs repository.
    M ChangeLog
  Running cvs diff to find changes.
  Extracting affected function names from C source files.
  Editing the ChangeLog file.
  Done editing ChangeLog.
$ gvim ChangeLog #remove files to be kept from commiting, add comments
$ cicl
Checking in ChangeLog;
/cvs/gnome/gegl/ChangeLog,v  $ ▊

Entry was updated:Changed to reflect current reality, I originally had my own ruby script to do the commit, but cicl a shorter perl version does the same job, and already existed

Syndicated 2006-11-25 21:26:03 from codecave.org

Rosing awards to StopMotion and OOo translators

StopMotion received the student award, and OpenOffice.org's Norwegian translation team the language award at the annual Rosing award ceremony held by the Norwegian Computer Society.

StopMotion is a stop-motion animation program for Linux developed in the spring of 2005 at Gjøvik University College as a student project for SkoleLinux|DebianEdu. The students created a basic stopmotion animation creation tool for use in schools. I participated in the supervision of the two students and it was great fun to observe them adhering to open source methods and practices succesfully - making the application end up in several distros during the initial project period.

Syndicated 2006-11-21 15:16:32 from codecave.org

Evolving the GUI^Wpublic API

The GEGL GUI testbed is evolving, and is now capable of saving output data as well. The most experimental new feature is search as you type addition of filters to a processing stack for non destructive editing. (1.6M gif anim.) It seems like an interface built on similar ideas could be quite effificent. This addition is a rearrangement of the existing code based on an idea from GIMP developer mailing list.

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.

Syndicated 2006-11-06 00:10:52 from codecave.org

GEGL and babl mingling with other piksels

This week I'm going to the piksel 06 festival for free/libre and open source audiovisual software, hardware and art. There I'm going to present the state of GEGL, babl and OpenRaster. In order to have more demoable things for the presentation, some effort is going into an initial test GUI, that mostly is code readapted from bauxite, the video compositing editor built on top of gggl when experimenting with concepts for GEGL.

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.

Syndicated 2006-10-09 16:53:44 from codecave.org

Accelerated Development

GEGL has gone from being dead, to be dormant last autumn, then undead this spring. The amount of required refacoring and polish needed before the releasing a first beta tarball is decreasing and general development is picking up speed, and tools to monitor performance and regressions are being made.

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.

Syndicated 2006-09-21 01:05:40 from codecave.org

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.

Syndicated 2006-09-18 20:06:15 from codecave.org

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.

Syndicated 2006-09-18 12:36:06 from codecave.org

Indexed Metamers

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.

Syndicated 2006-09-10 19:02:04 from codecave.org