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
#623 (comment).

[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
#623 (comment).

[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
#623 (comment).

[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
#623 (comment).