Gimp Traffic #39 For 16 Apr 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 39 posts in 162K.

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

The top posters of the week were:

1. Speed-up for Bumpmap

5 Apr 2001 - 9 Apr 2001 (12 posts) Archive Link: "[patch] unbelievable speedup for bumpmap..."

People: Ernst LippeKelly MartinAustin Donnelly

Georg Acher submitted a patch that greatly increased the speed of bumpmapping by getting and writing 32 rows at a time. Georg added that the performance issue was with gimp_pixel_rgn_get/set_row-calls in Gimp 1.2.1. Austin Donnelly suggested that most plugins should be using gimp_pixel_rgns_register() and gimp_pixel_rgns_process() functions instead, since they do blocking on a per tile basis. He suggested looking at whirl-pinch for examples of more complex access patterns. Ernst Lippe thought the speedup was caused by better caching, since it looks like all tiles are read and written gimp_tile_height (normally 64) times. Ernst submitted a patch that was similar, but allowed each tile to be read only once. He suspected that the algorithm could be rewritten so that only 3 tiles are needed at a time by using 3 extra buffer columns instead of 3 extra buffer rows. Kelly Martin noted that bumpmap.c calls gimp_tile_cahce_ntiles, which my not be asking for enough cache (or it could be a problem in the tile caching code.) Kelly also suggested using a pixel region iterator since the bumpmap need not be the same size on input and output.

Ernst Lippe offered to clean up some personal code that handled neighborhoods without fetching tiles multiple times. Austin Donnelly thought the core could use some tile convolution code, since it currently copies data Actually, the core could do with a tile convolution, since currently it copies data into a tempbuf before convolving it. This makes some tools more effificient (or incorrect) eg iscissors. Ernst had several design considerations "

" Ernst offered to do a large part of the coding if there was support from the "core" Gimp developers. That means help with design decisions, too.

There were no more posts in the thread

2. Whirl and Pitch

5 Apr 2001 - 9 Apr 2001 (10 posts) Archive Link: "[patch] Major speedup for whirl&pinch plugin"

People: Ernst LippeKelly Martin

Georg Acher posted a patch to whirl&pitch to the list. The patch uses blocking to affect a 4.5x increase in performance without changing the main algorithm. Kelly Martin thought whirl&pitch used tile regions for this, but later responded that this was not that case and thought pixel regions might provide less of a loss due to locality. Georg noted that the locality was good between the source and destination, which was what really mattered. Ernst Lippe suggested that there were no major differences in CPU time between Georg's method and the old way. The differences lie in the number of calls to gimp_tile_get and gimp_tile_put. " Requesting tiles from the main Gimp process is pretty expensive, it involves several context switches and a lot of copying. This is orders of magnitude slower than copying data within the plugin process from the tile cache to some other buffer. The whirlpinch plugin uses a cache size that is only big enough to handle the output tiles, there is no room for input tiles. This leads to a series of cache misses and horrible performance. Your modifications improve the cache-hit ratio because it " [...] " The more fundamental solution is to rewrite the algorithm so that it works on a tile by tile basis. In that case the minimum cache size is only 2 (for the output tiles) plus the number of input tiles that are needed to compute one output tile. Of course it is better to use a somewhat larger cache size because adjacent output tiles can use the same input tiles. "

Georg also asked if there was a default tile size that helped caching. Kelly said the default tile size was 64x64, and that changing this made .xcf files non-transportable. " I tried to modify the XCF loader & saver once to do reblocking, but it gave me a headache and I moved on to other, more interesting things, like feeding my cats. :)"

3. CMYK Images

8 Apr 2001 - 9 Apr 2001 (4 posts) Archive Link: "Problem with CMYK TIF"

People: Nick LambUlrich Windl

Ulrich Windl had problems loading a .TIF image into the Gimp. The image had no progress bar and ended up rotated 180°. Ulrich wondered if the .TIF used LAB colors, not CMYK. He also mentioned something about a dialog box he didn't read. Ville Pätsi pointed out that the Gimp didn't currently have support for the CMYK colorspace, but it was planned for a 2.0.X release. Nick Lamb added " [t]he dialog box who's contents you don't remember warned you that this would happen - read the warning dialogs!"

4. PNG/Netscape Incompatibilities

9 Apr 2001 (2 posts) Archive Link: "PNG/Netscape incompatibilities?"

People: Ulrich WindlSimon Budig

Ulrich Windl's problem with .PNG files was as follows: "The black pixels all appear white in Netscape, while in Amaya or xv the appear OK. I made PNGs the same way with older versions of GIMP, not having that problem." Simon Budig responded that this was a Netscape bug. The solution was to select black as background-color and check the "save background color" button in the PNG-Save dialog.

5. Update Your Translations!

10 Apr 2001 (1 post) Archive Link: "Update Your Translations!"

People: Sven NeumannSven Neumann

Sven Neumann posted the following note to the developer's list:

" I have just committed a patch to the stable gimp branch that marks a few leftover strings for translations. Translators that are interested in getting a full translation into 1.2.2, update your po-files now! "

6. Gimp-Print 4.1.6

15 Apr 2001 (1 post) Archive Link: "ANNOUNCE: Gimp-Print 4.1.6 release"

People: Robert L Krawitz

Robert L Krawitz posted the following announcement about Gimp-Print 4.1.6:

This is gimp-print version 4.1.6, a development release on the 4.1 line.

This software includes the Print plug-in for the Gimp, and GhostScript and CUPS drivers. The support for printers in GhostScript and CUPS is identical to the support for these printers in the Print plugin -- they use the identical code base. Please read src/ghost/README and src/cups/README for more information on this.

The Gimp Print plugin requires the Gimp 1.2.

Gimp-Print 4.1.6 contains the following changes over 4.1.6:

  1. As of this release, the Gimp 1.0 is no longer supported. You must use at least 1.1.21; 1.2 is strongly recommended. In particular, we will not fix bugs in the Gimp plugin unless they can be reproduced with the Gimp 1.2.
  2. Foomatic is now supported in the 4.1 line. Please read the README for more information. This requires a relatively recent version of Foomatic and is not compatible with the version bundled with Gimp-Print 4.0.
  3. Significant improvements to the Canon driver for many printers, most notably the BJC-8200. There may be some temporary new problems with 4-color printing on some Canon printers; feedback on this would be greatly appreciated.
  4. Significant improvements to the Lexmark driver.
  5. Further improvements to the Stylus Color 980.
  6. Support for printing 720x360 DPI on many Epson Stylus printers. This mode offers a speed/quality tradeoff intermediate between 360 and 720 DPI. It does not work very well on photo-quality paper.
  7. Improvements in the Fast dithering option on plain paper.
  8. Some improvements to the Epson Stylus Photo 870/1270 and newer 6-color printers.
  9. Internal architectural changes: the library now operates internally in CMY rather than RGB space, and offers a raw CMYK input mode. The former is not visible outside of the library; the latter has no current uses and is untested. Neither change should have any user-visible effects; this is strictly for programmer use.







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.