After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 709875 - Foreground select tool needs improvement / new UI
Foreground select tool needs improvement / new UI
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: Tools
git master
Other All
: Normal normal
: 2.10
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2013-10-11 03:15 UTC by Jehan
Modified: 2014-04-18 22:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Example of using forground select in master (40.87 KB, image/jpeg)
2013-12-05 15:09 UTC, Daniel Sabo
  Details
Give Foreground Select more of an interface (15.14 KB, patch)
2013-12-10 08:55 UTC, Daniel Sabo
none Details | Review

Description Jehan 2013-10-11 03:15:35 UTC
I just tested the foreground select tool on GIMP master.

Well it just does not work. Like at all.

Reproduction step:

1/ select the foreground select tool;

2/ roughly select with the lasso;

3/ stroke the foreground.
Result: the strokes immediately disappear.
Expected result: the strokes should stay visible.

3 (alt)/ stroke the background;

4/ enter to preview;
Result: the initial rough selection is never updated, whatever you stroked before (foreground or background, etc.).
Expected result: the rough selection should be updated.

5/ Enter to commit.
Result: same as preview, you get what you had originally roughly selected (minus any background stroke, if you did so; foreground stroke never seem to do anything). AND instead of a selection, it becomes a layer mask!
Expected result: the selection should be updated after your stroke AND that should be a selection, NOT a mask. Or the tool should be renamed, and that would stop being consistent from old behavior, so I guess that's not an option. :-p

Note: broken only on master, gimp-2-8 is still fine.
Comment 1 Max Mustermann 2013-10-11 03:47:04 UTC
Yes the tool is still broken in master. Lately there was an attempt to implement a new algorithm for it in GEGL and GIMP master (ask mirecta on IRC). IIRC one point of it was to improve selection of semi-transparent areas. Unfortunately there were problems in finding out more about Jan Rueggs implementation and AFAIK things stopped then. What is left is a half-done feature, like a zombie in code :-( No matter whether the work on it continues or is reverted - we're left with extra work.
Shouldn't we eventually start with feature branches and not start with it in 2.10 how it was suggested at LGM 2011 or 2012? We see the disadvantages of direct hacking on master almost every day (especially when the developer stops working on a feature for some reasons) and have seen the benefits of separate branches in GSoC... Sorry for posting it here, I'll bring up this suggestion on the ML next.
Comment 2 Jehan 2013-10-11 03:56:04 UTC
No you are right. If that's the story of this code, then it's another very good explanation of why feature branches are necessary. I thought that everyone in the team was already working in feature branches, actually.

Here that's just an ugly nothing, and a huge feature loss.

I don't think I could make time to fix this code, but if really nobody is working on it, and planning to do so before 2.10, I may find time to at least search all the relevant commits, cherry-pick them in a public branch for someone to continue later, and revert them on master.
Should we do this, or someone is actually planning to finish the tool improvements?
Comment 3 Michael Natterer 2013-10-11 07:48:37 UTC
The tool was *completely* disabled (not ported to GEGL) before the work was
started, in this particular case, doing the changes directly in master seems ok.
Comment 4 Michael Natterer 2013-11-17 00:06:15 UTC
We should also fix bug 312780, which is easy now.
Comment 5 Daniel Sabo 2013-12-04 21:21:52 UTC
The version in master should work, but in the current code the lasso selects the Foreground not the unknown, which means if you just lasso the tool will have nothing to do.

Before pressing enter you should have:
Solid blue: Not selected
Somewhat blue: Maybe selected
No color: Always selected
Comment 6 Jehan 2013-12-05 06:38:10 UTC
Hi Daniel,

I just tested GIMP/GEGL/babl master. I've tried on an image which works perfectly with 2.8 (the foreground piece to extract being quite different from the background). On GIMP 2.8, I roughly select the foreground, make a few stroke, and the object is magically selected. With master, same as in the description happens; that looks a lot like some kind of "toggle quick-mask" feature (which is useless since toggle quick mask already exists!): you can stroke foreground and background, but that's it. No magic foreground extraction.

Is it actually working on your master? If so, can you tell me what you do? Because I really scrupulously follow the tool indication and what is supposed to happen definitely doesn't. Did I miss something?

> in the current code the lasso selects the Foreground not the unknown

Well that's also the case on 2.8, but that's not the problem I raise here, I think. Up to the lasso selection, everything seems to work ok. The problem is at the stroking part where no selection recomputation happens.

> if you just lasso the tool will have nothing to do.

Yes I have to stroke afterwards, which I guess is the whole point of this tool because it allows to recompute the selection. Or are you saying something else maybe?
Comment 7 Daniel Sabo 2013-12-05 15:09:17 UTC
> > in the current code the lasso selects the Foreground not the unknown

> Well that's also the case on 2.8, but that's not the problem I raise here, I
think. Up to the lasso selection, everything seems to work ok. The problem is
at the stroking part where no selection recomputation happens.

NO! In 2.8 the lasso selects the "Unknown" the parts that might be part of the  final selection but could also be background. Then in 2.8 you stroke part of the "Known foreground".

In current master the lasso selects things that will be part of the mask no matter what, you then stroke around the edge with "Draw Unknown" selected under tool options. The tool only does things where you have used Draw Unknown: everything inside the initial lasso will be 100% selected unless you paint over it.

I've attached what it should look like before you hit enter.
Comment 8 Daniel Sabo 2013-12-05 15:09:48 UTC
Created attachment 263597 [details]
Example of using forground select in master
Comment 9 Daniel Sabo 2013-12-05 15:30:40 UTC
In case I misread this part of your question:

> no selection recomputation happens.

Press Enter (twice) when you're done with the paint step. First Enter is the preview, the second writes it to the mask.


Addendum:
I'm not saying that the UI is good or even usable. It took me forever to figure out what it is now taking forever for me to explain. But it is connected to a set of working internals.
Comment 10 Daniel Sabo 2013-12-10 08:55:04 UTC
Created attachment 263895 [details] [review]
Give Foreground Select more of an interface

I think this is far enough along for public scrutiny, the dialog is kindof hacky but it seems to be the most practical interface available.

When in preview mode you can press the preview button again to go back to edit, or you can just start drawing again and it will jump back to edit; not sure how to make feature that more obvious. I tried changing the dialog button labels after it's displayed but that breaks the layout.

It writes to the selection again instead of the layer mask, if writing to the layer mask directly is a desired feature we could add another button for that.

The Feather option seems useless for this tool and could probably be hidden too.
Comment 11 Jehan 2013-12-14 06:44:17 UTC
Hi,

I've just tested the update in master, hoping to see improvements. Well I got 3 main issues, 2 being worse than the previous broken flow:

1/ Now I can't even select Matting Level anymore, which was the only engine which at least "did something" (cf. our discussion on IRC). There is only Matting Global showing now and the widget is grayed out. And well... it does not work.

2/ Also I don't really understand the purpose of this dialog box you added. It just comes in the way. At the very least, have the dialog *not appear* until the tool actually started (which is likely once the lasso selection is created), and disappear after the effect is applied.
For instance here is a typical issue with this dialog staying in front: this tool is made to create a selection, so once applied, you may want to do something with this selection directly. Like a copy or a cut; and since you do it fast, you use a shortcut (ctrl-c or ctrl-x); but since the dialog has the focus, it does not work. You are forced to manually click on the main window to give it focus or select another tool, which breaks the working flow.

And in any case, this whole dialog box has absolutely no use altogether. It was a much better flow without a box, even the previous broken flow was better. This tool is quite simple to use. Status text is really enough to get it.

3/ And why does it have to be a 2-step tool? Can't the GEGL version do like it used to work on the 2.8 version? Instant preview is so much better.

I can see only one thing which improved here, is that the finale result is finally a selection, not a mask, which is the expected behavior.
Comment 12 Daniel Sabo 2013-12-14 06:56:04 UTC
> Now I can't even select Matting Level anymore
Because the op was never there for you, you need to build GEGL with umfpack to get it. The results you were seeing was just copying a grayscale of the image to the alpha channel (aka garbage output from an invalid graph).

> Also I don't really understand the purpose of this dialog box you added. Because there needs to be some indication of what the next step is, I agree that it is not much of a GUI and mitch has said he will be making improvements.

> And why does it have to be a 2-step tool?
Because computing the mask is expensive and you get much better results if you make the trimask (the blue overlay) more accurate.
Comment 13 Daniel Sabo 2013-12-14 06:59:14 UTC
Could you please attach:

1. The image you are attempting to select on.
2. A screenshot of the blue mask just before you hit preview.
Comment 14 Jehan 2013-12-14 09:11:10 UTC
> The results you were seeing was just copying a grayscale of the image
to the alpha channel (aka garbage output from an invalid graph).

You could have said it this way on IRC instead of yelling and basically saying I was lying that I saw "something" happen. One more good point of Bugzilla over IRC.

> Because there needs to be some indication of what the next step is, I agree that it is not much of a GUI and mitch has said he will be making improvements.

Ok. But there was already indication before through the status bar. And it feels much less intrusive and nicer this way for a fast workflow.

> Because computing the mask is expensive and you get much better results if you
make the trimask (the blue overlay) more accurate.

Ok. Then what about some compromise? Like an inaccurate less expensive live preview, with the possibility to get a more accurate preview through a button with some more computing? Because I feel that if you have to check the preview after each stroke by clicking a button (which is likely what people would do, no?), then the good point of expensive computing is not so worth it anymore. They may prefer live preview, even if it is to the price of some processing slowness. I would feel so if I had to use this often.

But I may be wrong. That depends on how people would really use the tool. I guess this should be gathered from actual users.

> Could you please attach:

I will do some other day. I don't think I'll be in the mood to touch this for many days now.
Comment 15 Daniel Sabo 2013-12-14 09:28:42 UTC
I was attempting to explain that the part I "broke" did nothing before I removed it, and I expect more detail than repeatedly saying the tool does nothing from someone who considers themselves a GIMP developer.

> Ok. Then what about some compromise?
I have been experimenting with it more and I think that enabling painting in preview mode will work well enough, this is basically the behavior of gimp 2.8. I would like to keep the mask mode because it's easier to paint refinements when it doesn't pause after each update, thought it's also harder to tell what needs refining.

> I will do some other day.
I am frustrated with you because you have written several pages of bug report here and repeatedly claimed nothing works while refusing to provided anything useful for debugging. The tool works for many other people who have tested it, and the only way you can end up with the behavior you describe is if there are only Foreground + Background pixels in the mask.

Please just attach a screenshot of your mask step so I can understand what you are attempting to do.
Comment 16 Max Mustermann 2013-12-15 10:39:36 UTC
I looked around to find something for the UI. Unfortunately there we have no spec. 

Existing artifacts are: 
- Drafts for improved selection tools from Peter Sikkings interaction design course at FH Vorarlberg, Austria: http://blog.mmiworks.net/2011/08/teaching-interaction-10.html
- Drafts for the Liquid rescale plug-in from Peter Sikkings interaction design course at FH Vorarlberg, Austria: http://blog.mmiworks.net/2012/05/teaching-interaction-12.html. The Liquid rescale plug-in also has to deal with three masks: areas to discard, protect and scale.
- Jan Rüeggs existing work: http://libregraphicsworld.org/blog/entry/what-hasnt-happened-to-gimp-2.8 (half down the page). 
- PS: the foreground extraction is part of the Quick select tool, which combines the Magic Wand tool with a brush-like interaction. There's a button 'Refine selection' which opens more options (what would be our tool dialog). See https://www.youtube.com/watch?v=v4i5-0hrU-Y, the relevant part starts at around 5:00. Yes, cloning the PS UI is not our aim and to be honest, the PS options dialog isn't very easy at the first glance. 
- Corel PhotoPaint, Corel Paint Shop Pro (1): the basic (or former?) background removal tool is a simple, intelligent brush. The users eliminate the background by brushing over it. It seems to work only for clear cases with blue sky backgrounds and clear edges. However, it's the simplest interaction I've found so far. 
- Corel PhotoPaint, Corel Paint Shop Pro (2): extended background removal tool uses a trimap. After marking foreground and background the users brush over the selections border to add/remove detail iteratively. See https://www.youtube.com/watch?v=-UyNVJCTOvA
- Corel Knock-Out: was the first professional tool to extract foregrounds AFAIK. It's also a trimap solution. In this video the user selects foreground and unclear areas, the rest is done automatically: https://www.youtube.com/watch?v=E0Yhjy-est0 and http://www.ehow.com/how_7584004_corel-knockout-2-operating-instructions.html.

From the users point of view extracting hairs, tree branches or semitransparent object from an image is a hard task you wouldn't wish even your evilst enemy. Additionally workers in creative jobs don't have much time. So the users expect something working well out of the box, which doesn't require much work or thinking.  

We already have established tools in GIMP to mark foreground: the Selection tools. Everything outside can be seen as background. So we don't need to reinvent and reimplement mask selection in the Foreground selection tool.

My proposals are: 
1. Drop the whole Foreground selection tool. Improve the Magic Wand, Select-by-Color and Intelligent Scissors tools with the matting algorithms instead.
2. Only implement a refinement brush tool with two modes to add and subtract detail (the 2nd Corel Photopaint solution). Let the users add and remove detail iteratively. The tool could work in Quickmask or normal selection mode or both. 
3. Like 2, but hide the tool from the toolbox. Instead add an item 'Refine Selection' to the 'Selection' menu next to 'Feather/Grow/Shrink Selection'.


Eventually we need an experts opinion - Peter, how is your opinion?
Comment 17 Michael Natterer 2014-02-04 15:30:45 UTC
Please use NEEDINFO only for asking non-developer reporters. Otherwise it's
a nice way of hiding the bug from all developers.
Comment 18 Michael Natterer 2014-04-18 22:39:24 UTC
The tool has been refactored a lot, this general bug is no longer needed,
please file new bugs for individual issued.