Label property edits are not deserialized

[PaulHax]

Reproduce:

1. Draw rectangle
2. Edit label color of the rectangle
3. Save state file
4. Refresh and load state file
5. Bug: Rectangle color is not your edited color, its the default.

Approach?

Bug was introduced with this code block:

VolView/src/store/tools/useAnnotationTool.ts

Lines 194 to 197 in 1a82091

	// prioritize existing labels (from configJSON most likely)
	.map(([id, label]) => {
	return labels.findLabel(label.labelName) ?? ([id, label] as const);
	})

That code will wrongly ignore property changes of deserialized labels that have the same name of default labels. To support config.JSON files over-riding session.zip files, could do a sort here:

VolView/src/io/import/importDataSources.ts

Lines 86 to 88 in 1a82091

	const results = await Promise.all(
	dataSources.map((r) => pipeline.execute(r, importContext))
	);

Add a postResource ImportHandler that collects up config.JSONs and runs them after session.zip has been processed?

The other (more hacky) fix would be to add some state asssoated with config.JSON labels so they take priority when a tool deserialzied its labels.

[floryst]

I have another observation related to this issue: saving and restoring a session that has two labels with the same name will result in the second label not existing after restore.

What should be the desired behavior when dealing with a three-way merge between config labels, session-saved labels, and defaults? Should we not merge and just pick one set?

[floryst]

Another note: maybe we should prevent users from making labels that have the same name, since I think we do expect the label names to be unique.

[PaulHax]

Good points. Idealy, restoring a session should look just like what was there before. I will fix.

Don't have a strong opinion on uniqueness of label names. Would it be useful to have 2 colors with same label name? Probably a confusing bad practice.

[floryst]

I think enforcing unique labels is good from an implementation perspective, but I don't know from a user perspective. For example, labelmap segments can have duplicate names because they're keyed off the segment value, not the name. @aylward should we allow annotations/measurements have duplicate label names?

[aylward]

A common use case of VolView + AI is loading multiple segmentations with the same name. Consider the situation in which 10 experts have segmented the same liver in a CT scan. We're going to want to be able to load all 10 liver segmentations and compare them, iterate thru them, selectively show/hide, change opacity. Each will have been created independently of the other. All will be called "liver", all will be painted with the same color, and all will have the same parent CT scan. So, how are we going to distinguish them? Seems like we have two choices 1) create a random identifier each time the data is loaded and that identifier is displayed next to the data (SEG Object) and next to the label (e.g., "Liver" becomes "Liver (AF879)" and AF879 is also shown next to the SEG file in the data browser). (I assume that filenames are too long to append to a name, so I'm suggesting a unique ID instead). -or- 2) each time we load data and there is a name conflict, we ask the user how the just-loaded labels should be renamed. My preference is 2 - asking the user to provide a new name. If the user is creating a multi-expert visualization, they will want an easy way to map each label to an expert without having to switch between the data and annotation tabs. So, have them pick the naming that is intuitive to them for display on the annotation tab.

…

On Tue, Oct 24, 2023 at 9:52 AM Forrest Li ***@***.***> wrote: I think enforcing unique labels is good from an implementation perspective, but I don't know from a user perspective. For example, labelmap segments can have duplicate names because they're keyed off the segment value, not the name. @aylward <https://github.com/aylward> should we allow annotations/measurements have duplicate label names? — Reply to this email directly, view it on GitHub <#454 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACEJL5V6G2WUY7KIZJ3VNDYA7BZZAVCNFSM6AAAAAA56ECMLGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZXGI2TEOJQGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Stephen R. Aylward, Ph.D. Chair, MONAI Advisory Board Senior Director, Strategic Initiatives, Kitware