how to add tissue detection on each TMA core manually

[Naoko]

Hi Pete and microscopyra,

Thanks for always being a great help for this community.

I'd like to adjust a tissue detection for a specific TMA core (one by one, not by row/column).

I received a TMA slide, where some cores are not arrayed in a straight line and some are not quite round. After using TMA dearrayer and Simple tissue detection, I found some cores couldn't be separated completely (see attached image). 

Is it possible to manually choose a specific region in this core, to prevent from overlapping, while still keeping the TMA map? I'd like to exclude the right-sided part of the core (green arrow).

Best regards

Naoko

[Pete]

Because you are using the tissue detection, you should be able to double-click on the tissue region to select it, and then right-click on the annotation and choose Annotations -> Unlock

Then you can use the Brush tool with the Alt key pressed to subtract regions from that annotation.

It's quite manual, but does that do what you need?

[micros...@gmail.com]

A side note when you do this, you may need to trim a little bit of the upper right corner of the annotation you want to keep (where it touches the edge of the TMA circle).  I recall those types of borders causing the annotation to no longer register as "within" the TMA core once you unlocked and edited the annotation (you will see your remaining annotation "outside" of the list of TMA cores).  

[micros...@gmail.com]

And I don't have a great TMA to test it with, but if you do not check the "Single Annotation" while performing the simple tissue detection, it might make it easier to select and delete the portions you do not want.  I am unsure how the separation of parts of your other cores may impact your downstream data analysis, however...

[Naoko]

Hi Pete and microscopyra, thanks for the quick reply.

"Re-annotation" was successful with Pete's instruction.

After the re-annotation, I set Annotations -> Lock, then I ran Cell analysis -> Fast cell counts for all annotations, but only the result of this core was not shown on the sheet of TMA viewer.

Is there anything else I should set?

Regards

Naoko

[Pete]

Locking shouldn't be essential (although it's a good idea, to avoid accidentally moving the region later).

My guess is that the problem is that a little bit of the tissue is outside the core boundary - as microscopyra predicts in his first post.  You might need to trim it off too; the red tissue annotation must be completely inside the blue circle - and QuPath is extremely strict about this.  Even a fraction of a pixel outside is too much...

You can check out the tree view under the Hierarchy tab as you make this change.  Whenever the red annotation is inside, it should be shown below the TMA core circle in that tree view... otherwise it will sit on its own within the first level of the tree.

[Pete]

This is the relevant bit of the documentation: https://github.com/qupath/qupath/wiki/Object-hierarchies

[Naoko]

I see. It seems fine if part of the tissue is outside the core boundary at the first tissue detection step, but once I unlocked the annotation and change it, the object was no longer below the TMA core.

Because of this object hierarchies, is this the reason why the TMA core size and place (blue circle) cannot be changed after the tissue annotation is completed? I should have more carefully set the TMA core size and place at the first step.

Also, I found the microscopyra's suggestion, not using Single annotation and just deleting the small objects, was easier to me at this moment.

Thanks!

[Pete]

Yes, when the command is run the first time, the TMA core defines the region in which the tissue detection is applied - and QuPath 'knows' that any created annotations should be placed below the TMA core in the hierarchy.

But if you then start editing it, then QuPath default (and stricter) 'hierarchy-resolving' decisions come into play... and that can result in this behavior.

QuPath tries to get a balance between flexibility and predictability.  I'm not sure that balance is quite right yet... The way the hierarchy is resolved whenever annotations overlap one another is a part that I don't like in its current form, because this kind of thing can happen.  One day I'd like to revisit it, but changing it would take some work - and when you know what it is doing and why, I find it's usually possible to live with the current behavior.