public class SoDataRange extends SoNode
SoDataSet
or SoVolumeData
) that will be mapped into the color map (SoTransferFunction
). When the volume data type is larger than the data type on the GPU, for example float data scaled to byte data, it also specifies the range of scalar data values that will be scaled to fit in the GPU data type.
By default VolumeViz maps the entire range of the voxel's data type (e.g. 0..65535 for unsigned short) into the colormap. This is often correct for byte (8 bit) voxels, but seldom correct for 16 bit voxels and never correct for floating point voxels. Use an SoDataRange
node to specify the actual (or desired) range of data values to be mapped. For example, a typical initial data range for DICOM data calibrated in Hounsfield units might be -1000 to 3000.
Data characteristics:
SoDataSet
method getDataType().
SoDataSet
method getDataSize().
SoDataSet
method getMinMax(). SoVRDicomData
object obtained from the SoVRDicomFileReader
or by using the MedicalHelper class. You can also use the MedicalHelper method dicomAdjustDataRange.
When using multiple volumes (see SoMultiDataSeparator
), a single SoDataRange
node can be used to specify the data range for all volumes or each volume can have its own independent data range. In the second case, create one SoDataRange
node for each volume and set the dataRangeId
equal to the SoDataSet.dataSetId
of the corresponding volume.
Note that the meaning of the min and max fields in SoDataRange
is quite different than the meaning of the minValue and maxValue fields in SoTransferFunction
. The fields in SoDataRange
specify the range of voxel values that will be mapped into the full color map. The fields in SoTransferFunction
specify the range of indices in the color map that will actually be used to store the color map. The visual effect changing these fields can be quite similar, but there are trade-offs to be aware of. Changing the SoTransferFunction
fields is generally much faster and can be a useful approximation of changing the data range, but the resolution of the color map (the ratio of data values to color map entries) is reduced.
NOTE: Setting the min value greater than or equal to the max value will cause this node to be ignored.
Brightness and contrast: Often the distribution of voxel values within the actual data range is not uniform and more details can be seen by adjusting the For larger data types, changing the data range may require VolumeViz to recreate the data textures on the GPU. This is necessary to maximize use of the available bits of precision on the GPU. Since Open Inventor 9.6, recreating data textures should not be required for 8 bit data or for 16 bit data when the If the data set contains explicit RGBA values (
File format/default:
DataRange{
Action behavior:
See also:
SoDataRange
values to increase brightness and/or contrast. This is particularly true when using a gray scale color map (for example the predefined INTENSITY map in SoTransferFunction
). In medical imaging this range setting is often specified by the
window center and
window width.
The window center is the image intensity that will be displayed as a medium-gray and the window width is the range of data values between full black and full white. For example, if the data volume contains byte data with a native range of 0 to 255, the default data range (0 to 255) is effectively specifying a window center of 128 and width of 256. To increase contrast in the resulting image we might set a data range of 20 to 110, which makes the window center and width 65 and 90 respectively.
Performance:SoDataSet.texturePrecision
field is set to 16.
Recreating data textures may be slow for larger volumes, even in the 512^3 range. There are several parameters that significantly affect this:
For backward compatibility, the default tile size is still only 64. This is quite small for modern CPU/GPU hardware. The smaller the tile size, the larger the total number of tiles that must be managed by VolumeViz. This overhead can be significant, especially for operations that require reloading the data textures on the GPU, for example, changing the data range (SoDataRange
). For smaller volumes, like 512^3, it can be efficient to set the tile size large enough to contain the entire volume. For very large volumes, larger tile sizes are efficient for SoVolumeRender
but somewhat inefficient for slice rendering because complete tiles must be loaded even though the slice only uses part of the data. Applications should experiment.
For volumes stored in LDM file format, the tile size must be specified when the volume is converted to LDM (see SoConverter
and the "-t" option). For other data data formats the tile size should be specified after the SoVolumeData
node is created, using the
ldmResourceParameters field, but before setting the
filename field.
This environment variable (see SoPreferences
) affects much more than its name implies. VolumeViz always manages data as "tiles", regardless of the data format. In many cases VolumeViz must create (or uncompress) the tiles at run time. These cases include in-memory volumes, any volume reader that does not implement the readTile() method (all built-in formats except LDM) and compressed LDM format files. If this variable is true ( the default value), then VolumeViz only keeps a small cache of tiles in memory. See the SoBufferObject
method getBufferObjectCache() for the current default and note that this setting is separate from the max main memory parameter. If a tile's data is needed and that tile is not in the cache, the tile must be recreated. This overhead can be significant, especially for operations that require recreating data textures on the GPU, for example, changing the data range (SoDataRange
). We recommend setting this variable to false unless the memory conserving feature for compressed tiles is critical.
SoDataSet.texturePrecision
When the data set's texturePrecision is at least equal to the numSignificantBits and you are not combining multiple data sets, i.e. your volume data is not under an SoMultiDataSeparator
, then the data range scaling can be applied on the fly during rendering (i.e. on the GPU). This implies that data textures don't need to be regenerated when the data range changes and interactivity is much better.
This parameter doesn't actually resend data to the GPU but it does require updating the sub-tile min/max values, which can be quite costly. Setting subDivideTiles to false may increase DataRange performance (the default is false).
SoVolumeData
dataRGBA field is true), then SoDataRange
and SoTransferFunction
have no effect on rendering.
}
dataRangeId 1
min 0
max 0
mapOnFullColorRange true
SoCallbackAction
, SoGLRenderAction
, SoPickAction
, SoWriteAction
, SoGetBoundingBoxAction
Sets a data range in the current traversal state.
Inventor.ConstructorCommand
Modifier and Type | Field and Description |
---|---|
SoSFInt32 |
dataRangeId
This field allows the use of multiple data ranges for the same shape.
|
SoSFBool |
mapOnFullColorRange
Specifies how to map data values that are outside of the data range.
|
SoSFDouble |
max
Maximum data value of the data range.
|
SoSFDouble |
min
Minimum data value of the data range.
|
VERBOSE_LEVEL, ZeroHandle
Constructor and Description |
---|
SoDataRange()
Constructor.
|
affectsState, callback, copy, copy, distribute, doAction, getAlternateRep, getBoundingBox, getByName, getMatrix, getPrimitiveCount, getRenderUnitID, GLRender, GLRenderBelowPath, GLRenderInPath, GLRenderOffPath, grabEventsCleanup, grabEventsSetup, handleEvent, isBoundingBoxIgnoring, isOverride, pick, rayPick, search, setOverride, touch, write
copyFieldValues, copyFieldValues, enableNotify, fieldsAreEqual, get, getAllFields, getEventIn, getEventOut, getField, getFieldName, hasDefaultValues, isNotifyEnabled, set, setToDefaults
dispose, getEXTERNPROTO, getName, getPROTO, isDisposable, isSynchronizable, setName, setSynchronizable
getAddress, getNativeResourceHandle, startInternalThreads, stopInternalThreads
public final SoSFInt32 dataRangeId
SoDataSet
).
public final SoSFDouble min
public final SoSFDouble max
public final SoSFBool mapOnFullColorRange
min
data value are mapped to the first color entry and any data values greater than or equal to the max
data value are mapped to the last color entry.
If mapOnFullColorRange is false, then any data value less than min
data value is mapped to the first color entry and the min
data value is mapped to the second color entry; any data value greater than the max
data value is mapped to the last color entry and the max
data value is mapped to the next to the last color entry.
Generated on January 23, 2025, Copyright © Thermo Fisher Scientific. All rights reserved. http://www.openinventor.com