The GIMP Homepage (http://www.gimp.org) | The GIMP News Archive (http://www.xach.com/gimp/news/index.html) | The GIMP Mailing Lists (http://www.gimp.org/mailing_list.html) | The GIMP FAQ (http://www.rru.com/~meo/gimp/)
Table Of Contents
|1.||20 Dec 2000 - 22 Dec 2000||(4 posts)||Divide By 255|
|2.||20 Dec 2000 - 21 Dec 2000||(4 posts)||Improved Keyboard Operation TODO|
|3.||21 Dec 2000 - 22 Dec 2000||(4 posts)||RPM Build Problems With gimp-1.1.32.rpm|
|4.||21 Dec 2000 - 26 Dec 2000||(9 posts)||Pupus Pipeline|
|5.||25 Dec 2000||(1 post)||GIMP 1.2 CVS Branch|
|6.||25 Dec 2000 - 27 Dec 2000||(12 posts)||Patch From 1.1.32 to 1.2.0|
IntroductionThreads 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:
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:
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 (http://www.khoros.com) . The white paper is located at www.khoros.com/ideas.technology/cantata.pdf (http://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 (http://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 (http://nova.student.utwente.nl/tc/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.