fix(Annotation Tools): Fix active volume to show correct cachedStats (especially on fusion viewport)

[Celian-abd]

Context

(Remake of #2408)
Currently, even if we set the PT volumeId into the configuration of Rectangle/Circle/EllipticalRoiTools, it will always show the cachedStats of the CT on the fusion viewport.

As we can see here :

Changes & Results

• Added a way to check if a volumeId is provided in the tool configuration
• Select the correct cachedStats to show following the volumeId

If we set PT volumeId in the tool configuration :

Testing

Example PET-CT
You can modify or delete the prefered volumeId in the tool configuration :
fusionToolGroup.addTool(RectangleROITool.toolName, { volumeId: ptVolumeId });

Checklist

PR

• [] My Pull Request title is descriptive, accurate and follows the
  semantic-release format and guidelines.

Code

• [] My code has been well-documented (function documentation, inline comments,
  etc.)

Public Documentation Updates

• [] The documentation page has been updated as necessary for any public API
  additions or removals.

Tested Environment

• [] "OS:
• [] "Node version:
• [] "Browser:

[sedghi]

LGTM, let's see what Bill says

[wayfarer3130]

I'm not at all keen on having more volume id specific tools - that means you have to know exactly what volumes to use when you create creating the tool group, and when you make any changes to the volumes available, they have to apply to the tool group.
I'd much rather see some sort of filter allowing a TYPE of volume to be applied based on some sort of criteria. For example, in this case just having a filter of modality = PT would work.
If it is necessary to identify the specific volumes, it should be disconnected from the tool group, and instead isolate that knowledge in a separate class. For example, it would be possible to provide a Set class with volume ids in it, and that class could provide notifications when the volume ids in it change so that as a new volume got loaded, it could be added to the right volume set class.

[sedghi]

I like the idea, but asking people to do this would be a breaking change since i think we already say use volumeId. I suggest we implement it in the next version.

[salimkanoun]

Hi there I agree with both of you, the current implementation is too complex.
However using modality is probably not enough neither as I saw fused MRI on which you fuse ADC and T1/T2 series so both will be MR modality.

I would suggest to use image index in the viewport, as you can control it in the hanging protocol I think it might be possible to specify which image index is used by the tool group.

[wayfarer3130]

@Celian-abd - my preference is to provide a function that determines the preferred target id rather than hard coding the value. That way it is possible to have more flexible determination and to work with multiple merged viewports at a single time by creating a custom function that works against both viewports.

[wayfarer3130]

@sedghi - this code is wrong as the target id doesn't have to include the desired target id as a substring in general. The right solution is to get the volume id associated with the given image id, and check for equality. HOwever, without passing in the set of image ids associated with the volume, I don't see an easy way of doing that. Should I just pass in a Set of the image ids that are preferred and use imageIds.has(imageId)?

[wayfarer3130]

@sedghi - I've updated the PR with changes that I think should work with the API generally. It isn't perfect, but I think is acceptable as the API should be fairly future compatible.
@Celian-abd - can you look at the change I made and add your agreement that they resolve your issue?

[Celian-abd]

@wayfarer3130 Looks good to me, thanks a lot !

[sedghi]

@wayfarer3130 can you fix the volumeId and imageid thing i sent in slack and we merge this

[wayfarer3130]

@wayfarer3130 can you fix the volumeId and imageid thing i sent in slack and we merge this

@sedghi - it really wasn't clear what you wanted changed from the comment in slack