Gimp Traffic #38 For 6 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 129K.

There were 17 different contributors. 9 posted more than once. 6 posted last week too.

The top posters of the week were:

1. Possible TODO Items

27 Mar 2001 - 30 Mar 2001 (32 posts) Archive Link: "couple possible TODO items"

People: Zachary BeaneNick LambSven NeumannTino SchwarzeAdam D. Moss

Zachary Beane posted two ideas that he'd like to add to the TODO.xml list. " Biased color reduction - This is a feature I saw in photoshop. When reducing the colors of an image, it will try to preserve colors within the active selection more than it tries to preserve those outside of it. For example, if you want to keep skin tones in an image, but want to otherwise reduce the overall number of colors, you would select a few representative areas of skin before doing the reduction. " " Personally, I can't count the number of times I've converted an image to Indexed only to find the black had gone suddenly slightly off-black, or another solid color that I really needed at a particular value had suddenly shifted slightly. I'd love to be able to select those colors before conversion to hint to the Indexed conversion, "these exact values are important to me." "

Sven Neumann mentioned that according to the changelog entries, Adam might be working on this. Zach said the entries are what prompted him to post. His main question was how does the algorithm know which colors to save and which to modify? Adam D. Moss didn't think the algorithm could. Hinting at what part of the color histogram to bias was a cop-out and would only be needed if the Gimp wasn't preserving colors. Tino Schwarze thought there might be some use to flagging some colors sticky for logos and corporate work where the colors are specifically fixed. There are colors that can be identified as important and non-important based on the image use (i.e. color safe web work)

Zach also posted an idea about monitor calibration " Monitor resolution calculation - This idea has been kicking around in my head for quite some time now. Rather than the current system of "measure this item onscreen and enter the figure from your ruler" to calculate DPI, I think it would be more userfriendly to have the shape of some common object that you could stretch to fit. For example, you could select A4 paper, place the top of a sheet against the monitor, and stretch or shrink the virtual outline until it fits the physical outline. That would give a pretty decent measurement, I think (This program could also be completely standalone, as I think it would be useful at other times than GIMP installation.) "

Nick Lamb suggested CDs, since perfectly round objects would show skew very well. Additionally, credit cards were standard size. Zach was concerned about CDs scratching his anti-glare coating. Sven though credit cards were too small and suggested using the image->new dialog for printing calibration info onto paper. The discussion devolved into the merits of metric v. english measurements and the general accessibility of rulers for measuring. Zach ended the discussion with " However, even if the consensus is "just get a ruler", I think the current measurement dialog could be improved with a user interface of "stretch the virtual to fit the physical," rather than the current setup."

There were no more posts to this thread.

2. Plug-In Question

28 Mar 2001 - 29 Mar 2001 (6 posts) Archive Link: "Plug-in question"

People: Nathan C SummersSimon Budig

Mark was trying to code a plug-in that read a file into the Gimp his company server, then saved it to a databases once it was edited. First, he wondered how to write a script-fu extension that would automatically open a file in the gimp once it was downloaded. Simon Budig suggested "file-jpeg-load", which returns an image id, followed by a "gimp-display-new" and probably a "gimp-displays-flush". He also suggested the vanilla "gimp-file-load", which is not limited to jpeg. Simon also suggested making this its own file type, allowing gimp to automagically know the file saves to a database (similar to gzip/wget-filetype).

Mark got it working but had a syntax question "The PDB function is file-jpeg-load, but I have to spell it file_jpeg_load in my const char * which I pass to gimp_run_procedure. Is this the standard, are all functions o fthe form xxx-xxx-xxx really xxx_xxx_xxx, or are all hyphens really supposed to be underscores?" Nathan C Summers said " the c pdb functions export lotsa_underscore_names, and the db browser and scheme interfaces substitute a hyphen whereever they see an underscore. This really threw me off when I made the first perl<->gimp binding ages ago. "

3. Grokking the Gimp

2 Apr 2001 (2 posts) Archive Link: "'Grokking the Gimp' any good?"

People: Branko CollinGuillermo S. Romero

Branko Collin is working on the Dutch translation of The Gimp and found a Dutch version of 'Grokking the Gimp.' He wondered if the translations of terms were faithful and if the English version was a valuable book. Guillermo S. Romero suggested taking a look at the full text online at ( .

4. Scaling of Work Images

3 Apr 2001 (2 posts) Archive Link: "Scaling of work images in late gimp's"

People: Gene HeskettAustin Donnelly

Gene Heskett commented " One item thats been bugging me since a bit before the final 1.2.0 came out is that the work screens default render is now set to a 50% scaledown. For what little work I do, this isn't desirable. Loading the same pix into gimp and scaling it back to to 100%, then compareing the same pix loaded into EE makes gimp look pretty bad. "

Austin Donnelly thought these were two separate issues. Firstly, The default scale factor for images is automatically adjusted to fit the new image on the screen. Secondly, the Gimp uses GdkRGB to reproduce colors, so is the difference pixelation, jaggy edges, color casts, or scaling artifacts? Austin requested Gene post some small screen shots, but there was no reply to the list.







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.