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

Gimp Traffic #9 For 14 Jan 2000

By Alex Harford

Table Of Contents


Welcome to Kernel Cousin Gimp. More bugs are being squished here, and people are starting to decide on what is going to go into the next stable release.

Mailing List Stats For This Week

We looked at 86 posts in 244K.

There were 39 different contributors. 17 posted more than once. 8 posted last week too.

The top posters of the week were:

1. New Gimp Plug-In

7 Jan 2000 - 12 Jan 2000 (7 posts) Archive Link: "New plug-in"

People: Paul F HarrisonGuillermo S. RomeroGlyph LefkowitzKelly Lynn MartinJay Cox

Paul F Harrison announced to the list:

"I have made a plug-in that does some interesting things, like applying a theme taken from one image and applying it to another, or making an image tilable. More details at This is my first plug-in (and my first post to this list). Any comments would be appreciated, especially about any GIMP conventions i may have inadvertantly missed."

He also asked about patents, saying, "Is putting something on the web enough to prevent someone patenting it, or could someone download my plug-in and then patent the algorithm?"

Guillermo S. Romero replied saying:

Your plugin is prior art so patents can not be taken. But web is still a weird place, so you will have to convice lawyers that it is your and since day X.

What I would do is to register your plugin (copyright office) or get an official stamp (notary? I hope that is the correct word for the guy who does that). In other words, an official doc that says that since day X your app exists, and is yours.

Glyph Lefkowitz added:

IANAL either, but the "quick and dirty" solution to this is just to print out the code to your plugin, stick it in an envelope, and mail it to yourself.

USPS is recognized by the US courts as valid, so a postmarked, sealed envelope is pretty much incontrivertable proof that you were there when you said you were.

Kelly Lynn Martin corrected Glyph, saying:

"This is archaic advice, and virtually useless. All doing that does is provide proof of date of authorship. It ceased to be legally meritorious in 1978 when the Copyright Act of 1976 took effect."

In another message, Kelly added that "The best thing I can think of is to have a copy of the source code notarized and stored in a safe-deposit box." Kelly went on to say that "It would provide evidence of prior art, at least; whether it would be sufficient, I can't say. Ask a patent lawyer."

In yet another message, Kelly addressed the effeciency of the new plug-in:

"It's incredibly slow, probably because you did a naive iteration across the image instead of using pixel regions. Doing direct iterations across a gimp image thrashes the system badly and is an evil thing to do. Please rewrite your code to use pixel regions and rerelease. (I'd do it myself but I'm on other tasks ATM.)"

Jay Cox defended Paul's code saying:

Actually the first thing this plugin does is copy the pixel data into it's own process so there is no extra data thrashing going on (though it may be able to benefit from a call to gimp_tile_cache_ntiles). Copying all the pixel info locally isn't exactly something that we should encourage plugins to do, but given the multipass nature of this plugin it seems a reasonable thing to do.

The slow part of the plugin is finding the best matches between the input image and the corpus image. I might suggest using a BSP tree or a multidimensional hash to speed that part of the process up, though I'm not sure if either of those would really be faster than the current qicksort like algorithm. One other possible optimization would be to disregard duplicated patches from the corpus image.

There were no more messages in this thread.

2. CVS Gimp Not Creating .gimp-1.1 Directory

7 Jan 2000 - 9 Jan 2000 (3 posts) Archive Link: "cvs can't create .gimp-1.1"

People: Marc Lehmann

Someone posted a bug report to the list, saying:

Without a pre-existing .gimp-1.1 directory, gimp cvs will lock up immediately after you issue "gimp" at the command line.

strace gimp reports over and over, at the end, that:

read(3, "\23\357w\0\27\0\200\1\27\0\200\1"..., 32) = 32
ioctl(3, FIONREAD, [0]) = 0
read(3, 0xbfffef80, 32) = -1 EAGAIN (Resource temporarily
select(4, [3], NULL, NULL, NULL

Marc Lehmann replied saying:

This is probably _not_ related to the missing .gimp-1.1 directory. Incidently, gimp asks me to create it (and does so) here.

So the error must be somewhere else. Could you provide a full strace listing (to me, possibly bzipped? thanks ;)

The next day Marc announced that he found the bug, saying that it was due "to the usage of gtk+-1.3. Something prevented the window from being mapped/shown/whatever, and gimp just waited for the user to press the (non-visible) install button..."

Problem solved.

3. Gimp Compiled Sucessfully On AIX-4.3.2

7 Jan 2000 - 11 Jan 2000 (3 posts) Archive Link: "success: Gimp-1.1.14 on AIX-4.3.2"

People: Ciaran DeignanMarc Lehmann

Ciaran Deignan announced that he compiled Gimp 1.1.14 on an AIX-4.3.2:


I now have all the plugins, including the perl plugins, and the modules, correctly loading and (apparently) working. Thanks to all who gave me pointers.

I put 2 binary packages on the AIX freeware and shareware archive, on, one for the basic gimp and the compiled plugins, one for the perl module and plugins.

I included in the packages the scripts I used to link the libraries and the perl shared-objects, but don't ask me why it suddenly started working. I've being going round and round with the AIX linker, I can't think straight any more. But the scripts should allow the feat to be re-produced (with the next versions).

Is it normal that after reading the plugins, it displays "extension_script_fu" for 3 or 4 seconds? I've become suspicious when it does things slowly. Still, I can see "script-fu" all over the place in the menus, it does seem to be working.

Regarding the perl libraries, Marc said "And I just wanted to ask you what the problem was ... ;)" As for the slow Script-Fu startup, he said " Yes, that's normal: script-fu re-scans & re-registers all of its scripts every time you start, unlike normal plug-ins, which can easily account for the long time you are experiencing. "

Ciaran Deignan then stated that:

All I can say is that I had to build the libraries by hand (especially libgimp.a and libgimpui.a). It seems to me that AIX doesn't like the way libtool just renames a shared-object to a .a file (instead of doing the 'ar' thing), and it then complains of duplicate symbols. But for libgimp and libgimpui I also had to tweak the link options to export and import a few external symbols.

I spent ages trying to the the Perl modules to work with the shared libs. During the dlload() of the and it couldn't find PLUG_IN_INFO (needed by libgimp.a). I reckon this is an AIX defect. I tried recompiling perl with "run time linking" (-brtl) enabled, but that didn't improve things.

Then I just cracked and used "-bstatic -lgimp -lgimpui -bshared" to add these libs statically to the perl modules, which cured the problems.

There were no more messages in this thread.

4. PNG Blank Display Bug In Windows

7 Jan 2000 - 10 Jan 2000 (7 posts) Archive Link: "[gimpwin-users] PNG blank display bug"

People: Matt WilkieTor LillqvistNick LambSven NeumannSven Neumann

Tor Lillqvist quoted Matt Wilkie as saying, "I'm getting this weird display problem with some PNG images, a sample is attached. Please let me know if you do/don't have similar problems." Tor replied: "The PNG apparently claims to have the display (and print) resolution of 0 pixels/inch... Set it with Image>Scale Image>Print Size & Display Unit>Resolution X and Y and the image appears. The PNG plug-in probably should check for this and use some sensible default if the file claims 0 dpi?"

Nick Lamb replied with some additional queries:

Mmmm. Can someone tell me which app or lib is settings pHYs == 0 ? I think png-implement would like to know about anyone stupid enough to actually do that (it's an optional chunk, so if you don't know what to put in it, why write it at all?)

If you have a suitably broken PNG which is non-sensitive then I'd also like a copy to add to my collection of test images.

Sven Neumann also replied to Tor's messages, stating:

I have changed the core so that it does not accept zero resolutions.

Additionally I have changed all plug-ins that try to set the resolution to check the value and simply don't set it at all if it is invalid. Gimp will then use the default set up by the user.

Nick then replied to Sven's message,

If we do not accept arbitrary values for xresolution & yresolution we need to check for this in image_set_resolution_invoker as well. This is the approach I've taken in current CVS.

Alternatively we could change image_set_resolution_invoker() and similar functions to be thin wrappers around core functionality -- I do not have time to do that, but perhaps someone else does?

Sven then replied to Nick, "Oops, I thought (but should have checked) that image_set_resolution_invoker was calling the gimp_image_set_resolution() in app/gimpimage.c. And probably it should since the core function keeps the undo_stack in sync by calling undo_push_resolution (gimage). On the other hand if called from the PDB, we probably don't want to gdisplays_shrink_wrap (gimage)..."

In response to Sven's earlier message regarding resolution, Kelly reminded Sven to "Please make sure that XCF loading is not exempt from these checks. (XCF loads seem to bypass core sanity checking sometimes..) "

Sven then replied, saying that XCF handled this correctly, and the core now checks these condidtions. He also said that he has "again removed the checks from the plug-ins since this only bloats the plug-in code."

The thread then moved to Nick's new thread, Triage.

5. Feature Triage

10 Jan 2000 - 12 Jan 2000 (12 posts) Archive Link: "Triage! (was Re: [gimpwin-users] PNG blank display bug)"

People: Nick LambSven NeumannRaphael QuinetMarc LehmannSimon BudigGarry R. Osgood

As an aside in another post, Nick asked the list about getting rid of buggy features for the 1.2 release:

It's the start of a new year, and my mind turns to Spring cleaning already

How about some comments for feature triage? There are some features in Gimp 1.1.x which are buggy or unusable, yet stay the same for weeks at a time. Without paid staff to do this work, we must throw away stuff that's not going to make it. On my short list...

Sven provided a status report on these features:

> * Resizable toolbar


I hope we can get the wrapboxes to work. They are considered to be part of GTK+-1.4, so it should be possible to fix this. As a workaround I'd suggest making the layout (horizontal, vertical) a preferences option and disable the interactive resizing.

> * Natural airbrush

Olof ?

> * Error Console (well, here it is, but where are my errors?)

I don't see your problem. I do get my errors in the error-console. All that's missing IMO is a way to set the error_console as the default error_handler in the preferences. That should be easy and is definitely worth the effort.

> * Display Filters

Are being worked on actively in the last time and the latest CVS version has a working Gamma filter.

> * Paths

Simon ?

I think we can wait a little longer with the decision about the removal of the two new tools, Path and Xinput Airbrush, since they don't interact with any other part of the GIMP and can very easily be removed if necessary.

Otherwise I'm all for pushing The GIMP into 1.2 as soon as possible.

Regarding the Error Console, Nick said, "Well, I think you hit the nail right on the head, I have seen this nice Error Console dialog, and never found out how to get my errors reported there. From your description it sounds like that's just some plumbing."

He also asked about the intended use of the gamma filter, and how it interacts with the gamma correction setting in .gimp/gimprc. Additionally he said that "I would like to be able (optionally) to reflect PNG image gAMA settings in the initial view of an image, and to save more accurate values for gAMA when images are entering/ leaving the digital domain. Right now, most users will just get 1 / 2.2 = 0.45 by default, but then almost all apps ignore/abuse the gAMA chunk anyway..."

Regarding the error console, Sven replied that "I can't reproduce your problem here. As soon as I open the error_console, all errors produced with g_message () appear in that dialog instead of popping up a message window."

Gerry R. Osgood also reported that he was unable to see anything in the error console, asked what was neccessary to enable this.

Nick Lamb then replied:

Oh, I see. Somehow I expected that all my errors would appear in that box, regardless of whether they happened before it was visible. Having played with that part I see what you mean...

I'm still not sure quite what I wanted this to do, but it does *do* something useful so strike that from the Triage list.

Raphael Quinet then suggested, "So maybe what we need is a new option in the gimprc, something like: make-error-console-visible-on-first-g-message-and-leave-it-open If you set that to true, then the error console would do what you were expecting. Or did I misunderstand this discussion?"

Nick responded, "Mmmm, well that was part of my sort of half-thought-through expectations, we should see a lot MORE messages in a thing like the Error Console because we don't have to click "OK" for every single message..."

He then added that "As it is, some PNG errors are reported to stderr, which is probably not useful to anyone (but it's default libpng behaviour so I have never gotten around to turning it off) and all fatal errors are reported via one or two general purpose g_message-type calls."

Marc clarified:

All of these discrepancies become because you (as well as me btw), assumed that "error console" is some kind of "error log".

Instead it seems to be something different. While I would prefer an error log window myself (since it is soo convinient for older messages), I think the "Error Console" is not that thing.

Wether that could be changed (making it an error log) is another question, but if, then I'd prefer a way to log warnings (or debugging messages) using the PDB, so I do not have to hardwire my own solution in perl anymore.

Regarding PNG errors, he said that "The problem is that developers probably won't notice, because they start gimp from an xterm often. It's "only" the users who get hurt ;*;> "

In response to Sven's original message, Simon Budig said that he has been busy lately, but gave a status report about the Path tool:

A short summary of the state of the tool:

Good News:

Bad News:

He went on to say that this should be removied from 1.2 unless it was properly intergrated into the Paths Tab. He said that he will try and work on this, but he can't promise anything.

Garry R. Osgood then said that "If there were one feature of Simon's path tool that I would like to have automagically appear in the Integrated path selection tool, it is the ability to manipulate the curve by "pulling" on it directly. it is a very pleasant way to adjust curves. It's effect needs to be adjusted near control points; bezier basis functions associated with the first and fourth control points grow expotentially to unity, so manipulating Simon's path near control points can be a tad exasperating."

Simon replied to Garry, saying

Yeah. The basic idea is, that when you drag on the curve near an endpoint you dont want to change the curve at the other endpoint. So I have to move the handle from the near endpoint more drastically to achieve the "curve-dragging" effect. Maybe I should limit the ratio at some point...

Anyway: It is not too hard to get the control-point back: Simply drag the curve near the anchor towards the anchor. The controlpoint will appear as quick as he went away earlier :-)

Garry clarified what he meant regarding the domain, "Though, strictly speaking, since the mapping is from the parameter space interval [0,...1] to the real line, the behaviour of the basis functions are moot for a parameter t < 0 or t > 1; the bezier basis functions partition unity (they always add up to one), and, at the zero boundary, the basis function scaling the first control point is just unity, the functions scaling the other points vanishing, which is why I had unity, not infinity, in mind. We can be both right; depends on how picky one wants to be in restricting the domain."

He then added that his schedule is rather light in January, and that he can look into the code if needed.

6. Archives Of Gimp Splash Images

8 Jan 2000 - 13 Jan 2000 (15 posts) Archive Link: "Gimp splash images"

People: Guillermo S. RomeroMarc LehmannAustin DonnellyAdrian LikinsGarry R. OsgoodRaphael QuinetTuomas KuosmanenSven Görsmann

Guillermo S. Romero asked the list if the older Gimp splash images were archived anywhere, as he wanted to download them. Sven Görsmann gave a pointer to, and Guillermo then replied, "Thanks to all, but Tigert have GIF images of the original PPM. I dunno if that means quality loss (original where 256 colors only?), and I am looking for the PPM, not derivatives."

He added that he now has access to CVS, and will archive them this way.

Marc Lehmann replied that it wll mean quality loss. He also said that "You can get the ppm files by checking out the relevant cvs revision of that file (tigert's page even mentions the revision numbers)"

Austin Donnelly then took the thread off on a tangent, saying "I vote for releasing gimp 1.2 with Tigert's 1.4 "floating balloon" splash screen."

Tuomas Kuosmanen (tigert) then replied that he agrees :). Various other people said that they like it as well.

Adrian Likins then said that he likes "the baloon, the rocket, or the new one are my faves for 1.2. I really like the newest one. Nice work."

Garry R. Osgood had a criticism for the latest one, saying that, "The latest is very good too, but the bristles are pointing the wrong way (they would point *into* the ink blot as the brush pushes to the left). I guess this bothers my boring and literal mind."

Raphael Quinet also had some ideas for improving the image:

Good catch! Actually, it is even more than that: the whole brush should be pointing in the opposite direction (unless the artist is starting to paint a second line on top of the first one). When you are painting, the brush is usually pointing in the opposite direction of the existing stroke, which is not very convenient for the image layout.

I would certainly vote for the lastest splash screen if it could be fixed. Some suggestions for Tigert (because I am not much of an artist so I cannot do that myself):







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.