Quick reference to creating and using the modules.

<p>These screenshots illustrate how to create and use the modules for U3D export. 1. (A) Create a new network (Menu “File” →“New”). 2. (A) Create an instance of the WemSaveAsU3D module (type the name into the “Search Modules” field (1) and hit Enter). The module icon (2) should appear in the workspace. 3. (A) Open the example network of the module (right-click the module icon (2) and select “Show Example Network” (3) from the context menu). 4. (B) A new network tab and two module panels should open automatically. (If not, open the panels manually by double-clicking the module icons of WemSaveAsU3D and ComposeWEMDescriptionForU3D.) 5. (B) Modify the U3D model properties using the ComposeWEMDescriptionForU3D panel (4). 6. (B) To save the U3D file, go to the WemSaveAsU3D panel, specify a file name (5) and click “Save” (6). Other surface models (e.g. in the popular STL format) can be loaded by means of the LocalWEMLoad module (double-click the respective module icon and select the “Browse” button from the module panel).</p

Simplified Generation of Biomedical 3D Surface Model Data for Embedding into 3D Portable Document Format (PDF) Files for Publication and Education

<div><p>The usefulness of the 3D Portable Document Format (PDF) for clinical, educational, and research purposes has recently been shown. However, the lack of a simple tool for converting biomedical data into the model data in the necessary Universal 3D (U3D) file format is a drawback for the broad acceptance of this new technology. A new module for the image processing and rapid prototyping framework MeVisLab does not only provide a platform-independent possibility to create surface meshes out of biomedical/DICOM and other data and to export them into U3D – it also lets the user add meta data to these meshes to predefine colors and names that can be processed by a PDF authoring software while generating 3D PDF files. Furthermore, the source code of the respective module is available and well documented so that it can easily be modified for own purposes.</p></div

Example of a more complex application network.

<p>(A) This example network simulates a complex image processing chain (read from bottom to top). The network generates an Open Inventor Scene with a cube and a sphere as “segmentation results” (B). The two objects are then converted into WEM patches (SoWEMConvertInventor modules) and the properties (names and colors) are set (WEMModify modules). Finally the two WEM patches are merged into one WEM and afterwards written into a U3D file. The result is displayed on the bottom right (C). A file containing this network is provided as <a href="http://www.plosone.org/article/info:doi/10.1371/journal.pone.0079004#pone.0079004.s001" target="_blank">File S1</a>.</p

Code snippet of pre-defined constants.

<p>This code snippet from WEMSaveAsU3D_Definitions.h shows comments pointing to the chapters of the ECMA-363 standard where the respective block type constants are defined.</p

Example Network for the new MeVisLab modules.

<p>(A) This example network illustrates the basic usage of the WEMSaveAsU3D module and the ComposeWEMDescriptionForU3D module. The network is available with the standard distribution of MeVisLab (right-click on the instance of a WEMSaveAsU3D module and select “Show Example Network”). The LocalWEMLoad module loads a 3D model defined in Object File Format (“venus. off”, part of the MeVisLab demo data) and the WEMSaveAsU3D modules writes it into a U3D file. The ComposeWEMDesriptionForU3D module sets the color of the model as well as object and group names. The result is displayed on the bottom (B).</p

Model of a segmented femur.

<p>Model of a left human femur segmented with MeVisLab. The model shows the outer surface (red), the surface between compact bone and spongy bone (green) and the surface of the bone marrow (blue).</p

Overview of the approach.

<p>The illustration shows an overview of our approach by combining several of the previous figures in a simplified fashion. The upper part (blue box) represents a mapping, which is visible to the user. The parts in the middle are internal ontology concepts that are hidden for the user. The SQL code in the lower part has been automatically compiled from the above ontologies.</p

Types and numbers of intermediate nodes that were used in complex mappings in the urology project.

<p>Types and numbers of intermediate nodes that were used in complex mappings in the urology project.</p

Command type definitions describe how to process mapping nodes from the mapping ontology.

<p>All intermediate nodes in the mapping ontology are connected to a command type definition. They contain SQL code fragments, which describe how to filter and transform the facts data derived from operands 1 and 2 (OP1 and OP2).</p

Overloading internal data model properties.

<p>This real-world example illustrates how semantic relationships between source data elements are stored explicitly in the ontologies and how they can be processed: Stating that <i>Gleason1 hasDateStartValueColumn DateBiops</i> e.g. tells the export software to use the data entry in the Value column of DateBiops as DateStartValue in Gleason1. Gleason2 is processed the same way.</p