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 #28 For 22 Jan 2001

By Cris Flagg

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

Table Of Contents

Mailing List Stats For This Week

We looked at 36 posts in 135K.

There were 21 different contributors. 6 posted more than once. 7 posted last week too.

The top posters of the week were:

1. Availability Of Patches And Updates

9 Jan 2001 - 17 Jan 2001 (8 posts) Archive Link: "gimp patch 1.1.32-1.2.0 [Also: Re: cmon guys, no patch from 1.1.32"

People: Daniel Egger, Raphael Quinet, Garry R. Osgood, Tom Rathborne, 

In a continuing discussion of Issue #25, Section #6  (25 Dec 2000: Patch From 1.1.32 to 1.2.0) Christopher Curtis suggested that the format of the patch was not as important as having patches available. Daniel Egger pointed out "if we started now to switch over to deltas then quite a few people would complain about that. " Raphael Quinet mentioned that CVS was not available at work since the firewall is set up to block anything but FTP, HTTP, and SMTP. In this case, patches are the only option. Raphael also said the absence of binaries from patches makes incremental updates more efficient since the do not contain " the latest splash screen or brushes that is included in every new version. This saves half a megabyte for every download."

Garry R. Osgood wrote:

As of this writing (Wed Jan 10 20:57:04 EST 2001) here's how thepings go down from New York City

Garry went on to say that an additional advantage to CVS was the ability to diff against earlier versions and releases of code.

Tom Rathborne, at the request of Christopher W. Curtis, set up an rsync server at rsync -az 64.231.64.9::gimp gimp and noted that the address would change without warning and he would stick the new address on a web page RSN. He finished by saying "The rsync daemon is running on my 486 NFS server, niced to 19. Thus, it might be a little slow with compression, and I have disabled checksums."

There were no more posts in this round of patch discussions

2. gauss_rle Errors

11 Jan 2001 - 18 Jan 2001 (5 posts) Archive Link: "gauss_rle bad error (indexed image)"

People: Rick Bradley, Marc Lehmann, 

Rick Bradley posted a problem relating to perl-fu and script-fu

In that specific instance I was calling script_fu_chalk_logo()(another culprit is script_fu_bovinated_logo()).

gauss_rle) script-fu's from perl with no problems (e.g., script_fu_basic1_logo, script_fu_chrome_logo). Looking at the scheme source for these two particular fu's the images being created and manipulated (as well as all layers created) are RGBA and not any sort of indexed. It seems like gauss_rle is either mistaken about the type of image it receives, the perl interface is not creating images of the proper type, or there's some hoodoo/voodoo loose under the hood.

In a later post, Rick Bradley mentioned that some script-fu didn't have toruble interactively and " It could be that gauss_rle is the only thing I've run into which explicitly checks type (but that would seem a bit odd). " Marc Lehmann suggested an upgrade. " The communication with script-fu from other plug-ins was broken until very, very recently, and I am not sure it works correctly now."

Marc also suggested:

Try to call Gimp::set_trace(Gimp::TRACE_TYPE) before the call to script-fu and check the arguments. If these are correct then you might fail for the corruption bug in libgimp or something new. (It could also be a bug directly in the scheme interpreter, but I think that's unlikely) However, it might also be a bug in the script-fu script. Sicne there is no form of type-checking it is very customary for script-fu scripts to only work directly after starting the gimp, or when certain conditions are met. For example, it could pass in a layer id instead of an image id.

Rick thought the notion of the scheme or perl interpreter being broken in a manner that only caused this specific error was unlikely. He planned "to do the gimp upgrade to see if that fixes the hoodoo."

There were no more posts in this thread

3. Color Calibration In X-Windows

12 Jan 2001 - 17 Jan 2001 (4 posts) Archive Link: "Color calibration in X"

People: , Marc Lehmann

Oliver asked about X-Windows support for useful color calibration. "I know that 4.0 adds gamma adjustment. What about the coordinates of the white point and primaries?" He also asked about ICCs under X. Marc Lehmann suggested calibrating the card and monitor and telling the X-server about it using Xcms. He also suggested looking at XDCCC. Oliver looked at the Xcms manpages and was not "entirely clear on what it's goal in life is." He thought color calibration would be a nice addition to the GIMP. The performance would not be too adversely affected by adding icc support. Marc Lehmann said "Patches welcome (oh yes)" , but cautioned that there are patent issues around color conversion/calibration/matching.

There were no more posts in this thread

4. Bug In ./configure

15 Jan 2001 - 17 Jan 2001 (2 posts) Archive Link: "Bug in configure"

People: Uwe Koloska, , Sven Neumann

Uwe Koloska posted a problem in the ./configure file:

"./configure --help" gives a wrong default for "--enable-gimpdir": --enable-gimpdir=DIR change default gimpdir from .gimp to DIR must be .gimp-1.2 Same change in INSTALL. (I don't know wether I can use variables, so I can't make a patch) maybe it would be a good idea, to explain that gimpdir is the personal dir and does not affect the global dirnames.

Sven Neumann pointed out that variables wouldn't work in INSTALL, so the file was changed by hand. He also suggested that an INSTALL.in file that could generate the INSTALL file.

There were no more posts in this thread

5. How To Despeckle

16 Jan 2001 - 17 Jan 2001 (3 posts) Archive Link: "Despeckle"

People: Michael Daum, , Martin Weber, Jon Winters

Martin Weber asked if there was a better despeckling filter than the median filter. Michael Daum suggested a low pass filters. " In point, it would seem thatyou could use an adaptive low pass filter patterned off of other adaptive smoothing filters. The basic principle is to change the scale of the filter according to the magnitude of the second derivative (Del^2 operator). So you run a windowed low pass filter over the image, and use the second derivative to adjust the scale so that you don't smooth out large features. " Jon Winters helpfully suggested the Despeckle filter.

There were no more posts in the thread

6. Duplicate Name Related Errors

17 Jan 2001 - 18 Jan 2001 (5 posts) Archive Link: "problems with windows gimp"

People: Austin Donnelly, Nick Lamb, , Sven Neumann, Tor Lillqvist

Steven Cochrane attempted to install GIMP for windows several times, but with no luck. he posted a list of errors encountered. Tor Lillqvist suggested Steven remove either tiff_nolzw.exe of tiff.exe from the GIMP plug-ins directory (as vaguely explained on www.gimp.org/win32/) He said PDB procedures caused strange errors from time to time. Nick Lamb posted that this was a long standing bug in GIMP. Sven Neumann had made changes that should have fixed this problem in the current gimp-1-2 branch in CVS. He also requested developers to submit bug reports for issues like this, rather than working around them. Austin Donnelly had also fixed a number of duplicate name issues and PDB code a while back, and asked " If there are still problems remaining, then it would be good to know. "

There were no more posts in this 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.