Kernel Traffic
Latest | Archives | People | Topics 		Wine
Latest | Archives | People | Topics 		GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Gimp Traffic #25 For 31 Dec 2000

By Cris Flagg

The GIMP Homepage | The GIMP News Archive | The GIMP Mailing Lists | The GIMP FAQ

Table Of Contents

Introduction

Threads between issue 24 and 25 have not been completely summarized due to change in authorship of Kernel Cousin Gimp.

Mailing List Stats For This Week

We looked at 86 posts in 310K.

There were 31 different contributors. 19 posted more than once. 0 posted last week too.

The top posters of the week were:

1. Divide By 255

20 Dec 2000 - 22 Dec 2000 (4 posts) Archive Link: "divide by 255"

People: Nick Lamb, , Mark Lehmann

Nick Lamb responded to a question about the speed of particular divide by 255 routine with the following:

#define FAST_DIVIDE_BY_255(v) ((((v) << 8) + (v) + 255) >> 16)

The above hack was tested to work 0 ... 65025, I'm happy to run speed trials or repeat accuracy checks on Sun and Intel hardware in our lab if someone wants to suggest a reasonable "benchmark" code fragment.

Mark Lehmann pointed out that the constant was wrong, and suggested he check gcc output since mov/mul/mov shouldn't be slower than shift/lea/shift. Mark also mentioned that signed integers are much slower than unsigned integers.

Jerome Abela noted that this issues was similar to one experienced with alpha channels. He describes a routine where a box should be filled with a red square, but instead is left with the original cross.

There were no further posts

2. Improved Keyboard Operation TODO

20 Dec 2000 - 21 Dec 2000 (4 posts) Archive Link: "gimp 1.1.31-32 BUG"

People: , Sven Neumann

Timecop pointed out that improved keyboard operation was left out of the TODO. Sven Neumann agreed that this was important, but that gtk+ needed to be fixed before the changes could be made. Lourens Veen pointed out that 1.1 was in a feature freeze, and the TODO would need to wait before it was updated.

There were no more posts in this thread

3. RPM Build Problems With gimp-1.1.32.rpm

21 Dec 2000 - 22 Dec 2000 (4 posts) Archive Link: "Problem building an gimp-1.1.32 RPM"

People: , Kevin Cozens

Henning Sauer pointed out an error in the gimp-1.1.32.rpm install where the gimp executable, plug-ins, modules, and libraries were installed in /usr/ and not under BuildRoot.

Sven Salut mentioned that the spec file distributed was not maintained and should probably be removed in 1.2. Henning Sauer asked to be penciled in as the spec file maintainer.

Kevin Cozens said he believed the problem was in the makefile, where 'make install' was sending things to /usr/bin/ and not the directory specified by prefix=.

4. Pupus Pipeline

21 Dec 2000 - 26 Dec 2000 (9 posts) Archive Link: "Pupus pipeline: what Adam has been doing, etc. etc."

People: Adam Moss, Garry Osgood, Tino Schwarze, , David Hodson, Steinar Gunderson

Adam Moss presented an update to his original proposal entitled "PUll-PUSh". He summarized the idea, saying, "The somewhat-simplified idea common to both proposals is that a list/tree of little black boxes is set up, where images get fed into the tree at the bottom, get chewed up by the black boxes through which they are sequentially sent, and at the end of the line comes a result. If you think of the black boxes as analogous to plug-ins or compositing operators then you'll see that you've basically got a generalized way for a program to conceptually project a layer-stack, spin an image around and blur it -- whatever. Have the right black boxes at hand, connect them up just /so/, push in the desired source image(s) and wait for your beautiful beautiful output to spew forth from the end of the chain."

Adam pointed out that the new proposal would not go crazy on the resource-contention-avoidance malarky. This should be a natural side effect. Additionally, in-place rendering and minimized copying is possible, life is a lot friendlier towards black boxes who can't/won't work on a 'regions on demand' basis, aborting a task pipeline is easier, changes to geometry (width, height, offsetting) figure into the grand scheme, spontaneously invalidate image regions from upstream while they are still being processed downstream, latches and feedback-loops within the system might be facilitated with a little more effort. He went on to describe the implementation as it stands:

  1. We are toolkit-agnostic. At the core we deal with tasks and resources, not a user-interface.
  2. We are transport-agnostic. Only one transport-type is implemented so far and even then not as cleanly as I'd like, but in theory we can quite easily invoke these 'black boxes' (called 'steps' within the code) on remote machines via CORBA or Convergence's GCim (?).
  3. Black boxes are instantiated from factories implemented as .so files. These are dynamically discovered at runtime. These are currently dynamically-linked to the main application at discovery-time but (in theory...) can trivially be dynamically-linked to an alternative transport shim and hence run from within a different address space or indeed a different physical machine.
  4. A few black boxes have been written for testing purposes. All interfaces are continually in flux and are slowly being pared down to their essentials.
  5. The basics of the pupus kernel/scheduler (the 'step manager') are written; this is responsible for collating and organising work requests, and is also responsible for tracking the resources afloat in the system and servicing region read/write requests.
  6. Pupus is colourspace, pixel-format and storage agnostic. That's Someone Else's Problem; we deal with high-level notions of 'surfaces', regions thereof and similar. The pixel-molesting black boxes have to care, of course; at the moment for testing purposes RGB24 is a blanket assumption. This is where GEGL comes in, I think.
  7. There are some lovely pipeline optimization opportunities that are becoming apparent and can later be implemented at leisure without affecting correctness.

Adam continued to describe the process as not simply a method of processing images, but of also processing trees of black boxes. The recalculation of "the whole world back to the conception of the universe" would me manageable by implementing cache-boxes that could be inserted into the tree where the step-manager saw a need to unstress the pipeline. He finished by saying "I do not advocate, in fact I ABHOR the idea that the user should end up drawing a little tree of boxes connected with wires. That's your view as a programmer (and even then there are likely to be a few utility layers of API between you and the raw pupus pipeline constructor when I've had my way), but your responsibility as an application designer is to map a more user-friendly concept (good old layers, images, layer masks, brushes et al) to this back-end."

Garry Osgood pointed out that if Pimp 2.0 core was dedicated to nothing but staging compositing, the user interface fell away from view. This means that any platform may write in interface to the Gimp core and any scripting language may be used to direct an manipulate it. Developers could focus on specific black boxes, rather than having to know the entire code-base. He went on to summarize Adam's black boxes:

  1. Some are capable of interpreting references to some sort graphic content as, say, PNG files in a file system.
  2. Some (cache-boxes) are capable of persisting "upstream" image presentation for "downstream" black boxes. Some other component of the application might choose to associate with such cache-boxes the notion of "layer", but that is the business of that more or less external (and, me thinks, user-interface housed) component. To the step manager, it is a step that persists (parts of) images.
  3. Some black boxes (it seems to me) house genetically engineered goats (large ones) that pixel process. As an aside, These GEGL boxes are (hopefully) the only interior places where some sort of physical implementation of pixels matter -- how many bits they have, how those bits relate to color and transparency components, what sort of pixel and pixel area operations are capable of mapping a region in one cache-box to a region in another. To pupus (the step manager) it is just a surface -- it is neither capable of, no interested in, the manipulation of the surface 'fabric.'
  4. Some black boxes know how to stream to external representations: perhaps they embed connections to an X server, or something that knows how to write (particular kinds of) image files.

Marcello de G. Malherios brought up a commercial image processing system called "Khoros" that used "glyphs" and had a visual data-flow editor. More information is located at www.khoros.com. The white paper is located at www.khoros.com/ideas.technology/cantata.pdf.

David Hodson said he has been working on a similar idea which, though still alpha code, was located at www.ozemail.com.au/~hodsond/gimpeon.html

Steinar Gunderson suggested that this could be used to preview a low-res image and computer the full-res version later

Lourens Veen said that as a programmer, he was excited about being able to manipulate the layer tree.

Tino Schwarze agreed that manipulation of trees as an exciting option, and that the process sounded like interactive sript-fu. The step manager could work as a stand alone library, managing steps for different types of applications. Tino stated "Using this framework, it would be easy to implement a transport mechanism via some high-speed network and interconnect several computers to do heavy scientific/industrial image processing. The "pipelines" connecting the black boxes should be pluggable."

There were no more posts to this thread

5. GIMP 1.2 CVS Branch

25 Dec 2000 (1 post) Archive Link: "CVS branch"

People: Manish Singh, 

Manish Singh posted "For 1.2 maintenance, the CVS branch is gimp-1-2. To check it out: cvs co -r gimp-1-2 gimp"

6. Patch From 1.1.32 to 1.2.0

25 Dec 2000 - 27 Dec 2000 (12 posts) Archive Link: "cmon guys, no patch from 1.1.32 to 1.2?? [Also See gimp patch 1.1.32-1.2.0]"

People: Steinar Gunderson, Garry Osgood, Daniel Egger, , Marc Lehmann

Timecop requested a patch from 1.1.32 to 1.2.0.

Daniel suggested using CVS Tags, to which Marc Lehmann suggested creating a patch using rdiff. Steinar Gunderson pointed out that "The CVS protocol is quite inefficient -- normally, I'd just do a CVS update on a shell with good bandwidth, and then either generate a diff, or just rsync the two trees."

Lourens Veen posted a gimp-patch-1.1.32-1.2.0.bz2 patch. Garry Osgood commented on patch-sets, saying, "The tarballs and patch-sets are really meant for end-users who prefer to compile from source, but don't otherwise desire to get involved in maintenance and so don't have a strong motivation to keep a bleeding-edge source tree around. Patch sets are published with this laid-back attitude in mind, They lack the CVS administrative files which is a pity (but then, CVS admin directories don't always transplant themselves effortlessly. They depend on the context of particular users on particular clients using particular CVS servers) " Daniel responded that Timecop had pointed out a problem with patch sets "They don't contain binary files or patches to such and thus a patched tree might miss quite a few important files after a while. xdelta wouldn't cause that particular problem but is harder to use and deltas are not as obvious to read as an unified diff." The end result is a need to refecth the whole tarball periodically.

There were no more posts in the thread

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.