They may be CLI modules. A CLI module is a simple executable that does not provide an icon, therefore only a generic icon is used. Since these modules are usually low-level data processing modules, lack of a recognizable icon is generally not a problem.
What are those diffusion-related modules that you are adding to the toolbar?
@jcfr@pieper what do you think about adding a new field to the CLI module description that would specify relative path of an extension icon in he (such as <icon>ACPCTransform.png</icon>) in the executable element?
<?xml version="1.0" encoding="UTF-8"?>
<description><![CDATA[<p>Calculate a transformation that aligns brain images to <a href="https://en.wikipedia.org/wiki/Talairach_coordinates">Talairach coordinate system</a> (also known as stereotaxic or ACPC coordinate system) based on anatomical landmarks.</p><p>The ACPC line extends between two points, one at the anterior commissure and one at the posterior commissure. The resulting transform will bring the line connecting the two points horizontal to the AP axis.</p><p>The midline is a series of points (at least 3) defining the division between the hemispheres of the brain (the mid sagittal plane). The resulting transform will result in the output volume having the mid sagittal plane lined up with the AS plane.</p><p>Use <b>Resample Scalar/Vector/DWI Volume</b> to apply the transformation to a volume.</p>]]></description>
<contributor>Nicole Aucoin (SPL, BWH), Ron Kikinis (SPL, BWH)</contributor>
<acknowledgements><![CDATA[This work is part of the National Alliance for Medical Image Computing (NAMIC), funded by the National Institutes of Health through the NIH Roadmap for Medical Research, Grant U54 EB005149.]]></acknowledgements>
I had a closer look and CLI modules actually can already store icons, but they provide it on their standard output when the CLI module is launched with the --logo argument. It would be very inefficient to simply start using this feature, as it would mean running 50 executables at each Slicer startup to just get the CLI module icons. We would need to do something like that is done for the module description .xml files cache the icon files in the module folder so that the application can load them directly. Even then, loading 50 icon files may have add some perceivable delay at application startup. Maybe adding the icon to the .xml file would be faster (as we already load the .xml files at startup)? Another complication is that it is not trivial to bundle the icon file into the executable file (embedding binary resources into an executable is different on each compiler).
Exploring all the options and implement something that does not slow down application startup and remains compatible with the existing CLI module infrastructure would be quite significant work. Since the benefits are quite small, I don’t think this will be worked on soon. Anyway, this issue tracks this task:
Not sure if I follow the rationale of the icon resources needing to be loaded being prohibitive in terms of time; there are other modules (CLIs or not; I am still not that familiar with these in the context of Slicer) that have a non-negligible number of icons in their panels. But my knowledge about the underlying mechanisms is very limited, so my reasoning may not be accurate enough.
To me, being able to identify a tool is essential in an application, and as a user, I expect any application to offer this capability for the sake of usability.
I grant that if an application is too slow to start, this can bother some users in some contexts or deter them from using an application; but being slow at start is a one-time event, whereas being unable to identify an icon or needing to constantly navigate through a hierarchy of menus is a recurrent event within one session.
Maybe the feature is not straightforward to implement given the current constraints, but I do believe that it can make a difference in usability.
Loadable modules use the Qt resource system to efficiently load icons. It is a very much optimized system for both minimizing storage requirements and loading time. Since CLI modules are just standalone console applications that don’t depend on Qt, they cannot use the Qt resource system.
The cross-platform resource embedding mechanism that is currently implemented for CLI modules is quite slow and complicated to use, so we would need to revamp that before we can use it to load all CLI module icons at each startup.
Lack of icons for CLI modules is usually not a problem because CLI modules implement computational algorithms that users typically do not interact with directly, but via more convenient higher-level interactive “loadable” modules (which all have icons and nicer GUI).