Gimp Traffic #18 For 24 Mar 2000

By Alex Harford

Table Of Contents

Standard Format
Text Format
XML Source
Mailing List Stats For This Week

Threads Covered

1.	13 Mar 2000 - 15 Mar 2000	(6 posts)	Improving the Levels and Curves UI
2.	14 Mar 2000 - 15 Mar 2000	(4 posts)	Meaning of fu, and Gimp 16 support status
3.	14 Mar 2000	(4 posts)	Color Channel Operations

Mailing List Stats For This Week

We looked at 68 posts in 244K.

There were 31 different contributors. 12 posted more than once. 10 posted last week too.

The top posters of the week were:

9 posts in 41K by quinet@gamers.org (Raphael Quinet)
8 posts in 43K by Marc Lehmann <marc@gimp.org>
5 posts in 22K by Sven Neumann <neumanns@uni-duesseldorf.de>
4 posts in 14K by Robert L Krawitz <rlk@alum.mit.edu>
4 posts in 13K by Garry R. Osgood <gosgood@idt.net>
Full Stats

1. Improving the Levels and Curves UI

13 Mar 2000 - 15 Mar 2000 (6 posts) Archive Link: "GUI Bugs: Levels and Curves"

People: Uwe Koloska, Carey Bunks, Steinar H. Gunderson,

Uwe Koloska writes:

The problems that arise:

for levels and curves there are four channels R, G, B, value. Is the fourth one really "value" (from HSV) or is it the combination of the other three?? The latter one is called "RGB" in photoshop and I think this is clearer.
in curves it is not easy to discover what is the input (x or y) that is matched by the shown curve to the output. As someone a little bit familiar with maths, I can determine that x is input and y output but maybe it would be better to give these two terms directly (or are there problems with i18n strings in a picture?)
if the other two points are really bugs this one is not and though has to be delayed after 1.2: It would be very nice to enter the value for x (input) and y (output) numerical and not by carfully driving the mouse. Photoshop has (albeit since 5.0) two entrys that show up if a point from the curve is selected.

Carey Bunks replied that "These techniques are described in detail in "Grokking the GIMP" sections 6.1 and 6.2. See http://gimp-savvy.com/BOOK/node60.html and http://gimp-savvy.com/BOOK/node61.html"

He continued to answer Uwe's questions:

Yes, the fourth one is really value; the functional form is V=max(R,G,B). This is the same as what's produced by the Decompose function (found in the Image:Image/Mode menu) when used with the HSV option.

I suspect that you are using GIMP version 1.0.4 which has no feedback about the mouse position in the Curves tool dialog. The developers' version of the GIMP has fixed this by providing a positional information field which gives the exact mouse position in the Curves tool dialog while manipulating the curve. Again, this is explained in detail in section 6.2 of "Grokking the GIMP".

I agree that this would be a nice feature. For this to work with multiple control points on a control curve there needs to be the notion of the "active" control point which shouldn't be too hard to implement.

Steinar H. Gunderson had a question about the algorithm Uwe was using, he asked "How can you know that this colour is supposed to be grey, and not a gray with a tint of blue, for instance? The problem is finding what is supposed to be exactly gray :-)" . Carey replied that "In fact you never really know what the correct colors in a photo should be unless you have a known point of reference (like a color or grayscale card in the photo). Even so, the lighting conditions may be such that the color card is no longer relevant." He suggested looking at areas that should be gray, for example, pavement, or steel objects for a reference. End of Thread.

2. Meaning of fu, and Gimp 16 support status

14 Mar 2000 - 15 Mar 2000 (4 posts) Archive Link: "fu?"

People: FUJITA Yuji, Raphael Quinet,

FUJITA Yuji posed a pair of questions for the list:

Hi, dear developers.

I have two questions, maybe one of them is trifling.

1. Does anyone know what "fu" is ?
I mean "script-fu", "perl-fu" or some kind of these names.

2. What is the biggest barriar to support 16bit depth in the GIMP ?
I'm just reading xcf.c or tile.c and their related stuff and am in distress.

Raphael Quinet answered that it is a pun on "kung-fu". Regarding 16bit depth in the Gimp, he writes "Many parts of the code assume that an image channel has exactly 8 bits. For example, all paint operations (brushes, bucket fill, transforms...) work on 8 bits. Changing that is already a huge amount of work. But this also applies to all plug-ins: they will have to be re-written in order to take several bit depths into account. Maybe you should have a look at Gimp16 project ("Hollywood"). I do not know the current status of the project (it looks like nothing happened recently) but the Gimp16 homepage is at: http://film.gimp.org/" . There were no more messages in this thread.

3. Color Channel Operations

14 Mar 2000 (4 posts) Archive Link: "Bug? cannot duplicate color channel"

People: pixel fairy, Zach Beane, Garry R. Osgood, , Carey Bunks

The Pixel Fairy writes that "is seems you cannot do to the three color channels what you can to any other, such as duplicate. duplicating a color channel is usefull for things like masking out complex selections (like hair)" . Zach Beane replied that "The RGB channels are not real channels, unfortunately. They're pseudo-channels that don't act normal. Perhaps they will be promoted to real channels after 1.2 comes out." Carey Bunks suggested using Decompose, and the pixel fairy replied that this was exactly what he wanted.

Garry R. Osgood suggested:

Open an RGB image.
Image/Mode/Decompose
Pick any decomposition into Red Green Blue; Hue, Saturation, Value....
OK (Decomposing...)
You now have three or four greyscale images which can be readily fashioned into channels.
Layers/Layers, Channels, and Paths...
Use the image menu to select the various decomposed greyscale images
Now you can drag-and-drop or copy and paste your decomposed greyscale images back onto the original to create additional layers, channels, alpha masks.... Or you can mess around with them with levels and curves first, for all kinds of odd and interesting selection tricks.

There were no more messages 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.