Add an option to union enclosed fragments

[hinerm]

Given a scenario like the below screenshot, it would be awesome if we had an option that would do a second pass to unify regions with junction points at both terminals.

For example, looking at selection 125, simply use it to union together all adjoining selections. This would create two ROIs:

• 105 + 125 + 107
• 120 + 125 + 126

[thorstenwagner]

Dear Mark, I thought much about that, but I think it is not that easy because there are more possible combinations: 105 + 120 105 + 125+ 107 105 + 125 + 126 120 + 125 + 107 107 + 126

And there are many more possobile combinations for the whole "agglomerate" (combinatorial explosion): 122,125,123,119,126,106,125,107,120

It is also complicated by the fact, that some line segments could belong to multiple lines (e.g. the segment 125 or 123)

We are currently working on a software where you can train a SVM and let the SVM decide which combination in meaningfull and which not... but it is far away from ready to use. Maybe someone is willing to help me? Then I can upload it onto github.

[hinerm]

@thorstenwagner

I thought much about that, but I think it is not that easy because there are more possible combinations:

You're right. I actually left out some key information in my original issue in that, in particular, I wanted to propose a heuristic using fragment slope.

The intended use is not to provide comprehensive intersection resolution. Merely to give scientists an option when:

• ridge intersections are rare and/or limited to two rides at a time
• when there is an intersection, it is unlikely that both ridges are also bending significantly

With these assumptions, I think a "continuation of slope" heuristic will typically give a good estimate.

It is also complicated by the fact, that some line segments could belong to multiple lines

Indeed. For the simple heuristic I am proposing, segments that could belong to multiple lines would be added to both lines, because of the above assumptions.

furthermore, choosing this slope-based heuristic is our way of saying combinations like: 107 + 126 120 + 125 + 107

are not of interest to us. I accept that this segmentation will not always be correct and is not universally applicable, but I think it is a reasonable first pass in some cases.

We are currently working on a software where you can train a SVM to and let the SVM decide which combination in meaningfull and which not

This sounds really cool! I do think it could be worth providing a variety of options for resolving combinations.

I started my own branch to add a selector for overlap resolution (which I am happy to rename). Is that something that would be of interest to you?

I'm happy to contribute more of the slope-based heuristic I'm interested in.. but do you have any thoughts about where such logic should exist? I'm assuming somewhere in the get_lines logic?

Maybe some is willing to help me? Then I can upload it onto github.

Put it on a topic branch! :+1:

[imagejan]

I'd be interested in this kind of heuristic as well. There's similar work in CellProfiler's Worm Toolbox that might be of interest here.

[thorstenwagner]

@hinerm

With these assumptions, I think a "continuation of slope" heuristic will typically give a good estimate. This sounds good and I'm devently interested in. I though about that too. You may also try the following: For line 107 there are two possible candidates: 126 & 125 Calculate the curvature for the split point of 107-125 and for 107-126. Select the combination of minimal curvature, do the combination if the curvature is below a certain threshold.

This sounds really cool! I do think it could be worth providing a variety of options for resolving >combinations. I started my own branch to add a selector for overlap resolution (which I am happy to rename). Is that something that would be of interest to you?

Yes, I'am! What is the best way cooperate?

I'm happy to contribute more of the slope-based heuristic I'm interested in.. but do you have any >thoughts about where such logic should exist? I'm assuming somewhere in the get_lines logic?

As mentioned, I had to fix or workaround some bugs of the original implementation. In some cases the original implementation assigned correctly detected junctions points to the wrong lines. Unfortunately I couldn't find the bug. So I made a reconstruction of the correct solution because the detected positions of the junctions points were correct. This correction have to be done before your logic starts. I would add the new logic in the get_lines logic after

 Collections.sort(resultJunction);
 junctions = resultJunction;

Put it on a topic branch!

I will do that as soons as possible (give me a few week, I'm currently very busy)

[hinerm]

I will do that as soons as possible (give me a few week, I'm currently very busy)

No rush! In the past I have enjoyed working on SVM implementations, but I do not know that I will have time to work on it with you. I was just saying that it's never too early to put a branch on GitHub :smile:

Yes, I'am! What is the best way cooperate?

You're doing it! You're very responsive on these issues and the forum. I will open a pull request when I have a basic implementation ready for review and we can discuss further from there.

I would add the new logic in the get_lines logic after

Collections.sort(resultJunction); junctions = resultJunction;

:+1:

[hinerm]

I will open a pull request when I have a basic implementation ready for review and we can discuss further from there.

FYI I am 99% done. just wasn't quite able to finish. Most of my algorithm works but it is not optimized yet and there was one case of intersection that I just need to wrap up. Will certainly be done by early next week.

[thorstenwagner]

Sounds good!

[hinerm]

@thorstenwagner @imagejan feedback on #11 would be much appreciated! I'm eager to get this merged and released. Let me know if there's anything else I can do. :smiley: