You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After discussion with Thomas, we agree this is a wished feature. Nevertheless taking into account the mask should be wired down at the array level and not connecting at the mask widget as it is proposed in #3281. This will simplify also the calculation of the range of the colormap with masked data (especially important with Eiger2 detectors are the dummy value is above 4 billions, 2^32-1)
This approach will require much more work at lower levels but will allow the generalization to all kind of processing very easily.
Here is a TODO list:
Provide the associated mask in the image object like: image.getData() one could have image.getMask()
Profile calculation are performed in Cython. It is the right time to refactor the code to take mask into account
Wire the mask in the ProfileToolBar.
The mask should be an array of same size as the image with dtype uint8 (or None if absent)
The alternative, numpy.maskedarray, has been discarded because we which to be able to manage multiple masks, either 7 overlapping masks or 254 non overlapping masks.
Sponsor: ID17
The text was updated successfully, but these errors were encountered:
I had a look at it, and it seems fine to integrate the mask at the low level.
It is also more versatile (support of mask loaded from a Nexus file should be simpler).
The only adaptation in PlotWidget beyond to image item seems to be that a plot items should be able to add more than one renderer item in the backend (which totally makes sense and should not be a big deal).
The most complex part can be expected in the mask authoring tools which will need to be updated.... and of course all tools willing to take the mask into account. Having the mask stored with the image item mask will make the wiring/update notification much simpler.
After discussion with Thomas, we agree this is a wished feature. Nevertheless taking into account the mask should be wired down at the array level and not connecting at the mask widget as it is proposed in #3281. This will simplify also the calculation of the range of the colormap with masked data (especially important with Eiger2 detectors are the dummy value is above 4 billions, 2^32-1)
This approach will require much more work at lower levels but will allow the generalization to all kind of processing very easily.
Here is a TODO list:
The mask should be an array of same size as the image with dtype uint8 (or None if absent)
The alternative, numpy.maskedarray, has been discarded because we which to be able to manage multiple masks, either 7 overlapping masks or 254 non overlapping masks.
Sponsor: ID17
The text was updated successfully, but these errors were encountered: