proposal for better status bar messages (long)
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
proposal for better status bar messages (long)
Here is a proposal for improving the messages that are shown in the status bar. Such messages would be very useful for describing some hidden features of the paint tools (bug #124040) but also for the other tools.
Basically, I followed this approach: anything that causes a tool to change its behavior (clicking, dragging or using some modifiers such as Ctrl and Shift) should be displayed or suggested in the status bar. Simon has already done that for the path/vector tool and I would like to apply that to all tools.
Some of these different modes are already triggering changes in the cursor. However, this is not sufficient because some people may not see these different cursors and because the status bar messages are better for suggesting what modifiers could also be used. I consider the status bar messages to be a useful complement to these cursors.
Note that these messages have to be short enough to fit in the status bar. They may not always fit if the image window is very narrow, but then the user who wants to read the messages can resize the window. The goal is to make the messages reasonably short so that they are entirely visible as often as possible. The suggestion to use some modifiers and the optional description of what these modifiers will do is put at the end of the message so that the essential parts are more likely to be visible.
Also, some tools allow their mode to be changed permanently via the tool options and toggled temporarily via a modifier. For example, toggling between horizontal and vertical modes for the flip tool. A change in the tool option reverses the meaning of the modifier. The messages below suggesting "(try Shift)" or "(try Ctrl)" should probably be built dynamically depending on whether modifiers are pressed rather than depending on the mode of the tool (tool->op).
And finally, most tools only consider the state of the modifiers before the first click for deciding to change their mode. This is the case for most selection tools (Shift/Ctrl for add/subtract/intersect), transform tools, zoom tool, etc. But there are some exceptions, such as siox and iscissors that only consider the modifiers after the area is defined. This has been discussed here a few days ago for the new selection tools. Below, I assume that the old behavior (modifiers considered only when starting) is the correct one because this is the one that brings the best consistency accross all tools. If you want to discuss this, please start a separate thread (new subject).
PATH TOOL (app/tools/gimpvectortool.c)
--------------------------------------
Most messages would remain unchanged, except that "SHIFT" would be
replaced by "Shift". For reference, here are the messages currently
used, with the updated capitalization:
"Click to pick path to edit."
"Click to create a new path."
"Click to create a new component of the path."
"Click to create a new anchor. (try Shift)"
"Click-Drag to move the anchor around."
"Click-Drag to move the anchors around."
"Click-Drag to move the handle around. (try Shift)"
"Click-Drag to move the anchors around."
"Click-Drag to change the shape of the curve. (Shift: symmetrical)"
"Click-Drag to move the component around. (try Shift)"
"Click-Drag to move the path around."
"Click to insert an anchor on the path. (try Shift)"
"Click to delete this anchor."
"Click to connect this anchor with the selected endpoint."
"Click to open up the path."
"Click to make this node angular."
PAINT TOOLS (app/tools/gimppainttool.c)
---------------------------------------
- When nothing has been drawn yet:
"Click to paint, or press Ctrl to pick a color."
- After the first brush stroke:
"Press Shift to draw a straight line. (try Ctrl to pick a color)"
- While drawing a line (Shift pressed):
" Click to draw the line, try Ctrl for constrained angles."
- While drawing a constrained line (Shift+Ctrl pressed):
" Click to draw the line."
- While picking a color (Ctrl pressed):
"Click in any image to pick the foreground color."
In these messages, is the distance shown as number followed
by the current unit. For example, "123.4 pixels" or "0.1234 m".
Tools such as the eraser, convolve and smudge tools can also use these common messages, with some exceptions explained in their own sections below. It would be better to replace the verb "draw" by the appropriate action for the tool, if this is possible (I didn't check). For example: "Press Shift to erase a straight line."
COLOR PICKER (app/tools/colorpickertool.c) ------------------------------------------ - While picking the foreground color: "Click in any image to pick the foreground color. (try Ctrl, Shift)" - While picking the background color: "Click in any image to pick the background color. (try Shift)" As mentioned above, the "try" messages would be different if the mode is changed permanently in the tool options (opposite meaning for Ctrl).
RECTANGLE SELECTION (app/tools/gimpselectiontool.c, gimprectangletool.c) ------------------------------------------------------------------------ Some of the current status bar messages are defined in libgimpbase/gimpbaseenums.c. These messages are OK to describe the undo steps or for PDB help texts, but better messages should be used for the status bar messages.
- While nothing is selected:
"Click-Drag to replace the current selection. (try Shift, Ctrl)"
- While nothing is selected and Shift is pressed:
"Click-Drag to add to the current selection. (try Ctrl)"
- While nothing is selected and Ctrl is pressed:
"Click-Drag to subtract from the current selection. (try Shift)"
- While nothing is selected and Shift+Ctrl are pressed:
"Click-Drag to intersect with the current selection."
- While dragging the rectangle to define the selection:
"Rectangle: dX x dY"
(I really miss the easy toggle for perfect square/circle and
would enjoy being able to add " (try Shift for square)")
- Once the rectangle has been defined, mouse outside the shape:
"Click-Drag to define a new selection. (try Shift, Ctrl)"
(plus the same messages as above for Shift, Ctrl and Shift+Ctrl)
- Once the rectangle has been defined, mouse inside the shape:
"Click-Drag to move the selection. (try Shift, Ctrl)"
(plus the same messages as above for Shift, Ctrl and Shift+Ctrl)
- Once the rectangle has been defined, mouse over the edges:
"Click-Drag to modify the selection. (try Shift, Ctrl)"
(plus the same messages as above for Shift, Ctrl and Shift+Ctrl)
It would be worth adding "Press Enter to confirm" or something like
that to these messages, but they are already a bit long. Suggestions
for better wording are welcome.
Also, I guess that it will take a while for people to discover how to move the selected contents (cut/paste or copy/paste) if they are used to the old tools, but I do not think that it is worth a hint in the status bar. Anyway, once they figure it out and get a floating selection, the following messages can be displayed: - While the mouse is inside a floating selection: "Click-Drag to move the selected pixels." - While the mouse is outside a floating selection: "Click to anchor the floating selection."
FUZZY SELECT (app/tools/gimpfuzzyselecttool.c)
----------------------------------------------
- While nothing is selected:
"Click or Click-Drag to replace the current selection (try Shift, Ctrl)."
- While nothing is selected and Shift is pressed:
"Click or Click-Drag to add to the current selection (try Ctrl)."
- While nothing is selected and Ctrl is pressed:
"Click or Click-Drag to subtract from the current selection (try Shift)."
- While nothing is selected and Shift+Ctrl are pressed:
"Click or Click-Drag to intersect with the current selection."
- While dragging to change the threshold:
"Move the mouse to change threshold."
(Maybe we could say "temporarily change the threshold"?)
INTELLIGENT SCISSORS (app/tools/gimpiscissorstool.c) ---------------------------------------------------- Note: this selection tool is different from the other ones because it ignores the initial state of the Shift+Ctrl modifiers for replace/ add/subtract/intersect and only considers them when the shape has been closed and converted to a real selection (bug #345541). It also has a minor problem showing the correct cursor state for the terminal points (bug #132352). These bugs would prevent useful status bar messages from being shown, so here I assume that these bugs are fixed and iscissors behaves as the other selection tools.
- While no point has been defined:
"Click to replace the current selection (try Shift, Ctrl)."
- While no point has been defined and Shift is pressed:
"Click to add to the current selection (try Ctrl)."
- While no point has been defined and Ctrl is pressed:
"Click to subtract from the current selection (try Shift)."
- While no point has been defined and Shift+Ctrl are pressed:
"Click to intersect with the current selection."
- Once at least one point has been defined, mouse over a point:
"Click-Drag to move the point around."
- Once at least one point has been defined, mouse not over a point:
"Click to create a new point."
- Once at least two points have been defined, mouse over the inital point:
"Click to close the shape."
- Once the shape has been closed, mouse over a point:
"Click-Drag to move the point around."
- Once the shape has been closed, mouse inside the shape:
"Click or press Enter to convert this shape into a selection."
- Once the shape has been closed, mouse inside the shape:
"Press Enter to convert this shape into a selection."
ZOOM TOOL (app/tools/gimpmagnifytool.c)
---------------------------------------
- While no button or modifier has been pressed:
"Click or Click-Drag to zoom in. (try Ctrl)"
- While Ctrl is pressed:
"Click or Click-Drag to zoom out."
- While dragging:
"Move the mouse to define the new visible area."
(I am not sure about what to say if Ctrl was pressed. Suggestions?)
ROTATE TOOL (app/tools/gimprotatetool.c)
----------------------------------------
- While no button or modifier has been pressed:
"Click-Drag to rotate. (try Ctrl for 15d angles)"
(I think that it would be better to say _what_ will be rotated so
that the user is not surprised: "Click-Drag to rotate the mask".
However, this would require different messages for layers, masks,
selections, channels, paths, etc.)
- If Ctrl has been pressed:
"Click-Drag to rotate with 15d angles."
- While the mouse is over the rotation center:
"Click-Drag to move the rotation center."
SCALE TOOL (app/tools/gimpscaletool.c)
--------------------------------------
- While no button or modifier has been pressed:
"Click-Drag to scale. (try Ctrl to keep aspect ratio)"
(Again, it would be better to say what will be transformed)
- If Ctrl has been pressed:
"Click-Drag to rotate with constant aspect ratio."
SHEAR TOOL (app/tools/gimpsheartool.c)
--------------------------------------
- Default:
"Click-Drag to shear."
(Again, it would be better to say what will be transformed)
PERSPECTIVE TOOL (app/tools/gimpperspectivetool.c) -------------------------------------------------- - Default (there should be a modifier for forward/backward modes): "Click-Drag to define perspective." - While the mouse is over one of the handles: "Click-Drag to move this handle around." (Or maybe better: "Click-Drag to move the top left handle around." and similar messages for the other 3 handles.) - While the mouse is over the center point: "Click-Drag to move the whole perspective area."
FLIP TOOL (app/tools/gimpfliptool.c)
------------------------------------
- Default:
"Click to flip horizontally. (try Ctrl for vertically)"
- While Ctrl is pressed:
"Click to flip vertically."
As mentioned above, the messages would be different if the mode is
changed permanently in the tool options (opposite meaning for Ctrl).
TEXT TOOL (app/tools/gimptexttool.c) ------------------------------------ Nothing special.
BUCKET FILL TOOL (app/tools/gimpbucketfilltool.c)
-------------------------------------------------
- Default:
"Click to fill area with foreground color. (try Shift, Ctrl)"
- While Shift is pressed:
"Click to fill selection with foreground color. (try Ctrl)"
- While Ctrl is pressed:
"Click to fill area with background color. (try Shift)"
- While Shift and Ctrl are pressed:
"Click to fill selection with background color."
- If a pattern fill is selected:
"Click to fill area with pattern. (try Shift)"
- If a pattern fill is selected and Shift pressed:
"Click to fill selection with pattern. (try Shift)"
See also the comment above about modes changed in the tool options
(fg/bg/pattern fills). The "(try Shift/Ctrl)" parts should be added
only if the corresponding modifiers are not pressed.
BLEND TOOL (app/tools/gimpblendtool.c) -------------------------------------- Nothing special.
ERASER TOOL (app/tools/gimperasertool.c) ---------------------------------------- Same as paint tools. Although it also supports Alt as a modifier, I don't think that it should be suggested in the status bar (anti-erase is evil).
CLONE TOOL (app/tools/gimpclonetool.c) -------------------------------------- Same as paint tools, except when the source has not been defined yet: "Ctrl-Click to select a clone source."
BLUR/SHARPEN TOOL (app/tools/gimpconvolvetool.c)
------------------------------------------------
Same as paint tools, except before the first stroke:
"Click to blur. (try Ctrl to sharpen)"
- If Ctrl is pressed:
"Click to sharpen."
Note also that pressing Ctrl before or after Shift produces different
results: Ctrl before Shift sharpens in a straight line, while Shift
before Ctrl blurs in a line constrained to 15 degrees angles (see bug
#120973).
SMUDGE TOOL (app/tools/gimpsmudgetool.c) ---------------------------------------- Same as paint tools.
DODGE/BURN TOOL (app/tools/gimpdodgeburntool.c)
-----------------------------------------------
Same as paint tools, except before the first stroke:
"Click to dodge (underexpose). (try Ctrl to burn)"
- If Ctrl is pressed:
"Click to burn (overexpose)."
I'm not sure about which one is over/under-expose. I found some
definitions that seem to be exactly the opposite of what GIMP does.
Can anyone provide a reliable definition of dodge and burn?
Like the convolve tool, this one is affected by the conflicting
modifiers: Ctrl before or after Shift (bug #120973).
FOREGROUND EXTRACTION TOOL (app/tools/gimpforegroundselecttool.c) ----------------------------------------------------------------- The current messages are fine, except that I they should suggest to use Shift or Ctrl to add/subtract/intersect selections. Something like "(try Shift+Enter, Ctrl+Enter)" could be useful and "accept the selection" would be replaced by the appropriate action. However, for greater consistency with other tools I think that it would be better to consider the state of the modifiers _before_ the first click instead of when pressing Enter.
For reference, here are the current messages:
- Before the mask is defined:
"Draw a rough circle around the object to extract"
- Once a mask has been defined, before the first foregound stroke:
"Mark foreground by painting on the object to extract"
- After the first stroke:
"Add more strokes or press Enter to accept the selection"
Phew! That was a long message. Please quote only the relevant parts if you reply. And no need to CC me, since I am on the list.
-Raphael
proposal for better status bar messages (long)
Hi,
On Wed, 2006-06-21 at 21:22 +0200, Raphaël Quinet wrote:
Here is a proposal for improving the messages that are shown in the status bar. Such messages would be very useful for describing some hidden features of the paint tools (bug #124040) but also for the other tools.
Basically, I followed this approach: anything that causes a tool to change its behavior (clicking, dragging or using some modifiers such as Ctrl and Shift) should be displayed or suggested in the status bar. Simon has already done that for the path/vector tool and I would like to apply that to all tools.
A little late to come up with that now. The status bar messages have been waiting for an update for quite a while now. But better late than never. If you want to see such messages in 2.4, hurry up, the string freeze is coming.
RECTANGLE SELECTION (app/tools/gimpselectiontool.c, gimprectangletool.c) ------------------------------------------------------------------------ Some of the current status bar messages are defined in libgimpbase/gimpbaseenums.c. These messages are OK to describe the undo steps or for PDB help texts, but better messages should be used for the status bar messages.
I would suggest that the selection tools are finished before status bar messages are being added. The current state is likely going to change and translators will go crazy if we change the messages over and over again.
FOREGROUND EXTRACTION TOOL (app/tools/gimpforegroundselecttool.c) ----------------------------------------------------------------- The current messages are fine, except that I they should suggest to use Shift or Ctrl to add/subtract/intersect selections. Something like "(try Shift+Enter, Ctrl+Enter)" could be useful and "accept the selection" would be replaced by the appropriate action. However, for greater consistency with other tools I think that it would be better to consider the state of the modifiers _before_ the first click instead of when pressing Enter.
That does IMO not make sense. The SIOX tool, just like the Intelligent Scissors tool requires the user to work on the selection outline for quite a while. It makes much more sense to respect the modifiers when the selection is actually created and that happens at the end, when the user confirms her work and presses Enter.
Sven
proposal for better status bar messages (long)
On Wed, 21 Jun 2006 22:45:55 +0200, Sven Neumann wrote: On Wed, 2006-06-21 at 21:22 +0200, Raphaël Quinet wrote:
[...] However, for
greater consistency with other tools I think that it would be better to consider the state of the modifiers _before_ the first click instead of when pressing Enter.That does IMO not make sense. The SIOX tool, just like the Intelligent Scissors tool requires the user to work on the selection outline for quite a while. It makes much more sense to respect the modifiers when the selection is actually created and that happens at the end, when the user confirms her work and presses Enter.
Users may have a different understanding of what is meant by "when the selection is actually created". Or different expectations. We know that it is only done at the end. But I would not be surprised that many users would consider the first click to be "when the selection is actually created" -- they probably do not care about the difference between a solid outline and marching ants, or between a masked foreground/background and marching ants. They probably consider only when they start defining that selection.
Anyway, my main argument is that it would be more consistent with the other tools: the other selection tools, the transform tools and the zoom tool only consider the state of the modifiers before the first click. Subsequent changes to the modifiers are ignored even if you spend quite some time modifying the selection, the transform parameters or the zoom area: only the initial state matters.
I actually made the wrong assumption once or twice with the iscissors: I wanted to add a new area to a selection so I pressed Shift before clicking on the first point, then added more points, closed the shape, clicked inside it and poof! my selection was gone. I naively thought that it would behave as described above and I did not press Shift for the final click. I lost my selection and I had no way to undo/redo this, except by re-selecting. But maybe I am the only one who has this expectation for the selection tools? I don't know. Only some usability tests could tell what is best...
-Raphaël
proposal for better status bar messages (long)
On Thu, Jun 22, 2006 at 12:08:34AM +0200, Rapha?l Quinet wrote:
Anyway, my main argument is that it would be more consistent with the other tools: the other selection tools, the transform tools and the zoom tool only consider the state of the modifiers before the first click. Subsequent changes to the modifiers are ignored even if you spend quite some time modifying the selection, the transform parameters or the zoom area: only the initial state matters.
I actually made the wrong assumption once or twice with the iscissors: I wanted to add a new area to a selection so I pressed Shift before clicking on the first point, then added more points, closed the shape, clicked inside it and poof! my selection was gone. I naively thought that it would behave as described above and I did not press Shift for the final click. I lost my selection and I had no way to undo/redo this, except by re-selecting. But maybe I am the only one who has this expectation for the selection tools? I don't know. Only some usability tests could tell what is best...
i really tried to use siox this weekend. it is so confusing, i have no idea what to expect from it or if what happened to me was a bug.
the default is foreground extraction. i wanted it to background extract and toggled this tool option. it toggled itself back to foreground and it also could not see an honest line that was in the image. a dark brown/gray area that ended in a very straight line before a very bright (luminescent even) area started (which was the background i wanted to extract.
it would not stay toggled and it seemed to be blind to the colors no matter what values i gave it. it only selected what i selected which, i could have used quickmask for and it would have been a lot less toggling and such.
is the tool broken or are my expectations all wrong?
i am honestly way to baffled to go to bugzilla with this even.
it would be one heck of a status bar message to explain how to use this tool.
also, the tooltips are popping up some freaking huge tool tips. it is the long help that is in the script-fu? i think it was some of the third party scripts i have installed that were doing this -- i did not find it at all helpful.
is GIMP showing the help blurb or the about blurb from the scripts?
carol
proposal for better status bar messages (long)
Carol Spears wrote:
it would not stay toggled and it seemed to be blind to the colors no matter what values i gave it. it only selected what i selected which, i could have used quickmask for and it would have been a lot less toggling and such.
is the tool broken or are my expectations all wrong?
Can you provide and/or point out the image you tried it on?
Michael
proposal for better status bar messages
On Thu, Jun 22, 2006 at 12:49:22AM +0200, Michael Schumacher wrote:
Carol Spears wrote:
it would not stay toggled and it seemed to be blind to the colors no matter what values i gave it. it only selected what i selected which, i could have used quickmask for and it would have been a lot less toggling and such.
is the tool broken or are my expectations all wrong?
Can you provide and/or point out the image you tried it on?
it is the image that makes the tool options toggle?
when i select background, it is wrong for me to expect that background continue to be selected or it relies on the image to retain the toggle?
that is a really intelligent tool then that will not retain the tool option toggle depending on the image.
i think that the problem with the tool should not have anything to do with 1) the image being worked on or 2) who is using the tool.
should i expect that when i toggle the tool options that they stay toggled?
thank you for responding, btw. it is an interesting environment where every user matters except for one. what kind of environment is this good for?
carol
proposal for better status bar messages (long)
On Wed, Jun 21, 2006 at 03:36:53PM -0700, Carol Spears wrote:
also, the tooltips are popping up some freaking huge tool tips. it is the long help that is in the script-fu? i think it was some of the third party scripts i have installed that were doing this -- i did not find it at all helpful.
is GIMP showing the help blurb or the about blurb from the scripts?
http://carol.gimp.org/bikeshed/images/screenshot-2006-06-21.png
fitting a whole tutorial into that area does not really seem as if it was the most helpful thing....
let me apologize to everyone whose little freesoftware project i have been involved in for how many years is it now? i really had to send mail out to say that $3000 was not worth it for a nice girl to get involved in something like how this project worked.
if i am following the logic that i have received locally, i was one of the first people to have become successful with something like GIMP. $3000 would not have kept me from having real life problems like i did and do. it would have been the very very wrong thing to just let other girls or nice people fall into the same trap. it seems like california has all of the problems michigan did, just with gender removed.
it is more wrong to use and discard people than it is to have been nice and unable to live up to those expectations.
also, sorry if actually USING the software makes it difficult to report bugs with that language everyone insists on. the fact that i am using it and that i was successful with the project and the people when i had my life and stuff really ought to count for something.
mostly i am sorry that this world does not allow a girl to be successful at something without spending the next few years trying to and maybe succeeding in destroying her.
do you know what has not been in my life now since may of 2003? love. if there is no love in a life or in a project it is just going to suck for everyone. everywhere around me, love is bought and sold and traded or only used to make families. let me be somewhere where there is some love and maybe even my stuff and then feel free to complain if i am not being nice.
no outlet for when there is a problem. no love. no acknowledgement. and the biggest problem is this. it really looks like a bunch of mean minded little males or malelike females who keep a calendar and know when to start being unreasonable.
and there. this email is perhaps the best example of what is wrong when you fit a whole tutorial into what should be a small space. you can see from the screenshot that there are some real problems with this new thing.
if i am to consider that the developers who work with this project are human beings and have real life issues that need consideration and also that whatever i expect from them is just my own idea and i should not actually expect anything -- when does that start from those same people back to me?
in closing, one of the things that i really really remember from when everything started to go so badly and wrong is something that scizzo said. i am paraphrasing now: "can we work next time as a team?"
i never ever wanted to be alone working on this stuff. never ever did i ever think that i could accomplish anything alone.
who do i thank?
carol
proposal for better status bar messages (long)
On 6/22/06, Carol Spears wrote:
http://carol.gimp.org/bikeshed/images/screenshot-2006-06-21.png
Okay.
It looks like there is a bug in the SIOX tool/gui that causes it to return
to the foreground setting unexpectedly, until the Control key is first
pressed, then it works as expected.
the 'Contiguous' option being off seems to be key in this case. I still can't get it to do quite what i tried to make it do. Anyway.. this is a dubious use of this particular tool; it was designed for use on photographic-type images, which your example is quite unlike. I've tried it on photographs and it generally performs pretty well. For this case I would have guessed immediately Fuzzy select would be the quickest route to success, and it did turn out that way: it took me ~45 seconds to select all the gradients without the lines or windows.
Though, I suspect that you are tied up in your frustration and thereby preventing yourself from doing things effectively. Maybe you have a genuine grievance or maybe you're just behaving lazy. Personally, I've always found a workout(preferably involving approaching serious peril, and demanding enough to get adrenaline running) good to clear my head and sort out my feelings, decide on something.
proposal for better status bar messages (long)
On Thu, Jun 22, 2006 at 12:09:24PM +0930, David Gowers wrote:
On 6/22/06, Carol Spears wrote:
http://carol.gimp.org/bikeshed/images/screenshot-2006-06-21.png
well, i did not use the tool on that image. that image is my desktop and what is wrong with some of the third party scripts with this new tooltip thingie.
Okay.
It looks like there is a bug in the SIOX tool/gui that causes it to return to the foreground setting unexpectedly, until the Control key is first pressed, then it works as expected.
i appreciate that you tried to use the tool and can verify that it is returning to the foreground setting like that.
the 'Contiguous' option being off seems to be key in this case. I still can't get it to do quite what i tried to make it do. Anyway.. this is a dubious use of this particular tool; it was designed for use on photographic-type images, which your example is quite unlike. I've tried it on photographs and it generally performs pretty well. For this case I would have guessed immediately Fuzzy select would be the quickest route to success, and it did turn out that way: it took me ~45 seconds to select all the gradients without the lines or windows.
pathtool works the best for me. i want to write a tutorial for siox though so i have lately been trying to use this tool so that i can write one. it was suggested at the gimp convention that a tutorial should be written.
you know how suggestions go, you try to take the good ones and ignore the wrong ones. at least, this is the approach i am trying to take.
Though, I suspect that you are tied up in your frustration and thereby preventing yourself from doing things effectively. Maybe you have a genuine grievance or maybe you're just behaving lazy. Personally, I've always found a workout(preferably involving approaching serious peril, and demanding enough to get adrenaline running) good to clear my head and sort out my feelings, decide on something.
heh. i think that you are probably right about this. the situation is wrong wrong wrong wrong wrong for adrenaline running in my life right now. all i can do is sit and count the wrongs about it.
this in itself is very frustrating.
thanks for the verification,
carol
proposal for better status bar messages (long)
Hi,
On Thu, 2006-06-22 at 12:09 +0930, David Gowers wrote:
It looks like there is a bug in the SIOX tool/gui that causes it to return to the foreground setting unexpectedly, until the Control key is first pressed, then it works as expected.
That's not a bug. You cannot mark background unless you first have marked some foreground area. When you start, the whole image is considered background, so there's really no point in marking background areas.
I suggest that you go to http://www.siox.org/ and read about the tool. It is somewhat unfortunate that one needs some basic understanding of the ideas behind SIOX in order to be able to make good use of the tool. But I don't see how this could be avoided.
Sven
proposal for better status bar messages (long)
Hi,
On Thu, 2006-06-22 at 00:08 +0200, Raphaël Quinet wrote:
Anyway, my main argument is that it would be more consistent with the other tools: the other selection tools, the transform tools and the zoom tool only consider the state of the modifiers before the first click. Subsequent changes to the modifiers are ignored even if you spend quite some time modifying the selection, the transform parameters or the zoom area: only the initial state matters.
All the other tools create the selection immidiately. All tools consider the state of the modifiers at the moment you create the selection. Whether that is the first click or not seems irrelevant to me.
I actually made the wrong assumption once or twice with the iscissors: I wanted to add a new area to a selection so I pressed Shift before clicking on the first point, then added more points, closed the shape, clicked inside it and poof! my selection was gone. I naively thought that it would behave as described above and I did not press Shift for the final click. I lost my selection and I had no way to undo/redo this, except by re-selecting. But maybe I am the only one who has this expectation for the selection tools? I don't know. Only some usability tests could tell what is best...
This wouldn't have happened to you if you have had a look at the cursor changes. BTW, does anyone object to removing the possibility of turning context dependant cursors off? They are very important and I can't really imagine that someone would want to work without them.
Sven
proposal for better status bar messages (long)
On Wed, 2006-06-21 at 15:36 -0700, Carol Spears wrote:
i really tried to use siox this weekend. it is so confusing, i have no idea what to expect from it or if what happened to me was a bug.
the default is foreground extraction. i wanted it to background extract and toggled this tool option.
The tool only does foreground extraction (hence its name). There's no toggle that would turn it into a background extraction tool.
Sven
Modifiers before or after first click in selection tools (was Re: status bar messages)
On Thu, 22 Jun 2006 08:21:46 +0200, Sven Neumann wrote:
On Thu, 2006-06-22 at 00:08 +0200, Raphaël Quinet wrote:
Anyway, my main argument is that it would be more consistent with the other tools: the other selection tools, the transform tools and the zoom tool only consider the state of the modifiers before the first click. Subsequent changes to the modifiers are ignored even if you spend quite some time modifying the selection, the transform parameters or the zoom area: only the initial state matters.
All the other tools create the selection immidiately. All tools consider the state of the modifiers at the moment you create the selection. Whether that is the first click or not seems irrelevant to me.
This is not really true for the rectangle or ellipse selection tools or even the free select tool (lasso).
I think that you are taking the developer's point of view here, considering when the data structures are created rather than the user's workflow. If you look at the code and see that the selections (the data structures) are created only once the shape has been fully defined, then it makes sense to say that the modifiers deciding if the new selection should be added to, subtracted from or intersected with the old one should only be considered when the data structures exist.
But if I think about how I work with selections, I usually do the following: I start with a selection created with one of the "complex" tools (iscissors, path converted to selection, magic wand or siox) and then adjust this selection by adding or removing some areas with one of the "quick" (one click) tools such as free select or rect select.
Sometimes I also use one of the "complex" selection tools for adjusting the initial selection. In these cases, the decision to add/subtract/intersect is always taken before the first click with the other selection tool: I start creating the new selection because I know that I will add or subtract it from the existing one.
From that point of view (user's workflow), it makes sense to consider the
state of the Shift and Ctrl modifiers when the decision to add or subract is taken, which is (at least for me) before the first click. In other words, I think about the modifiers when I start to define what the new selection will be rather than when the selection (the internal data structure) is created.
This is only my point of view and I may be biased, that's why I suggested some usability tests to check what is best. If we do not have the time or resources for that, we could at least ask for the opinion of our resident artists or maybe discuss that on gimp-user. From my point of view, I consider the usage of modifiers in iscissors and siox to be inconsistent with other selection tools and I would like to fix that. But I also understand your point of view, which is closer to how the code works.
This wouldn't have happened to you if you have had a look at the cursor changes.
I know that the cursors are there to help, but it is too easy for me to forget to press Shift or Ctrl again when I finish drawing the shape, maybe because I have the wrong expectations about how the tool should behave.
Besides, the cursors are actually wrong and misleading for siox.
Compare what happens with one of the simple selection tools (rectangle,
ellipse or free select) and with siox. With free select, I do this:
- Press Shift to add to the current selection: the cursor shows a "+".
- Click to start defining the new selection, release Shift: the "+" is
still there while I move the mouse around.
- Release the mouse button to finish defining the selection: the new
selection is created and added to the current one.
With siox (which uses exactly the same cursor), I do this:
- Press Shift to add to the current selection: the cursor shows a "+".
- Click to start defining the new selection (for siox, the first step
is to define the area around the object), release Shift: the "+" is
still there while I move the mouse around.
- Release the mouse button to continue with the second step of siox
(paint over the foreground): now the "+" is gone.
- Press Enter to finish defining the selection: the new selection is
created and replaces the current one, despite what the initial
cursor was showing.
I just discovered this bug, thanks to your suggestion to look at the
cursors. Before attempting to fix it, I think that we should decide
what is the correct behavior: considering the state of the modifiers
before or after the selection is defined (user's point of view) vs.
before or after the selection is created (developer's point of view).
[...] BTW, does anyone object to removing the possibility of turning context dependant cursors off? They are very important and I can't really imagine that someone would want to work without them.
I thought that one of the reasons for having this as an option was that some displays did not allow them or did not work well with them (severe performance degradation due to lack of acceleration for this feature). If this is not a concern anymore, than I agree with the removal of this option. If some people have a bad vision or a bad screen and have problems seeing the changes in the cursors, then hopefully the new status bar messages should help them.
-Raphaël
proposal for better status bar messages
On Thursday, June 22, 2006, 8:21:46, Sven Neumann wrote:
This wouldn't have happened to you if you have had a look at the cursor changes. BTW, does anyone object to removing the possibility of turning context dependant cursors off? They are very important and I can't really imagine that someone would want to work without them.
One of the first things I do in graphic programs is to disable the tool cursors, and use the cross-hair only (except for brushes, where I also enable the brush outline). Though, to tell the truth, I highly prefer the crosshair used in PaintShopPro to GIMP's.
proposal for better status bar messages
On Thu, Jun 22, 2006 at 02:56:36PM +0200, Michael Schumacher wrote:
Von: Carol Spears
On Thu, Jun 22, 2006 at 12:49:22AM +0200, Michael Schumacher wrote:
Carol Spears wrote:
it would not stay toggled and it seemed to be blind to the colors no matter what values i gave it. it only selected what i selected
Can you provide and/or point out the image you tried it on?
it is the image that makes the tool options toggle?
I'm mainly interested in the "color-blind" behaviour you're dexcribing, unless this was a side effect of the unstable toggle.
honestly, i have no idea if it was the irratic behavior of the tool (amplifying my frustration as was pointed out in another email about this/these problems) or tht the tool is stupid right now.
the image is on my web log and also should be on layers.gimp.org. i wanted to put some of the detail back into the window that the original photograph lost because it was out of focus.
carol
proposal for better status bar messages (long)
... AARRGH.
Accidentally sent this to Sven instead of the list!
Sorry Sven.
On 6/23/06, David Gowers wrote:
The tool only does foreground extraction (hence its name). There's no
toggle that would turn it into a background extraction tool.
Makes sense, actually -- the characteristics of a background are less clearly defined than that of an object.
Carol, your test subject is extremely uncooperative. Attempting to select the foreground and omit all else met with little success:
http://img.photobucket.com/albums/v449/neota/tech/gimp/screenshot-2006-06-21-try.png
I guessed from what Sven said, inverting the image colors first might help, and I was right.
I made my second try by:* Inverting the image * Selecting the entire image in the initial 'lasso' pass. * Disabling 'Contiguous'
* Setting L,a,b sensitivity to 0,707,555 respectively. (a,b was just a guess, but L was 0 to accommodate the harsh brightness contrasts of the widgets)
* Switching to background mode
* Scrawling a bit (~3 strokes) on the windowsOverall it was quite straightforward, actually.
http://img.photobucket.com/albums/v449/neota/tech/gimp/screenshot-2006-06-21-try2.png (selected areas marked in blueness -- the window 'shadow' got selected, but otherwise it seems quite satisfactory.)
.. My experience above causes me to wonder if 'BGselect' could be made by inverting the L*a*b values before interpreting them; maybe something to try after 2.4.
proposal for better status bar messages (long)
I guessed from what Sven said, inverting the image colors first might
help, and I was right.
I made my second try by:
* Inverting the image * Selecting the entire image in the initial 'lasso' pass. * Disabling 'Contiguous'
* Setting L,a,b sensitivity to 0,707,555 respectively. (a,b was just aguess, but L was 0 to accommodate the harsh brightness contrasts of the widgets)
* Switching to background mode
* Scrawling a bit (~3 strokes) on the windowsOverall it was quite straightforward, actually.
http://img.photobucket.com/albums/v449/neota/tech/gimp/screenshot-2006-06-21-try2.png
(selected areas marked in blueness -- the window 'shadow' got selected,
but otherwise it seems quite satisfactory.)
.. My experience above causes me to wonder if 'BGselect' could be made by inverting the L*a*b values before interpreting them; maybe something to try after 2.4.
I do not quite understand your problems. I am an aloof developer who has serious problems to understand user's problems. Please help me out, maybe I am misunderstanding something? So please do not get me wrong here.
What one defines foreground or background is not a matter of the tool but a matter of the human being who is using the tool.
I cut out the windows selecting them all with the lasso. See: http://www.gerald-friedland.de/tmp/multiwindow_sel.png
Then I disabled contiguos because the Windows in this image are not connected (may be "disconnected" would be a better string?).
Then I needed a few foreground strokes, mainly to select the KDE toolbar (or was it GNOME) and to include all the colors shown in this GIMP tool dialog.
The result is then: http://www.gerald-friedland.de/tmp/multiwindow_cutout.png
If you want to have the screen-background instead of the windows, use "select/invert" and you get the background instead of the foreground...
No need to fiddle with color sensitivity....?
Greetings, Gerald
proposal for better status bar messages (long)
.. I replied to the wrong address again; argh.
On 6/24/06, David Gowers wrote:
On 6/23/06, Gerald Friedland wrote:
I do not quite understand your problems. I am an aloof developer who has serious problems to understand user's problems. Please help me out, maybe I am misunderstanding something? So please do not get me wrong here.
What one defines foreground or background is not a matter of the tool but a matter of the human being who is using the tool.
If you want to have the screen-background instead of the windows, use
"select/invert" and you get the background instead of the foreground...
As far as I know, foreground and background are still objectively different from the computer's point of view and our point of view; they have different characteristics. A background tends to be less detailed than a foreground; also, the definition of background is further muddied by the possibility of having multiple overlapping objects at different depths.
You clearly understand the tool(and maybe the algorithym too) better than I.
However, my basic point is that 'what is not foreground' may mean something quite different from 'what is background'; the only case in which this will be false is when all objects are all at the same depth.
proposal for better status bar messages (long)
On Fri, Jun 23, 2006 at 03:27:19PM +0200, Gerald Friedland wrote:
I do not quite understand your problems. I am an aloof developer who has serious problems to understand user's problems. Please help me out, maybe I am misunderstanding something? So please do not get me wrong here.
heh.
What one defines foreground or background is not a matter of the tool but a matter of the human being who is using the tool.
what is the purpose of a toggle that says "Background"?
this was my expectation. i guess i would be an aloof user who refuses to try any longer to understand where the developers minds are at when they do things...
when i toggled it from Foreground to Background, my expectation was to manage what was selected. it seems sort of silly now that i write about it. my goal was to make the parts i wanted to select be what was floated.
perhaps a lot of the confusion would disappear if the background/foreground toggle disappeared.
as i have considered it since using the tool, it makes sense to me that it makes no difference what is selected.
however, the tool option is there.
I cut out the windows selecting them all with the lasso. See: http://www.gerald-friedland.de/tmp/multiwindow_sel.png
i honestly wrote this before looking at any of the urls.
bad form. i will apologize if that is helpful. i am still somewhat stuck with the image in my mind of where the developers minds are though....
carol
proposal for better status bar messages (long)
Hi David!
As far as I know, foreground and background are still objectively
different from the computer's point of view and our point of view; they have different characteristics. A background tends to
be less detailed than a foreground; also, the definition of background is
further muddied by the possibility of having multiple overlapping objects at different depths.
I see your point. The problem is that humans might have an intuition for background although it does not work for all pictures.
If there were any objective difference between background and foreground then a foreground selection tool would exist with a hundert percent robustness and nobody would care about extracting manually or even semi-automatically because the entire problem would not exist. One could just use this objective criterion on any image without any user interaction and let the computer do the segmentation (even in batch mode).
The reality is that there is no unique definition to distinguish foreground from background in every picture.
You can prove this easily:
Given a picture that consist of one white pixel and one black pixel.
What is foreground now?
Four possible answers:
- "None" or "Both pixels" => No differentiation possible. Thanks, no
further argumentation needed.
- "White" => OK. You define all white pixels to be foreground. Given
this definition of foreground, I won't have to show you millions of
photographs where this definition does not work, will I?
- "Black". See "white".
- You give any other definition. This will not apply to the two-pixel
checkerboard.
=> No unique definition for foreground or background exists that works
for all all images. Sorry.
You clearly understand the tool(and maybe the algorithym too) better than
I.
However, my basic point is that 'what is not foreground' may mean
something quite different from 'what is background'; the only case in which this will be false is when all objects are all at the same depth.
In this point you are right. As it is not clear what foreground and background is, it is well possible for a given picture, that a third, fourth, fifth class exists...
SIOX is a heuristics and there are several assumptions behind it:
1.) The user wants to extract one object (one connected pixel area) or
a set of objects (several connected pixel areas) of similar color
structure [=foreground].
2.) The foreground has an overall different color structure than the
rest of the picture [=background].
3.) The user provides the algorithm with information of the color
structure of the background and gives a spatial hint where the
foreground may reside. This is done by drawing the first lasso
selection. Everything outside the lass is considered background.
4.) The user provides further information on the color structure of
the foreground. This is done using the foreground brush marking.
Then the SIOX algorithm classifies those pixels that are not background and not part of the foreground marking by comparing their "perceptual similarity" to these two classes. Further (foreground or background) markings can be added if SIOX' first guess wasn't satisfying.
So given the heuristics defined by SIOX, background is the true opposite of foreground. If for some reason it might be hard to extract "background" with SIOX: Try to extract the "foreground" and invert the selection.
However, because no unique definition of background or foreground exists, there will always be images where any automatic foreground extraction fails (even the one working in our brains). The good thing about SIOX is that it works better for more images than the other extraction tools that I know.
Gerald
proposal for better status bar messages (long)
Hi,
On Fri, 2006-06-23 at 11:49 -0700, Carol Spears wrote:
what is the purpose of a toggle that says "Background"?
There is no toggle that says "Background" in the options of this tool. That's why I will not try to answer the rest of your mail. You would better look at the tool options again and stop annoying us with your unqualified mails.
Sven
