If you want to get the best out of your products, our Technical Support Team is available to assist you in any question, request, or technical issue that you may have.
Open Inventor 9.7
Open Inventor® 9.7 (January 2017)
The following document contains the release notes for the latest minor release 9.7 (January 2017).
The current service release is 9.7.0. See the bugs fixed section for a complete list of issues resolved for each version. Make sure to read the Compatibility Notes as well. They contain information about important changes in this release.
Finally, check the Life cycle topic for important information about Open Inventor platform support changes in upcoming release.
See below the complete list of enhancements and new features included in Open Inventor 9.7.
Starting with Open Inventor 9.7, Microsoft Visual Studio 2015 (update 2) is now officially supported for both 32 and 64 bits platforms. This support aloso requires a newer version of FLEXnet tools, and it's now mandatory to use, at least, the 11.14 version.
Please also note that because of the integration of Qt 5.6, Visual Studio 2010 is no longer supported (32 and 64 bit).
Because of the integration of Qt 5.6, the only compiler supported under linux is now GCC version 4.4.4 64bits.
Open Inventor 9.7 introduces a brand new installer (.dmg file) for the C++ and Java package. For more information regarding all the details of these installers, please refer to the installation procedures (C++ - Java)
Architecture name has also changed : MacOSX is now OSX. So the OIVARCH environnement variable need to be set to arch-OSX-x86_64-clang60-release or arch-OSX-x86_64-clang60-debug.
The only supported compiler for MacOSX is now clang 6.0. Note also that all demos are available through xcode projects.
Open Inventor now fully supports QT 5 and requires the version 5.6 of the well known GUI library. This new feature introduces two major changes from an application point of view
SbQtHelper::addPlatformPluginsPath(). This method will initialize the path to the QT platform libraries depending on your configuration and allow Qt to load properly.
SbQtHelper::addPlatformPluginsPath()is given, as a parameter, the path where to find the platforms directory in the package you distribute (originally found in <$OIVHOME/$OIVARCH/platforms>).
Please keep in mind that the second option does not allow any modification of the folders hierarchy of your application.
setStereo(SoStereoParameters parameters)function. Please note that MFC Viewer Components also provide the same level of feature. Unfortunately, a bug in Qt 5.6 prevents us to provide the Raw Stereo feature for Qt Components.
This shape node constructs triangle fans out of vertices located at the coordinates specified in the vertexProperty field (from SoVertexShape), or the current inherited coordinates. For optimal performance, the vertexProperty field is recommended. SoIndexedTriangleFanSet uses the indices in the coordIndex field (from SoIndexedShape) to specify the vertices of the triangle fans. An index of SO_END_FAN_INDEX (-1) indicates that the current fan has ended and the next one begins.
The vertices of the faces are transformed by the current transformation matrix. The faces are drawn with the current light model and drawing style. Treatment of the current material and normal binding is as follows:
If any normal (or materials) are specified, Open Inventor assumes you provide the correct number of them, as indicated by the binding. You will see unexpected results if you specify fewer normal (or materials) than the shape requires. If no normal are specified, they will be generated automatically. To render triangles that are not in fans, please refer to SoIndexedTriangleSet and SoIndexedTriangleStripSet nodes.
Available since Open Inventor 9.4 the capability to draw cell outlines offers a great visual improvement for SoHeightFieldRender rendering. In Open Inventor 9.7 it's now possible to change the color and the width of these outlines.
To achieve this, two new fields have been added to the SoHeightFieldRender class:
Of course value of these fields are only taken in account if SoHeightFieldRender::cellOutline is set to TRUE.
Illustration of a SoHeightFieldRender with cell outline activated, size set to 5 and color updated.
( click on image to get full resolution)
In order to improve our DICOM support, VolumeViz reader SoVRDicomFileReader has been upgraded and now uses the third party library GDCM. As a result, the number of DICOM image encoded now includes:
Moreover, new SoVRDicomFileReader are now able to load RGB images from a DICOM file.
Note that no additional license is required to use the upgraded reader.
Starting with Open Inventor 9.7, VolumeVizLDM now integrates OpenJPEG library in order to be able to offer wavelet compression for LDM file. The result is a new compressor class SoJp3dDataCompressor that can be used in your custom reader if you want to implement a Jp3d capable reader.
In order to be able to generate Jp3d compressed files, LDM Converter now provides a new option to generate a Jp3d compressed LDM file instead of the classic gzip file. If you use the commande line version of the converter, you may pass the option -c jp3d to get the Jp3d compression. If you use the SoConverterParameters class, you will then need to add a call to
SoConverterParameters::setCompressionName("jp3d") to activate this new compression algorithm. It supports lossless and lossy compression. Please refer to the associated documentation to get more information about the compression parameter of the SoJp3dDataCompressor. As usual, the detection of the format will be automatic when, after compression, you will load the file within an application using the SoLDMReader.
Please note also that when using Jp3d compression, you may notice that time to reach full resolution of your volume data may be a little bit longer compare to gzip compression. But the high compression rate make Jp3d compression very useful fot archiving dataset and is far more efficient if you load your datas from a limited bandwidth network.
as these new methods getBuffer return an object of type SoBufferObject, the library MeshViz Extractor now depends on the OpenInventorGL lib. Please note also that the returned SoBufferObject can be used directly into a shape.
Another chart, available at this address, shows that Action Time (time from the start of the extraction and the first render) also benefits from this new method with a reduction of the time needed to get the first frame rendered compared to Open Inventor 9.6 (in every case for the same kind of extractions).
The computeMode field is available for any ImageViz engine filling both of the following conditions:
In previous ImageViz versions the computeMode field was set by default to MODE_2D, but this was a problem and could lead to errors when applied on a 3D image. Now the default mode is a new MODE_AUTO enumerate that chooses automatically the most suitable mode at the execution. This mode is equivalent to:
Most of the morphological algorithms relying on the use of a cubic structuring element allow now to select which voxels can be considered as neighbors of a central voxels. The related engines expose a new field neighborhood3d with 3 possible values:
The default mode is CONNECTIVITY_26 corresponding to the former behavior.
The new class SoProxyDataAdapter allows to define a Region Of Interest (ROI) on an SoImageDataAdapter class. This object can be then used as input of any ImageViz image processing engine in order to apply the corresponding algorithm only on the selected ROI. It avoids to make a copy of the selected area with an SoCropImageProcessing engine. Note that this ROI is necessarily a box aligned with the original image bounding box. This class may also be used to filter out a specific channel (e.g : extract the red component from an RGB image).
These new features are especially useful for implementing custom engines. In addition, the SbDiscreteLineProfile class allows to extract all voxels intensities along a segment defined by 2 points. This feature can be used to draw a line profile.
Some new engines allow to perform a registration between two 3D datasets:
Registration of an MRI data set (gray) on a CT data set (colored)
The SoBoxFilterProcessing engine has been rewritten allowing some strong optimizations. Following charts shows performances comparison between Open Inventor 9.6 and Open Inventor 9.7 (3D and 2D).
Please note that now, when used with the autoScale field set to YES, the output type is no longer upgraded (ie: an 8 bits input gives now an 8 bits output). If the autoScale option is set to NO, the output type is still upgraded.
The SoNonLocalMeansFilterProcessing new engine applies an edge-preserving smoothing filter. It computes a weighted mean of a large set of pixels (search windows) around the pixel to be denoised (target pixel). The pixel weight in the search window is a function of the similarity between this pixel and the target pixel. A pixel very similar to the target pixel will be assigned to a weight close to 1. A pixel very different from the target pixel will be assigned to a weight close to 0 and will have a small impact on the final denoised value.
|Original Image (1024x1024)||Square Medial Filter of size 10||NonLocal Means Filter of size 10|
The SoMedianFilterProcessing engine proposes a new field kernel type. The ITERATIVE mode enables the former mode of the median filter. This algorithm repeats iteratively a median filter on a square or cubic window with a side size of 3. This algorithm converges quickly and applying more than 3 iterations doesn’t change the result significantly. As a consequence the main drawback of this algorithm is to be ineffective when a large window size is required. The BALLS and CUBE modes perform a real median filter on the full size of the window. These modes are performed by an optimized algorithm which offers improved performances. The gain of performance is especially noteworthy in 3D case. For small kernel size in 2D, the former mode (iterative) is recommended.
|Original Image (1024x1024)||Iterative median of size 20 (0.15 sec)||Disk median of size 20 (0.13 sec)|
Following charts shows a scalability comparison of median modes on a 512x512x512 3D dataset
Please note that a new parameter is exposed with this command. The default mode corresponds to the former behavior in order to preserve compatibility.
The new engine SoThresholdingByCriterionProcessing allows thresholding a grayscale image by selecting a comparison criterion as used with the SoCompareValueQuantification and SoCompareImageQuantification engines. This engine presents the benefit of defining a threshold with a single value instead of two like with the classical SoThresholdingProcessing engine.
The SoAutoThresholdingProcessing engine proposes a new field RangeMode for selecting the way to define the input range. The OTHER enumerate corresponds to the former mode which was not adapted by default when the dynamic of the input image was greater than 256 gray levels. The new mode MIN_MAX allows a default behavior working with most of the grayscale images.
The new SoCenterLineApproximation3d engine extracts the centerlines of a 3D object. Contrarily to the existing SoSkeletonProcessing this algorithm passes at the center of the branches constituting a 3D objects and limits the generation of prunes artifacts. The number of branches to detect can be set or automatically computed. This engine produces 2 outputs
Result of the centerline algorithm
Data courtesy of Cancer Imaging Archive - Smith K, Clark K, Bennett W, Nolan T, Kirby J, Wolfsberger M, Moulton J, Vendt B, Freymann J. (2015). Data From CT_COLONOGRAPHY. The Cancer Imaging Archive. http://doi.org/10.7937/K9/TCIA.2015.NWTESAY1
The new SoEuclideanDistanceMapProcessing3d distance map engine computes a 3D distance map with the Euclidean metric whereas the former SoChamferDistanceMapProcessing3d makes an approximation with the Chamfer metric. The Euclidean metric is much more precise but is more time consuming for computation.
(XY view of a sphere)
|Distance map with the Chamfer metric
|Distance map with the Euclidean metric
The new SoLocalThicknessMapProcessing3d engine computes the local thickness for each voxel in a binary image, defined as the diameter of the largest ball containing the voxel and entirely inscribed in the object, following the definition of Hildebrand&Ruegsegger, J.Microscopy, 185:1, 1997.
Result of SoLocalThicknessMapProcessing3d with TEMPERATURE color map
The SoIntensityHistogramQuantification and SoIntensityBinHistogramQuantification new engines compute the histogram of a gray level image. The first engine imposes a bin size of 1 whereas the second one allows setting a specific bin size.
In the SoDataMeasurePredefined class the LENGTH_3D measure, also known as Feret's longest diameter, represents the major diameter of an object. The BREADTH_3D measure is the primary minor diameter, largest diameter orthogonal to LENGTH_3D. The new measure THICKNESS_3D is the secondary minor diameter, largest diameter orthogonal to both measures LENGTH_3D and BREADTH_3D. The related THICKNESS_ORIENTATION_PHI_3D and BREADTH_ORIENTATION_THETA_3D measures express the orientation of this secondary minor diameter.
Precision and capacity have been improved for large data analysis with the following predefined measurements of the SoDataMeasurePredefined class:
ImageViz makes a difference between gray level, label and binary images. This distinction was not visible in the public API, any of these image type was seen as a gray level image. An engine requiring a specific type used to cast automatically the input to the expected type. For instance if an engine expected a binary image as input and a 256 levels image was set, all values greater than 1 were clamped at the execution. If this behavior could be convenient at some points, it could also have some disastrous side effects leading to incomprehensible bugs. Applying an engine on an incorrect data interpretation type raises now an exception. The new interpretation field of the SoImageDataAdapter class allows to control explicitly the interpretation type (VALUE, LABEL or BINARY).
Use case: 03.1.LabelAnalysis tutorial demo : This demo loads a binary dataset from a tif file. By default a data adapter got from an image file has the interpretation field set to VALUE. Applying an SoLabelingProcessing engine directly on this data adapter would raise the exceptions below:
Inventor error: LabelingProcessing: Unable to initialize 'inObjectImage' input field with a value image. Inventor error: LabelingProcessing: Unable to initialize 'inObjectImage' input field. Inventor error: LabelingProcessing: engine cannot be computed because input and/or output are not valid.
In order to avoid exceptions and assure the code runs as before the following instruction has been added to this demo:
imageAdapter->interpretation = SoImageDataAdapter::BINARY;
In order to reduce bandwidth usage and latency, H.264 video codec support has been integrated in this new version of RemoteViz. H.264 is a video codec standard using an advanced compression method which allows to obtain high-quality videos while keeping a low bit rate. It uses the Nvidia video codec SDK for video encode hardware acceleration. Indeed, NVIDIA GPUs (Kepler generation or higher) contain a dedicated accelerator to encode video at higher speeds and with a better power efficiency than CPU-based encoders.
Compared to JPEG encoding, H.264 encoded streams reduce the bandwidth usage between clients and the service by 30% for the same level of image quality and FPS. The following chart shows the bandwidth comparision between JPEG encoder and H264 encoder at constant image quality and FPS.
Please note that some hardware requirements have to be fullfiled in order to benefit from H.264 encoding.
To be able to encode using H.264, server side application must be launched on a NVIDIA Quadro, Tesla, GRID or GeForce products with Kepler, Maxwell or Pascal generation GPUs. Moreover you must install Cuda 8 Toolkit from NVIDIA. On client side application, there is no particular hardware requirement as long as the H.264 decoding is done through HTML5 Api.
Introduced in RemoteViz 9.6, the independent service mode enables to run a RemoteViz application based on your own render engine. In this new version, the previous pushFrame mechanism has been replaced by a requestedFrame mechanism. RemoteViz now requests a new frame when needed, unlike the previous pushFrame mechanism that involves generating and pushing frames that are not always sent to the client. It enables to keep a better synchronization between the render engine and the RemoteViz service.
The JPEG encoding quality settings “InteractiveQuality” and “stillQuality” have been replaced by a new setting: “MaxBandwidth”. The JPEG quality is automatically calculated from the bandwidth and the FPS defined for the connection. The encoding settings have been moved from the removed RenderAreaSettings class to the ConnectionSettings one. Clients can now share the same view (renderArea) by using many encoders (JPEG or H.264) or many encoding settings (bandwidth and FPS).
RemoteViz in Open Inventor 9.7 also provides a new bandwidth calibration mechanism to allow your application to take advantage of all the potential of the used network. In a nutshell, during connection step, a calibration phase is launched to test bandwidth capability of the client application. The result of this calibration is then used to set default bandwidth value of BandwidthSettings object. Of course this value can be changed manually by using the provided API.
In this new version of RemoteViz the still rendering (done when there is no interaction on the scene) now use a PNG encoding (where it was previously JPEG encoding) to avoid any loss of quality.
We now provide a Docker file allowing you to run the demo server RemoteVizHelloCone in a Docker container. For more details please read $OIVHOME/src/RemoteViz/Docker/ReadMe.txt file.
Lots of new features have been added applying to the following mesh interfaces
If you want to get the best out of your products, our Technical Support Team is available to assist you in any question, request, or technical issue that you may have.
FEI Visualization Sciences Group operates at a worldwide level through offices in the United States, United Kingdom, France and distributors. Feel free to contact us.
Request an evaluation version of Open Inventor. Evaluation versions include full access to our technical support and product experts.
FEI Visualization Sciences Group is the leading provider of advanced 3D visualization and analysis software tools for developers, engineers and scientists in natural resources, medical and life sciences, and engineering.
©2015 FEI. FEI, the FEI logo, and Open Inventor are trademarks of FEI Company or its affiliates. All other trademarks belong to their respective owners.