A t1despot module should be made from the mipav built-in plugin. It needs to be able to handle multiple volume inputs, for instance from a VolumeCollection or FileCollection. I can script it and convert to a module, but the scripted version will only handle 1 calculation from two 3D volumes. I would like to be able to have it iteratively calculate based on a collection of high flip angle 3D volumes and a single low flip angle 3D volume.

I think it's a situation where using the action discovery tool probably isn't going to work in this use case. The way that mipav algorithms internally handle multiple inputs specified by the user seems to be incompatible with the JIST interface. For instance, if I want to specify the inversion time (TI) for the second T1IR volume there is no place to define it since it is only expecting 1 T1IR volume as the default. The parameter labels in the JIST module have names like "SPGR_TRunsupportedList", so I think there is an internal list structure to the algorithm that can handle multiple inputs specified on the fly, but it isn't transferring over to the JIST module through the action discovery tool. I think it would be best to write a dedicated module from scratch that uses the JIST conventions for setting multiple input volumes and multiple parameters. If you need me to specify these properties in detail I can do so.

JIST uses exactly the information that action discovery provides. Action =
discovery does not currently well-capture plugins that take variable =
numbers of inputs - we allow you to specific any options at runtime. Are =
the "mandatory" fields not set correctly within the flip angle =
calculation?=20

I've updated to MIPAV v1.5 (the newest release) and there is now a discoverable plugin called "FlipCalcT1(5.0.0 R)" under MIPAV->Algorithms->MRI. Unfortunately we're running into the same problem. The MIPAV plugin works fine when using it manually to create T1, B1, etc maps because I can specify how many SPGR volumes and how many IR volumes to use. The GUI will update itself to accept more parameters when multiple volumes are selected. However, the JIST version of this plugin doesn't know a priori how many volumes will be specified. Therefore the input pins that should show up for the input volumes don't exist. Furthermore, I can't specify the IR times for the two IR volumes as well as some other pertinent parameters. I think it is a matter of the ActionDiscovery interface not being compatible with the way JIST defines input volumes. I think in order to properly set up the JIST module version of this plugin, we need volume collection input pin for SPGR volumes and another volume collection pin for IR volumes. That way it can handle 0,1,2+ volumes for each type. Similarly we need input pins that can take 0,1,2+ parameters like flip angle and inversion time.

I got a response from Dr. McAuliffe; apparently Justin
Senseney implemented the despot plugin at Danny's request and
they plan to implement the despot-JIST API "in the near
future".

Do you know who developed the original MIPAV plugin? If so, can you ask =
that person to implement the "ActionDiscovery" interface. If this is =
implemented, the native MIPAV plugin will automatically be detected in =
JIST. It's a very light weight interface to add to a module that already =
supports scriptable.

(enter your response here)