BUG: Filter "Minimum Number of Neighbors" should be yellow and have warnings akin to "Remove Minimum Size Features"

[StopkaKris]

Is there an existing issue for this?

• I have searched the existing issues, known issues in release notes, and documentation.

Brief Description of the Issue and Expected Behavior

The filter “Remove Minimum Size Features” appears yellow in the pipeline because it modifies cell data. However, the “Minimum Number of Neighbors” does not, yet it should be formatted in a consistent manner as “Remove Minimum Size Features” since both edit cell/feature data, and therefore the same warning should be provided to users. This is the case in DREAM.3D 6.5.171, for example.

Also, are the current warning messages sufficient for both of these filters? These filters modify not just things like NeighborList and SharedSurfaceAreaList, but also the feature size, shape, centroid, etc. These filters and their associated documentation/warnings should warn users that feature metrics like size and shape, in addition to neighbor information, must be recomputed. For example, the way the “(08) Small IN100 Full Reconstruction” pipeline is currently set up will report incorrect feature sizes if users are not aware of this (filter 14 computes feature sizes, which are modified by filters 15 and 17).

There are other filters that also affect feature metrics, such as "Erode/Dilate Bad Data" and "Fill Bad Data". Should these filters (and possibly others) have similar warnings?

Finally, since the first filter is entitled “Remove Minimum Size Features”, should the other be called something similar, for example “Remove Minimum Number of Neighbors Features” or "Enforce minimum number of feature neighbors"?

Version

DREAM3D NX (version 7)

What operating system are you seeing the problem on? [Further details may be required during triage process]

Windows 10

What hardware architecture are you using? [Further details may be required during triage process]

x86_64

What section did you encounter the error in? [Further details may be required during triage process]

No response

Steps To Reproduce

No response

Relevant log output

No response

Anything else?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[imikejackson]

These are all good points. We will have an engineer look into this.

[imikejackson]

@StopkaKris

Require Minimum Feature Size
Require Minimum Feature Neighbors

[imikejackson]

@StopkaKris There is some catch-22 going as you need to compute the sizes in order to use the "minimum size" filter. But then we do need to inform the user in strong terms that essentially ALL of the feature data is basically invalid as soon as these filters are executed. The trick is if we remove the entire Feature Attribute Matrix, then the user would have to start over with their segmentation. I will have to think on this for a bit to try and figure something out.

At the minimum, we should be putting something in the comments of the filters in those example pipelines, or maybe even inserting the "Remove Data" filter after we are done with those filters.

[StopkaKris]

@StopkaKris

Require Minimum Feature Size
Require Minimum Feature Neighbors

I like these filter names!

I understand the following would be very difficult to implement, but an idea for a very cool filter would be "Recompute all feature attributes", in which a single filter could read existing feature attributes, such as size, shape, number of elements, etc., and then recompute based on knowing which filters would perform these calculations.

I like the idea of inserting the "Remove Data" filter in those prebuilt pipelines and including comments in the prebuilt pipeline filters.

[imikejackson]

@StopkaKris The issue is that there really is no way to track what filter creates which data. We can certainly make assumptions but I'd rather not.

[imikejackson]

@StopkaKris I have added the following to the documentation for the 4 filters mentioned:

## WARNING: Feature Data Will Become Invalid

By modifying the cell level data, any feature data that was previously computed will most likely be invalid at this point. Filters that compute feature level data should be rerun to ensure accurate final results from your pipeline.

This will help a bit but it is up to the user to start reading these docs. What I don't want to happen is that we inundate the user with warnings and they just start to ignore them. But I'm not really sure what the best route is at this point.

[StopkaKris]

@imikejackson That is a fair point.

[imikejackson]

@StopkaKris This is what I am thinking for warnings. 2 places. In the official Issues table of the UI and also up in the filter parameters (but that could get hidden if there are enough parameters)

[imikejackson]

@StopkaKris Unless we pull the nuclear option and give the user an option to nuke all the feature level data after the filter is done running. That saves the step having to run the "Delete Data" filter which isn't hinted at in the above.

@jmarquisbq Thoughts?

[StopkaKris]

@imikejackson I like the "nuclear" option the best. A checkbox at the top of the filter parameters that is checked by default specifying "Delete previous feature data" would be a nice option. That would certainly save me time when running these filters. And placing the checkbox will get the user's attention as opposed to a warning that, as you mentioned, could be hidden if there are enough parameters.

[imikejackson]

#980