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]> 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]]
> *Gesendet:* Sonntag, 22. April 2018 04:45
> *An:* [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
