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.

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.

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 http://www.gimp-savvy.com/BOOK/.

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.