Sorry, I accidentally deleted the history of this thread...
Hello everyone, I just wanted to ask if geometries can already be serialized separately from the surfaces when saving the scene. Best Martin Hi again, we'll have a look at the vrml reader/writer. I guess there is no particular reason we didn't integrate it so far when its already there. Regarding the IO refactoring, I forwarded the mail to our guy who is responsible for the project, he should write something about that soon. Regarding scene serialization you are absolutely right. We should always store the geometry in this case separately. Best, Stefan ________________________________________ Von: Ingmar Wegner [iwegner@...] Gesendet: Mittwoch, 6. August 2014 16:38 An: Kislinskiy, Stefan Cc: Mitk Users Betreff: Aw: AW: [mitk-users] Serialization of a surface node Hi Stefan, was there a reason to not connect the vrml reader / writer from VTK to MITK? AFAIK this file format could also store additional data such as a transformation. We have added vrml IO to our mitk workbench as we have several other projects using vrml files and are satisfied so far even though that we use our own vrml reader and only use vtkVRMLExporter as writer. Speaking of which: is there a schedule when to integrate the micro service based IO refactoring? For us at least a short term solution would be usefull such as the solution I mentioned before: In case the project is saved as one mitk project file that also contains all properties not merging the geometry into the surface file would be good. In this case a serialized and deserialized dataStorage would be equal! And it should also be quite straight forward for point sets and such, right? Bug Squashing almost over! Best, Ingmar Gesendet: Mittwoch, 06. August 2014 um 10:28 Uhr Von: "Kislinskiy, Stefan" <s.kislinskiy@...> An: Wegner <iwegner@...>, "Mitk Users" <mitk-users@...> Betreff: AW: [mitk-users] Serialization of a surface node Hi Ingmar, We already discussed this issue several times as it is quite annoying indeed. Unfortunately, as far as we know, there is no surface format currently supported by MITK which preserves transformations (neither STL, nor OBJ, VTK or VTP is able to). This would be the most elegant and simpe solution to have such a format for surfaces. However, other data types like point sets are affected as well. Recently we had a platform project to enable options for file writers but it isn't merged yet. A short-term solution would be a check-box during file saving asking for applying the current transformation/geometry. A better mid-term solution would be able to save the geometry as well. We didn't agree on a solution yet, as the idea to save the geometry in a seperate but optional file wasn't liked so much. For MITK project files it could be the same concept as for the property files for data nodes but for saving data nodes as external data types an accompanying geometry file might be easy to lose during copying or further processing by other tools. We will put more effort in this issue in the near future during bug squashing and are open for great ideas. :) Best, Stefan ________________________________________ Von: Wegner [iwegner@...] Gesendet: Donnerstag, 17. Juli 2014 23:44 An: Mitk Users Betreff: [mitk-users] Serialization of a surface node Hi all, as there are discussions on serialization currently going on I also wanted to add one thing: I am using an .mitk project file quite often to recover the state of my plugin. Sometimes for debugging, sometimes as interface between two plugins. Let me explain the latter: one plugin A creates a certain setup of data nodes in the DataStorage and the next plugin B consumes this data and processes the data. So I should be able to store the project after processing plugin A into an .mitk file and close and open the Workbench and load the project again to continue with plugin B. But: when I save a surface node the geometry of the surface is applied to every vertex in the surface and this is stored to file. When I load the surface it is displayed at the same location as before but the node is different. The geometry equals identity and the vertices are modified obviously. The thing is, that plugin B uses the geometry of the surface and if this one is not set or not as expected, the result is incorrect. So would there be a way to differ between saving an .mitk project (and then to also save geometry data as well and not to change vertices) AND saving a regular .stl (...) file by incorporating the geometry into vertices as that file format doesn't contain a container for this information? That would assure that a saved DataStorage with a surface node equals a loaded one. I would also contribute those changes once they are agreed upon. Best Regards! Ingmar ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ mitk-users mailing list mitk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mitk-users
