support regions/annotations

[kswang1029]

For the publication purpose, we need to support region/annotation file loading so users can use it to decorate their images for presentation (such as an arrow plus a text to point to a target source or a set of point markers to mark target sources, etc)

once CARTAvis/carta-frontend#2019 and CARTAvis/carta-backend#1229 are merged annotation region will be supported.

[Jordatious]

Doing this for regions is essential. For annotations, this would be nice, but for a small number of sources, it's not difficult to overlay one's own annotations in any basic image software.

[kswang1029]

we would need the abilities to

• load region files
• create regions/annotations from scratch
• modify existing regions/annotations (either loaded from a file or created manually)
• set styling of regions/annotations
• lock/hide/center regions
• delete regions/annotations

[I-Chenn]

@kswang1029, @confluence :
I designed a few APIs (mostly for loading regions and adding regions) for this issue. I haven't completed it yet, but I am hoping to at least complete all the functions about adding regions. Please take a look:
https://hackmd.io/@UL9ceyk6SsmUkbgVUFXQPg/Bk3Kn8xB2
If there's items which are OK for you, perhaps I can add some issue to GitHub for those functions.

[kswang1029]

@kswang1029, @confluence :
I designed a few APIs (mostly for loading regions and adding regions) for this issue. I haven't completed it yet, but I am hoping to at least complete all the functions about adding regions. Please take a look:
https://hackmd.io/@UL9ceyk6SsmUkbgVUFXQPg/Bk3Kn8xB2
If there's items which are OK for you, perhaps I can add some issue to GitHub for those functions.

The most critical part is missing: how region fits in the current architecture? Does it belong to session or image or else? If it belongs to session, how it interacts with image? If it belongs to image, how it interacts with session? How do we handle matched images? And how do we handle region analytics which requires a user-input image and a user-input region?

[confluence]

There should be a new Region class, so that we can have region objects as handles to regions in the same way that image objects are handles to images.

Functions for manipulating (or deleting) existing ("open") regions would be methods on this class. Whether the functions for creating / importing them should be on the session or the image class depends on the relationship between images and regions. Does each region "belong" to a specific image? If yes, then these methods should be on the image class (but call different class methods on the region class; similar to the relationship between session and image). But we might want helper methods on the session class for finding / interacting with all the regions in the session.

Most of the actual region logic should be inside the region class. The methods on the image and/or session should just connect this functionality to particular images or sessions.

I think that it would be helpful to start by sketching a diagram showing how images and regions are related to each other (images to regions, regions to regions, etc.).

[I-Chenn]

The most critical part is missing: how region fits in the current architecture? Does it belong to session or image or else? If it belongs to session, how it interacts with image? If it belongs to image, how it interacts with session? How do we handle matched images? And how do we handle region analytics which requires a user-input image and a user-input region?

OK, I haven't thought that deeply but just want to add some basic functions first. I will think more about it and discuss with you few days later.