Found non-noded intersection between [numbers galore] M9

[Svidro]

Bug report

Describe the bug
Attempting to interact with an image in "this state" causes a popup with the title error followed by a string of numbers, and also shows up in the log. Occasionally it can be circumvented by selecting an annotation of some object, but it inevitably recurs.
LINE log.txt

To Reproduce
I am not certain how to reproduce the error, but it seemed to start when I had generated a very large number of cells, and then created additional annotations within the parent annotation. I have not had it happen during standard use.

Expected behavior
No matter what terrible things I do, QuPath should stand tall and defiant.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Win10
• QuPath Version 0.2.0m9

Additional context
Clicking out of the program seemed to help, but nothing was consistent about bringing back the ability to pan around by clicking and dragging. On the other hand, zooming out, moving the cursor, and then zooming back in worked fine.

Deleting the additional small annotations within the larger annotation resolved the issue completely.

[petebankhead]

If you search for this error you should find many discussions about it and Java Topology Suite. It is a frequent source of problems since QuPath started using JTS routinely for ROIs, although I still think that on balance there are many more advantages of using JTS overall.

I had tried to put in additional steps to reduce the frequency of occurrence in m9, but it seems from this issue that is can still happen. I can see from the screenshot roughly where this occurs, but without steps to reproduce it I am not sure I can do much in the near future.

Two questions: are you using pixel snapping to round ROI coordinates to integers here? And how did you generate all the annotations (ie by hand or automatically)? These are likely to be more relevant than the many cells.

[Svidro]

Pixel snapping is turned on, but I'm not sure if it applies to script generated annotations. And these are script generated annotations, and generated using a downsampled imageprocessor, I should have included that.

Would it work to try and round all of the annotation points prior to using addObjects(), and if so do you have any recommendations on how to do that (the annotations could, theoretically, have holes)? Or is it possible to snap objects to the grid with a function similar to resolveHierarchy?

As a note, I would probably do this at the ROI stage, where I use IJTools.convertToROI(). Looking into options to edit the point values within those ROI objects now.

[petebankhead]

You're right pixel-snapping will only impact the ROIs drawn manually. Apart from that I don't think there's an easy solution, because the underlying problem concerns self-intersections in the shapes that may be very subtle/due to excessive precision. Rounding the vertices alone isn't certain to help, and may make the situation worse (e.g. by introducing new self-intersections) - any rounding will likely need to be done very cautiously.

The solution/workaround will likely involve trying to add even more logic into QuPath to try to capture and fix these problems internally as early as possible, but that will likely require gathering more information here about when they can occur - ideally with reproducible examples.

[Svidro]

Closing this with the note that I was able to use Simplify Annotations to prevent the error from occurring. As mentioned it only happened with script generated annotations, and even then only when creating them off of a downsampled ImageProcessor, followed by upscaling them back into annotations in QuPath.