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

• Printer-Friendly Format
• Text Format
• XML Source
• Mailing List Stats For This Week
• Threads Covered

  1.	5 Apr 2001 - 9 Apr 2001	(12 posts)	Speed-up for Bumpmap
  2.	5 Apr 2001 - 9 Apr 2001	(10 posts)	Whirl and Pitch
  3.	8 Apr 2001 - 9 Apr 2001	(4 posts)	CMYK Images
  4.	9 Apr 2001	(2 posts)	PNG/Netscape Incompatibilities
  5.	10 Apr 2001	(1 post)	Update Your Translations!
  6.	15 Apr 2001	(1 post)	Gimp-Print 4.1.6

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:

• 7 posts in 24K by Kelly Martin <kmartin@pyrzqxgl.org>
• 5 posts in 24K by Ernst Lippe <ernstl@planet.nl>
• 4 posts in 26K by Georg Acher <acher@in.tum.de>
• 4 posts in 15K by Austin Donnelly <austin@gimp.org>
• 3 posts in 20K by Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
• Full Stats

1. Speed-up for Bumpmap

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

People: Ernst Lippe, Kelly Martin, , Austin 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 "

• What data type for the convolution matrix? the current core only seems to support integers, for my applications I found that floating points are really necessary.
• How to handle image boundaries? Treating pixels outside the image as zero gives in many case undesirable results, my code also supports mirroring but several other options are possible.
• What sizes of convolution matrices must be supported? This is an important issue. When you want to support larger matrices (e.g. 20x20) the most efficient approach is to copy the tile that you are processing and (parts of) neighboring tiles into a buffer and perform the convolution on the contents of the buffer. In this way the inner loops of the convolution can be much better optimized. When the size of the matrix is small (say 3x3) it could be more efficient to use the data from the tile directly (without copying) and to treat the boundaries of the tile as a special case.

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 Lippe, Kelly 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 Lamb, , Ulrich 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 Windl, , Simon 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 Neumann, Sven 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:

Sharon And Joy