Hi Federico,
these changes look good to me. I also agree that using the MITK serialization
for Point3D and Vector3D makes sense in this context. Would you be able to
prepare a branch or patch containing these changes? Information about how to
contribute can be found here: http://mitk.org/wiki/How_to_contribute
I created the following task to communicate on this matter:
https://phabricator.mitk.org/T24703
Let me know if you need any further assistance.
Alexander
Von: Federico Milano [mailto:[email protected]]
Gesendet: Montag, 23. April 2018 20:47
An: Seitel, Alexander
Cc: [email protected]
Betreff: Re: [mitk-users] Serializing custom properties of a NavigationTool
Hello Alexander,
My proposal would be to modify just some lines of two methods:
1. In mitkNavigationToolWriter.cpp change ConvertToDataNode member function so
that if there is a DataNode associated with the Tool, then use that DataNode as
a base for writing the NavigationTool properties. The custom properties that
are in the DataNode will then get serialized when the tool is written. If there
is no DataNode associated with the tool, then we create a blank DataNode (this
is the actual policy MITK is using right now).
2 In mitkNavigationToolReader.cpp change ConvertDataNodeToNavigationTool member
function so that we do not create a new DataNode as the associated Tool
DataNode, but use the one we receive in the method. After we feed the
NavigationTool with each of the special properties of the NavigationTool, we
could remove these properties so they do not confuse the user.
I'm linking a gist with these changes:
https://gist.github.com/fmilano/0551c7f95757ece4cb5e3064ecc343cc
Actually I have also found a couple of bugs during tool serialization of
Vector3D values, because the NavigationToolWriter and the NavigationToolReader
try to implement its own serialization code instead just using the already
proven MITK Vector3D and Point3D serialization code. That's why you can see
strange behaviours in the "IGT Navigation Tool Manager" view (specially when
trying to save a tool axis).
Please let's keep discussing this. It is not really a large change, just a
couple lines of code (actually reducing the number of lines if we start using
the MITK serialization instead of reinventing some already written
serialization code).
Thanks,
Federico
On Mon, Apr 23, 2018 at 10:03 AM, Seitel, Alexander
<[email protected]<mailto:[email protected]>> wrote:
Hi Federico,
thanks for offering to contribute to MITK. Generally it is a good idea to save
all the properties associated with this DataNode.
As a remark, this DataNode associated with the NavigationTool is intended to be
the representation object (in most cases a surface) of the Navigation tool
which is continuously updated with the current tracking pose. As a
representation object it can be chosen by the user and can also be changed
within the application. Tool specific properties set to this DataNode will be
lost as soon as a new representation object is loaded.
It would be great if you could share your idea on how you would solve the
serialization and deserialization in the case you describe. I don’t see any
obvious problem applying your changes.
Looking forward to receiving your contribution.
Best
Alexander
Von: Federico Milano [mailto:[email protected]<mailto:[email protected]>]
Gesendet: Sonntag, 22. April 2018 04:45
An: [email protected]<mailto:[email protected]>
Betreff: [mitk-users] Serializing custom properties of a NavigationTool
Hello. I want to save some custom information in a NavigationTool (stored in a
tool storage). I first thought that since a NavigationTool has an associated
DataNode, that then I could add some custom Properties to that DataNode and
that the NavigationToolSerializer would serialize them for me. Then I found
that it does not work like that. The NavigationToolWriter just looks for
certain Properties and then it saves only those properties. I have modified the
NavigationToolWriter (and the NavigationToolReader) to save/read all the
Properties in the tool DataNode.
I can prepare a PR with this mod, do you think there is a chance that you
accept that PR? Or is there a strong reason for maintaining the actual design?
Thanks,
Federico
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
