The 'reference' attribute for image parameters is not described in the XSD yet

[hmeine]

Apparently, a 'reference' attribute has been added to <image> parameters in the execution model, but Libs/CommandLineModules/Core/Resources/ctkCmdLineModule.xsd has not been updated yet accordingly.

I am seeing 38 such occurrences in yesterday's nightly build.

[hmeine]

I just noticed that the 'reference' attribute is also found in the description of transform, geometry, and table parameters.

[hmeine]

Also, for transform, I wonder whether we would need two attributes (one for the fixed and one for the moving image)? According to @jcfr , the attribute is not used anywhere yet. It would make sense to collect input on how people intend to use it. (I guess @fedorov could want to use it for provenance in DICOM exports, for instance?)

[pieper]

Yes, for a dicom registration object you would want the two frames of reference that are connected by the transform, so having the fixed reference and the moving reference would make a lot of sense.

On Thu, Jan 7, 2016 at 5:14 PM, Hans Meine [email protected] wrote:

Also, for transform, I wonder whether we would need two attributes (one for the fixed and one for the moving image)? According to @jcfr https://github.com/jcfr , the attribute is not used anywhere yet. It would make sense to collect input on how people intend to use it. (I guess @fedorov https://github.com/fedorov could want to use it for provenance in DICOM exports, for instance?)

— Reply to this email directly or view it on GitHub https://github.com/commontk/CTK/issues/623#issuecomment-169823245.

[fedorov]

I am not familiar deeply enough with this specific topic (i.e., what is the relationship between XSD mentioned here and Slicer execution model), but "reference" is an ambiguous term. As an example, Slicer does not have a concept to parallel DICOM Frame of reference, and "reference" attribute you mention here probably refers to the image node, which may or may not have a DICOM representation in the database. In Slicer, "reference" attribute is used in quite a few CLIs here: https://github.com/Slicer/Slicer/tree/master/Modules/CLI, but I believe its purpose is to initialize things like how the output should look like (window level, lookup table), and its semantics will probably depend on the object type.

[pieper]

I think it would be helpful to think of what is needed to support proper tracking so that all inputs and outputs of CLIs can be used to make well-formed DICOM objects. I've looked at this problem in the past and it seems tractable, but in some cases it may not be identical to the semantics of current flags. That is to say that making CLIs fully DICOM compatible will take more than this one change.

On Fri, Jan 8, 2016 at 5:25 PM, Andrey Fedorov [email protected] wrote:

I am not familiar deeply enough with this specific topic (i.e., what is the relationship between XSD mentioned here and Slicer execution model), but "reference" is an ambiguous term. As an example, Slicer does not have a concept to parallel DICOM Frame of reference, and "reference" attribute you mention here probably refers to the image node, which may or may not have a DICOM representation in the database. In Slicer, "reference" attribute is used in quite a few CLIs here: https://github.com/Slicer/Slicer/tree/master/Modules/CLI, but I believe its purpose is to initialize things like how the output should look like (window level, lookup table), and its semantics will probably depend on the object type.

— Reply to this email directly or view it on GitHub https://github.com/commontk/CTK/issues/623#issuecomment-170144720.

[hmeine]

I agree with both of you; this issue has already brought up the following:

• What was the intention behind the reference attribute?
  • I think @jcfr said that it was not used in Slicer at all.
  • @fedorov suspected it to be intended used for LUT settings.
• It could be used for provenance tracking (which I assumed it was meant for), in which case we may want to make sure that it has "enough provenance" for later DICOM exports.
• All of these questions need to be separately looked at for the four mentioned parameter types (starting with image).

[pieper]

I'd be interested in looking at the problem from a different perspective: if we consider CLIs to be mappings from one set of DICOM instances to another set, then what bookkeeping is needed to track the provenance. I would then think about how to wrap and augment existing CLIs so they can be used in the DICOM context. I'd contend that if the DICOM bookkeeping is done well, then it will also allow more sophisticated behavior at the application level, such as associating the correct frames of references for transforms etc.

On Sun, Jan 10, 2016 at 3:39 AM, Hans Meine [email protected] wrote:

I agree with both of you; this issue has already brought up the following questions:

• What was the intention behind the reference attribute?
  • I think @jcfr https://github.com/jcfr said that it was not used in Slicer at all.
  • @fedorov https://github.com/fedorov suspected it to be intended used for LUT settings.
• It could be used for provenance tracking (which I assumed it was meant for), in which case we may want to make sure that it has "enough provenance" for later DICOM exports.
• All of these questions need to be separately looked at for the four mentioned parameter types (starting with image).

— Reply to this email directly or view it on GitHub https://github.com/commontk/CTK/issues/623#issuecomment-170326233.

[fedorov]

Yes, I would be very interested to see proposals on how this perspective should be approached. But I think this perspective is too broad for me to suggest one myself. It is not even clear what would be the mapping from the XSD-supported element types into DICOM IODs, forget operations on those.

From my point, I want first to see tools in place to handle DICOM conversions explicitly via converter CLIs for now. It will not be easy (and maybe even counterproductive) to generalize semantics of an arbitrary CLI into XSD attributes for the purposes of DICOM attribute mapping/transformation.

[pieper]

My suggestion is to ignore the XSD and current CLI support and instead focus on the best fit for operations on DICOM instances. Then go back and adapt for legacy slicer execution module CLIs either by rewriting or by providing an adaptor.

On Sun, Jan 10, 2016 at 3:28 PM, Andrey Fedorov [email protected] wrote:

Yes, I would be very interested to see proposals on how this perspective should be approached. But I think this perspective is too broad for me to suggest one myself. It is not even clear what would be the mapping from the XSD-supported element types into DICOM IODs, forget operations on those.

From my point, I want first to see tools in place to handle DICOM conversions explicitly via converter CLIs for now. It will not be easy (and maybe even counterproductive) to generalize semantics of an arbitrary CLI into XSD attributes for the purposes of DICOM attribute mapping/transformation.

— Reply to this email directly or view it on GitHub https://github.com/commontk/CTK/issues/623#issuecomment-170391093.