Simplify and harden the annotation file format.

[allemangD]

I'm opening this issue to allow discussion of some ideas I mentioned in our planning for the next phase of work; I think making such changes and hardening the file format may enable easier adoption and integration with external tools.

Up to this point we've focused on making the file format easy to consume from cell locator; for example markups are stored as MRML nodes with metadata. We've made progress in removing some of the extraneous pieces (display node, etc) however there still is a lot of extra weight in the format.

For example the "controlPoints" objects contain "orientation", "selected", "locked", "visibility", "positionStatus"; none of these are used by Cell Locator. "label", "description", "associatedNodeID" are technically used, but not editable or significant.

At the extreme, the "controlPoints" only needs to be a list of position vectors.

Would it make sense to put effort into paring down the file format to only contain the minimally relevant information in an easy-to-consume format for external tools rather than Cell Locator? This would add some complexity to the (de)serialization logic in Cell Locator, but it might help to make our format easier to consume by other projects.

[allemangD]

From @lydiang during our meeting today:

The file should be Cell Locator centric. But we provide library etc. to get them into libraries like ITK/VTK and allow the annotation then be serialize into well documented models like VTK

The goal should not be to make the file format part of some public contract; we would be creating a library of tools which would allow third-party projects to consume the cell locator data.

---

The changes I mentioned, and clearly documenting those changes, will still be important in internally developing that library; so I still believe this is important.

I also wonder if it may be possible to allow Cell Locator itself to use the library; much of the functionality we would need in such a library is already present in the Annotation and AnnotationManager classes and subclasses. Exposing these, or a similar set of classes, in a library imported by Cell Locator may be ideal.

[lydiang]

I like the sound of thi idea in that if it is central to Cell Locator itself then it won't go stale.

…

________________________________ From: David Allemang ***@***.***> Sent: Thursday, August 5, 2021 12:05 PM To: BICCN/cell-locator ***@***.***> Cc: Lydia Ng ***@***.***>; Mention ***@***.***> Subject: Re: [BICCN/cell-locator] Simplify and harden the annotation file format. (#195) From @lydiang<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flydiang&data=04%7C01%7C%7C06a0f00324444addf30a08d958440d02%7C32669cd6737f4b398bddd6951120d3fc%7C0%7C0%7C637637871561870394%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FjcQR7SymF1tmveDvUcNuWf4sWEx9gEIpVdcb2RCFlw%3D&reserved=0> during our meeting today; regarding this section: Would it make sense to put effort into paring down the file format to only contain the minimally relevant information in an easy-to-consume format for external tools rather than Cell Locator? This would add some complexity to the (de)serialization logic in Cell Locator, but it might help to make our format easier to consume by other projects. The goal should not be to make the file format part of some public contract; we would be creating a library of tools which would allow third-party projects to consume the cell locator data. The changes I mentioned, and clearly documenting those changes, will still be important in internally developing that library; so I still believe this is important. I also wonder if it may be possible to allow Cell Locator itself to use the library; much of the functionality we would need in such a library is already present in the Annotation and AnnotationManager classes and subclasses. Exposing these, or a similar set of classes, in a library imported by Cell Locator may be ideal. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FBICCN%2Fcell-locator%2Fissues%2F195%23issuecomment-893712952&data=04%7C01%7C%7C06a0f00324444addf30a08d958440d02%7C32669cd6737f4b398bddd6951120d3fc%7C0%7C0%7C637637871561880349%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vq0VHaEtnPVBHNYf2euHVRFaun6vNBsq6RQJrjb9slw%3D&reserved=0>, or unsubscribe<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FACBIBYIG7ODYOMIK4CRL7G3T3LOJFANCNFSM5BUI5CUA&data=04%7C01%7C%7C06a0f00324444addf30a08d958440d02%7C32669cd6737f4b398bddd6951120d3fc%7C0%7C0%7C637637871561880349%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SnuwpAvHgq0kUvb2SF7hID88phGjHRGZsyfjlCct1kI%3D&reserved=0>. Triage notifications on the go with GitHub Mobile for iOS<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04%7C01%7C%7C06a0f00324444addf30a08d958440d02%7C32669cd6737f4b398bddd6951120d3fc%7C0%7C0%7C637637871561890300%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rT9ZR4Ds%2FIxdusQX%2BDxSzZCJYheRZrfDVfvzmk7vDF8%3D&reserved=0> or Android<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26utm_campaign%3Dnotification-email&data=04%7C01%7C%7C06a0f00324444addf30a08d958440d02%7C32669cd6737f4b398bddd6951120d3fc%7C0%7C0%7C637637871561890300%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JBOaQLlX1kmxsJQmq4AW8%2FFynigVhNthS3LAK5Eb71k%3D&reserved=0>.