thorstenwagner / ij-ridgedetection Goto Github PK

I would really like to call this plugin from a macro, recording all parameters so that a dialog does not need to be shown.

@thorstenwagner I spent a few minutes on it this morning but gave up. It is not clear to me what would need to be done to make this nicely macro recordable in the ImageJ 1.x framework.

If you can give me some direction I am willing to do the work. But I looked at other plugins that I know are fully recordable and still couldn't figure it out. :(

Anyway another option would be to just convert to ImageJ 2 where we could use @Parameter notation and get rid of the generic dialog and macro language restrictions altogether. I would be happy to work on this as well but only if you are OK moving to IJ2.

Let me know! :)

To reproduce:

Configuration:
Sigma: 2.52
Lower Threshold: 2.21
Upper Threshold: 9.00

The contours table containing two lines which were merged nicely. However, the junction table contains six junction points with line ids which do not exist.
@hinerm I think this is because you do not update any junction points when doing slope resolution?

To reproduce:

Configuration:
Sigma: 2.52
Lower Threshold: 2.21
Upper Threshold: 9.00

The contours table containing two lines which were merged nicely. However, the junction table contains six junction points with line ids which do not exist.

Remove lines smaller as some defined threshold

The detected line should be added to the ROI manager

Image to reproduce:

Settings to produce:
Line width: 6
High contrast: 255
Low contrast: 250

With activated "Correct position" and "Estimate width" the junctions points in the middle are vanishing. Estimating the with without activated "Correct position" works fine.

The following image & settings produce an ArrayIndexOutOfBoundsException:

ERROR: java.lang.ArrayIndexOutOfBoundsException: 100
in Ridge Detection Preview
at de.biomedical_imaging.ij.steger.Link.compute_contours(Link.java:1125)
from de.biomedical_imaging.ij.steger.Position.detect_lines(Position.java:255)

It wasn't immediately clear to me how this plugin should be licensed. It's actually really easy to add license info via the license-maven-plugin - especially since you already are extending pom-imagej

@thorstenwagner if you let me know what the license should be (GPL? BSD?), I can submit a PR that adds the maven configuration.

Generate a binary scene using line width

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

Hello,
thanks for the plugin.
If I understand well, a larger contrast range should give more or longer ridges. Because larger variation of contrast is tolerated. By the way it does not seem to be so in the screenshots that I attach: one with the range 0-230 and the other with 200-230.
So what would be the correlation between the (number or length of the) fibers and the low and high contrast chosen?
All the best,
Asef

In the code we have at least 100 value in the 'junc' variable, that are init with default values.
These values are "really" filled starting from the last position, hence in some case could be that
in this assignment https://github.com/thorstenwagner/ij-ridgedetection/blob/master/src/main/java/de/biomedical_imaging/ij/steger/Link.java#L1202 it assignes the default values instead of a real value

This situation could lead to unexpected behavior. In my case at the end of the code in the 'cont' vector I get duplicate values. Is it OK?

I suggest the following overlap resolution method:

1. Given is a complex agglomerate with several junction points
2. Start with next junction point
   2.1. Search for line positions P at a specific search radius r (e.g. 3 * line width) which are part of the agglomerate. The position on the current line (which belongs to junction point) is P₁. If the current line is shorter then r use midpoint of current line as P₁.
   2.2. Calculate the shortest paths S from the position P₁ to each position in P
   2.3. Select the path S₁ with the highest straightness^§
   2.4. If the straightness is below some defined threshold, accept it, merge all lines in S₁ and update the junction points accordingly
3. Return to 2 when other potential junction points exist

^§Straightness: The straightness of a path p is calculated the following way: distance between start and end point divided by the length of the path

@hinerm This approach would be like an extension of yours. And it exploits that we roughly know the width of the lines (because it is specified by the user anyhow). Furthermore I guess it would be able to handle situations like these:
http://fiji.sc/_images/e/ec/Slope_detection_low_sigma.png
I would like to hear your opinon!

To reproduce:

Configuration:
Sigma: 2.52
Lower Threshold: 2.21
Upper Threshold: 9.00

All contour classes are now of type "closed".

Hi,

I was wondering if there is a way to script this plugin ideally in Python or using the macro language?

Cheers,

Sebi

This line does not make sense:
https://github.com/thorstenwagner/ij-ridgedetection/blob/master/src/main/java/de/biomedical_imaging/ij/steger/Link.java#L615

In some cases the contour class of line is wrong.

Example:

Settings to produce:
Line width: 6
High contrast: 255
Low contrast: 250
Correct position: deactivated
Estimate width: deactivated

The contour with the ID 113 should have the class "both_junc" but the class is "start_junc".

In the first infinitive loop (https://github.com/thorstenwagner/ij-ridgedetection/blob/master/src/main/java/de/biomedical_imaging/ij/steger/Link.java#L365) when you look for the 'Line' objs you save some values in the row,col,angle and resp Arrays and at the end of the loop you saved it in a Line obj.

You init these Arrays before the loop (https://github.com/thorstenwagner/ij-ridgedetection/blob/master/src/main/java/de/biomedical_imaging/ij/steger/Link.java#L322) and you resize them into the loop ...anyway you rewrite them in every iteration.

I suppose that different Line can have different number of values in the row/col/etc. Array.
If the Line 'm' has less row values than Line 'n' (with m>n) you will not rewrite the last value of these Arrays but you will still save them on the line 'm' arrays.

e.g.:
Line1 has 80 value in its row.
Line2 has 60 value in its row
Hence Line2 will have 80 value in its row: the 60 real value + the last 20 value of Line1.

Is it an error or we are sure that the next Line will have at least the same number of elements (of rows for example) that the precedent?

I noticed that there are multiple commits on master with the same Maven release version. This can lead your project to be unreproducible.

There are many tools and workflows for managing release cycles. I'm happy to discuss pros and cons here or on the forum, if you're interested.

In 'compute_contours' of Link.java the 'Line' objs are stored in the 'cont' list.
In the first element of this list the 'response' value seems not be filled in the correct way.
The vector has 387 values but just the first 4 are not zero. In the other elements there are no 0 values.
These values are used to fill the 'intensity' vector ... I think that its values could be invalid

All the issues that I opened are obtained with the following file

The params used are:

{
"path_to_file": "example.tif",
"mandatory_parameters": {
"Sigma": 3.39,
"Lower_Threshold": 0.34,
"Upper_Threshold": 1.02,
"Maximum_Line_Length": 0,
"Minimum_Line_Length": 0,
"Darkline": "LIGHT",
"Overlap_resolution": "NONE"
},

"optional_parameters": {
	"Line_width": 10.0,
    "High_contrast": 200,
    "Low_contrast": 80
},

"further_options": {
	"Correct_position": true,
	"Estimate_width": true,
    "doExtendLine": true,
	"Show_junction_points": true,
    "Show_IDs": false,
	"Verbose_mode": false,
	"Display_results": true,
	"Add_to_Manager": true,
    "Preview": true,
    "Make_Binary": false
}

}

In some cases, the SLOPE overlap resolution produces phantom lines.

Input:

Result:

@hinerm Any idea?

I do not understand how the function works, but I did a search and never found these parameters used in the function.

I wonder if https://github.com/thorstenwagner/ij-ridgedetection/blob/master/src/main/java/de/biomedical_imaging/ij/steger/Link.java#L250 had something to do with the two parameters?

/* Count how often line j needs to be split. */
for (k = 0;  junc[(i + k)].cont1 == j && i + k < num_junc; k++)
	;

I encountered an ArrayIndexOutOfBoundsException: 200 while executing this for loop. To avoid this error, it is advisable to perform a boundary check on the array before accessing it. Consider applying the following modification to address the issue:

/* Count how often line j needs to be split. */
for (k = 0; i + k < num_junc && junc[(i + k)].cont1 == j; k++)
        ;

However, I'm not sure if this for loop serves any purpose, so I'm inclined to think it can be safely omitted. I would appreciate any input on this matter.

@thorstenwagner could you release a new version of the package using the release-version.sh script? A git tag will be automatically created and the package will be uploaded to the ImageJ Maven repository.

If you give write access to the repo I can also do it for you.

Thank you.

@hinerm

I've played around with some other image data and found some strange results. The original image is:
http://fiji.sc/_images/f/f5/CNT_Ridge_Detection_Original.png

I've used the following settings...
Sigma = 1.5, Lower Threshold = 1.3, Higher Threshold = 7
... and get some 'strange' results:

At the moment, the detection algorithm find a "main line" and all lines which runs into that main line leads to a junction point. However, it would be better and more intuitive when the "main line" would split at the junction point.

I recognized that the extend lines functionality in the Link class does not work correctly:
https://github.com/thorstenwagner/ij-ridgedetection/blob/master/src/main/java/de/biomedical_imaging/ij/steger/Link.java#L818

Example:

Use the standard settings and deselect extend lines. Three lines were detected:
100, 101, 102

There are gaps between the lines 101 - 100 and 102 -100. If extend lines is selected, the algorithm detects correctly that 101 could be connected with 100 and 102 could be connected with 100. However, it does not add a junction point. The reason is, that the extend lines functionality only adds a junction points if it is not one of the other line's endpoints. But when it comes to the connection of 101 and 100 it is the endpoint of line 100. So the decision not add an junction point when extending the line 101 to 100 is correct. But then algorithm should merge the lines 101 and 100 but it does not! When it comes to the connection between 102 and 100 the algorithm does not know that the line 100 is already extended and do not add junction point again . This should be corrected.