Systems and methods for segmentation network synchronization

Abstract

A computing device (101), a method, and a computer program product for replicating a three-dimensional label mask (20) of a three-dimensional volumetric data set (190) in a network of computing devices (100), wherein the device (101) receives, from a further computing device (102) of the network, a set of segmentation input data (21) describing an edit (2-1) of the label mask (20) at the further computing device (102), the set of segmentation input data comprising current position data, size data, and a label identifier associated with a spherical segmentation object (102-1) used by the second computing device (102) to interactively edit the label mask. The replication module (101-10) replicates an edited label mask of a further computing device (102) associated with a set of segmentation input data by calculating respective ellipsoids corresponding to the spherical segmentation object (102-1) stretched inversely proportional to the shapes of the voxels in the label mask, determining voxels (vi) of the label mask having positions inside the segmentation object based on the ratio of the distance between each voxel position in all three dimensions and the center position of the ellipsoid divided by the respective semi-axis lengths of the ellipsoid, the division being performed by negating the exponents of each denominator using respective bitwise operations on a graphics processing unit of the computing device (101), and updating the determined voxels in the replicated label mask (10) according to the label identifiers of the segmentation input data (21).

Description

[Technical Field]

[0001] The present invention relates generally to 3D rendering, and more particularly to replicating 3D label masks across multiple computing devices in a network. [Background technology]

[0002] Typically, multi-user applications support collaborative sessions that allow connecting the front-end devices of multiple users via a network. The connection can be established via a local network, e.g., multiple connected computing devices (e.g., VR stations) in the same physical location, or via a wide-area network (e.g., the Internet). In a collaborative session, the connected users share a virtual environment. The virtual environment includes volumetric representations of items as data objects visualized on display devices, with which the connected users have the possibility to interact. Actions taken by a particular user that affect the virtual environment need to be replicated (or synchronized) to the front-end devices of the other users so that each user ultimately sees the virtual environment in the same state.

[0003] In general, there are two approaches to achieving such state reproduction. a) Synchronization of the state of the virtual environment, which involves periodically transmitting and updating relevant data. The term "synchronization" of application states across multiple devices is used herein as a synonym for "replication" of such states on the devices and does not imply time-based synchronization of signals. Typically, one user's device (or a single dedicated server in a server farm) acts as the host for a multi-user session. Each user's application sends user inputs, such as "I want to grab this object" or "I want to move this object up," to the host. The host updates the state in its local copy of the virtual environment and periodically transmits updated state information to all connected users, such as "Object A is at position X" or "User 1 is holding Object B." Each user's application on each front-end device uses this information to update its local virtual environment state. b) Synchronizing User Input. This approach is similar to a) in that each user sends their input to the host. However, with approach b), the host does not update its local copy of the virtual environment state. Instead, the host simply forwards each user's input to all other connected users. Special care must be taken to ensure that all connected users receive and process the exact same input sequence. Each user's application can use this information to replicate the events represented by the received data within their respective local applications on the user's front-end device.

[0004] In a), even if the virtual environment state is out of sync between different users (e.g., one user is looking at an object at position X and another user is looking at the same object at a slightly different position), the state always returns to sync after a short period of time (typically around 1 second) because the host periodically sends the same authoritative version of the virtual environment state to all users.

[0005] In case b), the virtual environment state is not explicitly synchronized during a collaborative session (only when initializing users joining a collaborative session). Only user input is synchronized. Therefore, any relevant virtual environment state changes must be done in a fully deterministic manner. In other words, given the same list of user inputs, all users' local applications must reach the exact same virtual environment state. Otherwise, the state will become out of sync over time.

[0006] State synchronization works well when the state is not highly complex. In this context, state complexity refers to the amount of data required to store and transmit the state. Thus, approach a) can be used by collaborative applications with relatively simple (low-complexity) state. For example, online whiteboard applications typically have around 50 movable objects. In such cases, the entire state fits into a few hundred bytes. However, in collaborative sessions with large amounts of data (e.g., the state of thousands of objects or a few highly complex objects), approach a) is not an option because the amount of data describing the entire virtual environment state is too large to be transmitted over the network quickly enough to support real-time collaboration of connected users. Updates in such high-complexity state applications result in a waiting period of several seconds after each update for each user, which is unacceptable in real-time collaborative scenarios.

[0007] Approach b) is typically used in applications where each user interacts with one or more objects in the virtual environment. In this case, the application developer does not need to worry about achieving completely deterministic behavior, and it is usually sufficient to transmit the positions of a few objects in the virtual environment. The position and orientation of an object in 3D space can easily be represented in 24 bytes or less.

[0008] However, state synchronization approach b) becomes impossible when the amount of data required to represent the state is excessively large and cannot be efficiently transmitted over the network used by the collaborative session in real time. For example, for applications with thousands of objects, or objects with large amounts of data required for state representation (high state complexity), the data required to describe the state of all objects quickly exceeds the amount of data that can be reliably transmitted at the desired update rate (typically 10-60 Hz). Another example relates to medical image processing, where segmentation techniques are used to collaboratively label voxels in volumetric medical images. That is, segmentation labels applied by one user must be visible to all connected users in the collaborative session. In particular, for such medical applications, an accurate replication of each state for all connected users is essential. However, the amount of data required to store the assigned labels can easily exceed the amount that can be reliably transmitted at the desired update rate.

[0009] Examples of prior art solutions are described in the following documents: U.S. Patent Application No. US2022346888A1 discloses a system for visualizing and interacting with multidimensional data in an augmented reality, virtual reality, or mixed reality environment. In a medical environment, the disclosed embodiments provide a tool for doctors, surgeons, or other medical technicians to quickly load and review patient scans within an AR / VR / MR environment. U.S. Patent Application No. US2020054398A1 discloses a method for presenting medical imaging data in an interactive virtual reality environment. The system includes a head-mounted display (HMD) that determines whether a transparent 3D object overlaps a 3D model of an anatomical region based on a medical imaging scan, performs a shading process to set values ​​of pixels corresponding to portions of the 3D model not occluded by the transparent object, and sets values ​​of pixels corresponding to portions of the 3D model at the boundary of the transparent object to intensity values ​​obtained from the medical imaging data, and displays the 3D model with outer surfaces shaded to invoke the 3D object and inner surfaces unshaded at the boundary of the transparent object to preserve details embedded in the medical imaging data. The paper "A Collaborative Virtual Reality Environment for Liver Surgery Planning" (Chheang Vuthea et al., July 2021, Computers & Graphics 99(6)) discloses surgical planning software used in the treatment of tumor diseases. To improve virtual resection planning between surgeons in remote or co-located environments, a collaborative virtual reality environment is presented to assist liver surgeons in tumor surgery planning. The system allows surgeons to define and adjust virtual resections on 3D surfaces and 2D image slices of patient-specific organs. Changes to both modalities are synchronized, allowing surgeons to rapidly iterate and fine-tune the resection surface.The paper "Liver segmentation in contrast-enhanced CT data using graph cuts and interactive 3D segmentation refinement methods" (Beichel Reinhard et al., Med Phys, March 2012, 39(3), 1361-1373, published online February 21, 2012) evaluates a new approach for liver segmentation. It combines a graph cut segmentation method with a 3D virtual reality-based segmentation refinement approach. The developed interactive segmentation system allows users to manipulate volume chunks and / or surfaces instead of 2D contours in cross-sectional images. Summary of the Invention

[0010] Therefore, there is a need to provide a method and system for efficient state replication to connected devices in a collaborative session, particularly with respect to the state of volumetric data processed by the connected devices in real time. The term "real time" as used throughout this specification is understood by those skilled in the art of digital data processing as "near real time" or "quasi-real time." Any digital data processing step (e.g., image processing step) applied to data captured from the real world (e.g., sensor data converted into a visual representation of the sensor data) always results in a delay imposed by the digital data processing step. For convenience, only the term "real time" is used throughout this specification, e.g., when referring to the "near real time" behavior of the disclosed methods and systems.

[0011] The approach disclosed herein is particularly useful for medical image processing applications in which segmentation is used to label various organs or pathologies within a 3D dataset. For example, label information is used to hide, reveal, or highlight specific organs or regions. When segmenting a volumetric image (e.g., a CT scan), a label can be assigned to every voxel in the 3D dataset because each label mask is also volume-based. Generally, segmentation in image processing refers to assigning labels to individual 2D pixels in 2D or individual 3D voxels in 3D. Labels are stored in a separate image data structure, referred to herein as a label mask. Each pixel / voxel in the mask stores the label index of the assigned label. A label index of "0" can be used to indicate no assigned label for the respective voxel. Typically, the resolution of the label mask is the same as the resolution of the corresponding volumetric image (3D dataset), but this is not required. A separate data structure can be used to assign additional metadata to each label, such as a user-modifiable name, description, highlight color, or opacity. The visualization of the volume image can then be modified so that the color and opacity of each voxel are combined with the color and opacity of the assigned label. In essence, this allows for applying highlight colors and varying opacity to entire segments, such as organs or pathological regions.

[0012] A simple modification to standard ray marching processing can be used to hide or apply highlight colors to segmented areas within a 3D volume. In standard ray marching, at every step along the ray through the 3D volume, a transfer function is used to map each voxel's scalar raw data to the voxel's respective opacity and color values. In addition to checking the opacity and color of the current ray marching voxel location within the 3D volume, the same voxel location is checked within each 3D label mask. If the current voxel location (voxel) is assigned a label, the color and opacity specified for that label are taken into account when calculating the voxel's final color. However, it should be noted that ray marching is not the focus of this specification. Those skilled in the art will be able to use ray marching to render a 3D volume with an associated 3D label mask. Rather, the focus of this specification is on replicating a label mask being edited by one user to connected users in a collaborative session.

[0013] For example, a user can interact with a virtual environment (including 3D volume(s)) using a motion-tracked controller, e.g., to grasp, move, and rotate a loaded dataset. To edit the dataset's segmentation, a user can activate a spherical segmentation object (e.g., a spherical brush tool) and interactively draw on a label mask. The brush may be represented by the outline of a sphere. When the user moves the brush tool into the 3D dataset (e.g., CT data) and presses a controller button, voxels within the brush tool's sphere are assigned to the label currently selected for the brush tool (label setting mode). Alternatively, in a subtraction mode (label unsetting mode), voxels within the sphere already assigned to the currently selected label are removed from that assignment.

[0014] Determining which voxels are inside the sphere at a given moment and therefore should be included in processing a label mask modification command (e.g., assigning or clearing the currently selected label associated with a segmentation object) is, in principle, a trivial mathematical problem. The distance from the center point of every voxel to the center of the sphere is calculated and compared to the radius of the sphere. If the distance is greater than the radius, the voxel can be considered to be outside the sphere; otherwise, a label is assigned to the voxel that is inside the sphere. However, when determining whether a voxel is inside the sphere based on segmentation input data generated by an editing user, different GPUs in other connected users' front-end devices may reach the opposite conclusion, computing different results. This is due to the use of the IEEE 754 (IEEE Standard for Floating-Point Arithmetic," in IEEE Std 754-2019 (Revision of IEEE 754-2008), vol., no., pp. 1–84, 22 July 2019, doi: This is due to deviations from the standard (10.1109 / IEEESTD.2019.8766229). For example, GPU manufacturers are permitted to choose different handling of certain edge cases in floating-point arithmetic. These permitted deviations lead to different results regarding the voxels determined to be inside the segmentation object's sphere. As a result, different connected users may see different virtual environments at the voxel level when their GPUs attempt to replicate the virtual environment state corresponding to the segmentation state on the editing user's front-end device. This problem arises when replicating the state based on the respective segmentation input data, as per approach b). Especially for medical applications, even small deviations in the rendered label mask are unacceptable.

[0015] The above problem is solved by the embodiments set forth in the independent claims: a computer-implemented method for replicating a 3D label mask of a 3D volume data set in a network of computing devices, a computer program product having instructions configured to cause said method to be performed when the computer program product is executed on a computing device, and a computer system capable of loading and executing said computer program product to perform said method.

[0016] In one embodiment, a computer-implemented method for replicating a three-dimensional label mask of a three-dimensional volumetric data set in a network of computing devices is provided.

[0017] Assume that a collaborative session is already running on a network where multiple users are connected via their respective computing devices. When a new user joins the collaborative session via their own computing device, the additional computing device is initialized and synchronized with the entire current label mask dataset and the 3D volume dataset. Hereinafter, the additional computing device of the joining user will also be referred to as the first computing device. The entire 3D volume dataset includes the 3D volumes already loaded by the computing devices of all previously connected users. The entire current label mask includes a 3D label mask in which all voxels are assigned one or more respective labels, as set after the most recent editing / segmentation activity by the already connected user. Thus, voxels in the current label mask are associated with corresponding voxels in the 3D volume dataset. For each voxel in the label mask, a label index for the corresponding voxel in the 3D volume may be stored. Multiple label masks for multiple 3D volumes may be replicated independently of each other.

[0018] Once the first computing device is initialized, it is ready to receive a set of segmentation input data generated by a second computing device. The received segmentation input data reflects drawing commands that result in changes to the label mask compared to the current label mask on the first computing device. This received set of segmentation input data is generated while a user of the second computing device edits the label mask. To edit the label mask, the second computing device uses a spherical segmentation object, allowing the user to interactively draw on the label mask. The segmentation input data is also received by the first computing device because it is transmitted to all connected users (possibly via a host). The segmentation input data comprises current position data, size data (i.e., the radius of the sphere), and a label identifier associated with the spherical segmentation object. Typically, during an editing / segmentation activity, the set of segmentation input data includes multiple label mask editing commands that describe changes to the position of the segmentation object during the segmentation activity, while keeping the radius and label of the segmentation object constant. However, during the segmentation activity, it is also possible for the user to change the associated label identifier (e.g., switch to a label index representing a different segmentation color), and / or change the mode of the segmentation object (e.g., label setting mode or label unsetting mode), and / or change the radius of the sphere (to adjust the size of the segmentation object).

[0019] The first computing device then replicates the edited label mask of the second computing device based on the received set of segmentation input data. Thus, the first computing device performs the following steps for each of the received set of segmentation input data:

[0020] First, an ellipsoid corresponding to each spherical segmentation object is calculated, stretched inversely proportional to the shape of the voxels in the label mask. Typically, the voxels of a volume have a rectangular parallelepiped shape (rather than a cubic shape). This is particularly true for volumes generated by medical imaging techniques such as computed tomography imaging, magnetic resonance imaging, optical coherence tomography imaging, positron emission tomography imaging, single-photon emission computed tomography imaging, and 3D ultrasound imaging. In such techniques, multiple 2D scan images are combined into a 3D volume. However, the distance between two 2D scan images is typically different from the edge size of the 2D pixels in the 2D scan images. This results in a rectangular parallelepiped shape for the voxels. The calculated ellipsoids have the purpose of making the spherical segmentation object correspond to the rectangular parallelepiped voxel shape.

[0021] In the next step, the first computing device determines voxels of the label mask that have positions inside the segmentation object. To this end, the first computing device calculates the ratio of the distance between each voxel position in all three dimensions (called the numerator) and the center position of the ellipsoid, divided by each semi-axis length of the ellipsoid (called the denominator). As a result, the division is performed using bitwise arithmetic in the graphics processing unit of the first computing device. Thus, each semi-axis length is a floating-point number represented by an integer for the sign, mantissa, and exponent. The division is performed by approximating the multiplicative inverse of each denominator by sign-negating the exponent of each semi-axis length, and multiplying the approximated multiplicative inverse of each denominator by the respective numerator. The use of such bitwise arithmetic ensures deterministic determination of voxels that are inside the segmentation object. In contrast, using a standard GPU division instruction would result in a label mask on a first computing device that deviates from the label mask generated by a second computing device if the two devices use different types of GPUs (e.g., GPUs from different manufacturers). Of course, bitwise operations also work when the GPUs on the first and second computing devices are identical. In this case, the claimed method provides an alternative implementation to an implementation using a GPU standard arithmetic algorithm. It should be noted that an implementation using bitwise operations may produce slightly different results than a regular division implementation, resulting in slight differences in the effective sphere size. However, this is irrelevant with respect to the requirement that all connected users see the same label mask, which is always guaranteed by bitwise operations, which enable deterministic computations that are valid for any GPU.

[0022] Finally, the first computing device updates the determined voxels in the replicated label mask according to the label identifiers of the segmentation input data. That is, after all pending segmentation input data has been processed (i.e., after the update step is completed), the label mask of the first computing device is identical to the current label mask of the second computing device in all cases, regardless of the type of GPU used by the computing device. That is, after the label mask replication, users of each device see images rendered using the same segmentation information. For example, all voxels labeled with a specific intent by the editing device are also rendered with a specific color on the replicated device. This is a crucial requirement in collaborative sessions performed within medical applications. Often, in such collaborative scenarios, different users use different VR devices from different manufacturers and different GPUs. The bitwise operation-based solution proposed herein provides an exact replication of the current label mask on each connected device.

[0023] To explain the bitwise division operation in more detail, a specific implementation of division is described below. The division A / B is the sum of A and B, where A is the reciprocal of B. -1 It can be expressed by multiplying an approximation of B by B, which is calculated by subtracting B, interpreted as an integer, from a given integer constant. According to the IEEE 754 standard for floating-point arithmetic, the exponent of a 32-bit floating number is stored in the 8 bits following the sign bit. Since the exponent can be negative, it is implemented with a bias of 128 - 1 = 127. That is, 127 is added to the actual exponent to keep it always positive.

[0024] A compiler of the first computing device is instructed to interpret 32-bit floating-point numbers as integers without changing their binary representation. This may be achieved by using programming language-specific instructions such as "floatBitsToUnit" or "floatBitsToInt" in OpenGL Shading Language (GLSL), "asuint" or "asint" in High-Level Shading Language (HLSL), or by dereferencing an integer pointer set to the address of the floating-point number in languages ​​with explicit pointer support. The resulting integer is subtracted from a predetermined integer constant such that the result of the integer subtraction approximates the reciprocal of the floating-point number by leveraging the standardized encoding format of floating-point numbers, particularly the positions of the exponent and fraction in the binary representation. The result of the subtraction is reinterpreted as a floating-point number to obtain an approximation of the reciprocal of the original floating-point number.

[0025] For example, the interpreted integer may be subtracted from the hexadecimal number "0x7F000000," which is a predetermined integer constant (equal to the integer "127" shifted to 8 bits used for the exponent in a 32-bit floating number). By using "0x7F000000" as the predetermined integer constant, it is possible to implement a bitwise division operation in which 1 / 1 is exactly equal to "1." Bitwise division operations may also use other predetermined integer constants, such as "0x7EEEEEEE," which also results in very good overall precision.

[0026] Particularly in the context of medical applications, it is important to prove the identity of the original label mask (second computing device) and the duplicated label mask (first computing device). To this end, in an optional embodiment, the first computing device periodically receives, in addition to the segmentation input data, a hash value of the corresponding edited label mask of the second computing device. The first computing device then calculates the hash value of each duplicated label mask. If the two values ​​are the same, the accuracy of the duplication of the label mask between the computing devices is proven.

[0027] In a further optional embodiment, the first computing device (and the second computing device) may support various update modes. In addition to the already mentioned "label set mode" that sets the determined voxels in the replicated label mask to the label identifiers of the segmentation input data, and the "label unset mode" that removes certain previously set label identifiers from the determined voxels in the replicated label mask, any of the following update modes may be supported: a "label erase mode" that resets all label identifiers of the determined voxels in the replicated label mask; a "label set to unassigned voxels mode" that sets the label identifiers of the segmentation input data in the replicated label mask only to determined voxels that have not yet been labeled; and a "label set to visible voxels mode" that sets the label identifiers of the segmentation input data in the replicated label mask only to determined voxels that are visible according to the applied transfer function. Those skilled in the art may define further update modes supported by the connected computing devices.

[0028] Optional embodiments may support label identifiers in label masks of different sizes. For example, label identifiers may be stored as 8-bit, 16-bit, or 32-bit values ​​for each voxel. For example, a label mask with 8-bit integer values ​​for every voxel may have a maximum of 2 ∧ This allows for the definition of 8-1=255 different labels. In a 32-bit implementation, this is 2 ∧ The label mask can be expanded to 32-1=4294967295 labels. In an alternative embodiment, the value stored for each voxel in the label mask can be thought of as a bit field, with each bit corresponding to a different label. In this embodiment, the label mask can be used to assign multiple different labels to each voxel of the volumetric image. The number of different labels that can be simultaneously assigned to a voxel corresponds to the number of bits used to store the value of the label mask.

[0029] In one embodiment, a computer program product for replicating a three-dimensional label mask of a three-dimensional volumetric data set in a network of computing devices is provided, the computer program product comprising computer-readable instructions that, when loaded into a memory of a computing device and executed by at least one processor of the computing device, cause the computing device to perform a computer-implemented method as disclosed herein.

[0030] In one embodiment, a computing device for replicating a three-dimensional label mask of a three-dimensional volumetric data set in a network of computing devices is provided, the computing device implementing functional software modules configured to enable the computing device to perform the functions disclosed herein to perform the computer-implemented method.

[0031] In particular, the device has an interface adapted to receive a current label mask dataset and an entire three-dimensional volume dataset from the network of computing devices when the device joins a collaborative session on the network to initialize the computing device. As used herein, a collaborative session is an interactive session involving multiple users with respective computing devices, where the users work toward a shared goal in real time. The interface is further adapted to receive a set of segmentation input data from additional computing devices on the network. The set of segmentation input data (editing commands) describes editing of the label mask on the additional computing device. In that regard, the specific segmentation input data comprises current position data, size data, and a label identifier associated with a spherical segmentation object used by the second computing device to interactively edit the label mask.

[0032] The system further comprises: an ellipsoid module adapted to calculate respective ellipsoids corresponding to spherical segmentation objects stretched inversely proportional to the shape of the voxels in the label mask; a voxel identifier module adapted to determine voxels of the label mask having positions inside the segmentation object based on a ratio of a distance between each voxel position in all three dimensions and a center position of an ellipsoid divided by each semi-axis length of the ellipsoid, the division being implemented by negating the exponent of each denominator using bitwise operations on a graphics processing unit of the computing device; and an updating module adapted to update voxels in the replicated label mask determined according to the label identifiers of the segmentation input data; a replication module adapted to replicate the edited label mask to a further computing device associated with the set of segmentation input data by processing the edited label mask to a further computing device associated with the set of segmentation input data.

[0033] Advantageously, the voxel identifier is B, which is the reciprocal of A and B. -1 A bitwise division operation for the division A / B is performed by multiplying B by an approximation of B, which is calculated by subtracting B, interpreted as an integer, from a predetermined integer constant. The integer constant is predetermined by utilizing the standardized encoding format of floating-point numbers, particularly the positions of the exponent and fraction in the binary representation, such that the result of the integer subtraction approximates the reciprocal of the floating-point number. A compiler for the computing device is instructed to interpret the 32-bit floating-point number as an integer without changing the binary representation. The interpreted integer is then subtracted from a predetermined integer constant, such as hexadecimal "0x7F000000," hexadecimal "0x7FEEEEEE" (or another hexadecimal number that meets the above predetermined criteria). Finally, the result of the subtraction is reinterpreted as a floating-point number to obtain an approximation of the reciprocal of the original floating-point number with the exponent negated.

[0034] Additional aspects of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not intended to be limiting of the invention as so described. [Brief explanation of the drawings]

[0035] [Figure 1] 1 shows a block diagram including an embodiment of a computing device for replicating a three-dimensional label mask of a three-dimensional volume data set in a network of computing devices. [Figure 2A]1 is a simplified flowchart illustrating a computer-implemented method for replicating a three-dimensional label mask of a three-dimensional volumetric data set in a network of computing devices, according to an embodiment. [Figure 2B] 10 is a simplified flowchart illustrating an example of bitwise operations for performing division on a GPU to determine voxels within a segmentation object. [Figure 3A] ~ [Figure 3B] 10 is a screenshot showing an example of an editing activity for modifying the segmentation of a three-dimensional object with a segmentation object. [Figure 4A] Shows the voxels of a 3D volume and their coordinate system. [Figure 4B] 1 shows the typical elongated rectangular shape of a voxel in a volume data set and the spherical shape of the segmentation tool as seen by the user. [Figure 4C] 1 shows the same volume data set and segmentation tool transformed so that the voxels are cuboid shaped. [Figure 5] A representation of a 32-bit real number. [Figure 6A] , [Figure 6B] A simplified 2D view of the segmentation results and replicated segmentation results on two different GPUs is shown. [Figure 7] 1 shows an example of segmentation results in a medical application with the segmentation applied to the spine of a human skeleton. [Figure 8] A photograph of a collaborative session with four users and four connected computing devices is shown. DETAILED DESCRIPTION OF THE INVENTION

[0036] FIG. 1 illustrates a block diagram including an embodiment of a computing device 101 for replicating a three-dimensional label mask 20 of a three-dimensional volume dataset 190 in a network 100 of computing devices 101-10n (computing devices communicating via a network). In the example of FIG. 1, only visible voxels of the volume dataset 190 are shown, although the entire 3D volume dataset has a rectangular parallelepiped shape. FIG. 2A is a simplified flowchart illustrating a computer-implemented method 1000 for replicating a three-dimensional label mask of a three-dimensional volume dataset 190 in a network of computing devices, according to an embodiment. For example, the method 1000 may be performed by the computing device 101. Accordingly, FIG. 1 will now be described in the context of FIG. 2. Therefore, reference numerals from FIGS. 1 and 2 will be used in the following description. Furthermore, FIGS. 3A-3B are screenshots illustrating an example of an editing activity for modifying segmentations 32a, 32b of a three-dimensional object (the three-dimensional volume dataset 390) with a segmentation object 30. This example is also used in the context of the description of FIGS. 1 and 2A.

[0037] A computing device 101 is connected to other computing devices 102, 103, ..., 10n via a network 100 to conduct a collaborative session (by running a collaborative application). The computing devices have a standard communication interface that enables data exchange between the devices. Each computing device is operated by a respective user 1, 2, 3, ..., n. An example will be described below in which the computing device 101 receives data from the computing device 102 to replicate a label mask 20. It should be noted that in the described example scenario, the computing devices 103-10n perform the same functions as those described for the computing device 101 and can replicate the label mask 20 of the computing device 102 using their respective GPUs. Furthermore, one or more of the computing devices 101, 103-10n may be used as an editing device for its own label mask, in which case all other connected devices can replicate the corresponding modified label mask.

[0038] In the example collaborative session of FIG. 1, the computing device 102 is running an application that enables editing 2-1 of a three-dimensional volume dataset 190. In this example, the application is a medical application that renders a 3D volume from a CT scan of a human skull. However, any other application for visualizing a 3D object to a user can utilize the approach described herein. A volume is composed of so-called voxels. FIG. 4A shows several voxels pv_n of Vn. The voxels of the volume have a rectangular parallelepiped shape. In a complete volume Vn, each voxel layer has the same number of voxels arranged in a rectangular shape, resulting in a rectangular parallelepiped-shaped volume. Although voxels may have a cubic shape, in general, a volume Vn is usually composed of layers of 2D images, where each pixel of the 2D image is rectangular. In this example, it is assumed that the 2D image layers lie in the xn-yn plane of Vn's local coordinate system CSn. Looking at stippled voxels, we can see that the depth of a voxel in the zn dimension is different from the edge length of the voxel in the xn-zn dimension. The distance at which a 2D image is captured (e.g., by one of the volume imaging techniques mentioned above) corresponds to the depth of the voxel in the zn dimension. Typically, the depth of a voxel is different from the edge length of the respective pixel in the underlying 2D image layer.

[0039] Returning to the example of FIG. 1 , user 2 uses a spherical segmentation object 102-1 to interactively draw on a label mask 20 associated with a 3D volume dataset 190. In that regard, the segmentation object is used as a brush tool that the user can use to interactively draw on the 3D dataset. Voxels touched by the brush tool are labeled accordingly. The label mask 20 is also a 3D volume dataset that may store label values ​​for each voxel of the 3D dataset 190. A segmentation area 22 indicates voxels of the label mask that were touched by the brush tool 102-1 during edit 2-1. Labeled voxels (e.g., having a color label set for the segmentation object) are visualized to user 2 so that labeled voxels can be clearly distinguished from unlabeled voxels.

[0040] The editing commands generated while the user 2 is editing 2-1 the label mask 20 are also referred to herein as segmentation input data 21. During the editing 2-1 activity, a series of segmentation input data is typically generated while the segmentation object 102-1 is moving. Particular segmentation input data comprises current position data, size data, and a label identifier associated with a spherical segmentation object. The examples in FIGS. 3A-3C illustrate editing of a label mask associated with a 3D volume dataset (skull) 390 at three different time points t1, t2, and t3. At t1 (see FIG. 3A), the user approaches the skull 390 with the segmentation object 30, but the segmentation object has not yet intersected with the skull. At t2 (see FIG. 3B), the segmentation object has already labeled several voxels 32a of the label mask. While the segmentation object 30 intersects with the skull 390, the system records the corresponding editing commands ECa as segmentation input data. That is, ECa represents a series of segmentation input data reflecting the respective position data, size data, and label identifiers during the editing operation. At t2, the segmentation object "pierces" the skull, and the right portion of the sphere intersecting with the skull defines the current edge of the labeled voxel area 32a. At t3 (see FIG. 3C), the segmentation activity ends, and the user moves the segmentation object 30 away from the skull. The area 32b, which represents the voxels labeled during the editing operation, is now larger than it was at t2. That is, a further series of editing commands ECb was applied to the label mask between t3 and t2.

[0041] 1, in a collaborative session over network 100, the current label mask 20 with labeled voxels 22 in computing device 102 needs to be replicated in real time to the connected computing devices. Hereinafter, label mask replication will be described only for computing device 101. However, any of the other connected devices can implement the same replication method as computing device 101.

[0042] When computing device 101 first joins a collaborative session on network 100, an initialization step 1100 is performed, in which computing device 101 first receives (via its communication interface) the current label mask of the collaborative session and the entire 3D volume dataset 190 from the collaborative session host. Since the collaborative session host receives all editing commands from all connected devices, it knows the exact current label mask (because it knows the true order of all editing commands). The current label mask can then be provided to any replicating devices. The collaborative session host can be considered an intermediary for forwarding editing commands from editing devices to replicating devices, ensuring that all editing commands originating from different editing devices are always processed in the correct order. Once initialized, computing device 101 can replicate changes to the label mask applied by any of the connected devices. In this example, computing device 102 performs the most recent editing action on label mask 20. Each set of segmentation input data (editing commands) is provided to network 100 by computing device 102 and received 1200 by computing device 101. As described above, the set of segmentation input data 21 describes the edits 2-1 of the label mask 20 according to the edit commands generated at the computing device 102. That is, after receiving the segmentation input data 21, the computing device 101 knows the position of the segmentation object 102-1, its size, and the associated labels that need to be assigned to the voxels of the label mask that intersected with the spherical segmentation object during the editing activity at the computing device 102.

[0043] The computing device 101 has a duplicator module 101-10 adapted to replicate 1300 an edited label mask of the computing device 102 associated with a series of segmentation input data 21 by processing each of the series of segmentation input data with subsequent (sub)modules.

[0044] The ellipsoid module 101-11 calculates 1320 a respective ellipsoid corresponding to the spherical segmentation object 102-1 that is stretched inversely proportional to the shape of the voxels in the label mask. Figures 4B and 4C illustrate such an inverse stretching of the spherical segmentation object into its corresponding ellipsoid. To check if a voxel is inside the sphere of SP1, the position (v x ,v y ,v z ) to the center of the sphere (c x ,c y ,c z ) is calculated by equation F1, and the voxel position is defined as the center of the voxel.

number

[0045] However, as mentioned earlier, in real volumes, the size of voxels in three dimensions is usually not uniform. That is, the edge length of a voxel cuboid, which reflects the distance between two image layers in a 3D volume, is different from the edge length that defines the pixel size within a single layer. For example, in CT images, the CT slice distance (z-axis) is usually larger than the pixel size within each slice. A typical voxel size in a CT scan is 0.3 mm × 0.3 mm × 1.5 mm.

[0046] Figure 4B illustrates a situation where the edge length of pixels within a layer (slice) is a', but the edge length (slice distance) between two layers is c' > a', resulting in a cubic voxel shape for the voxels of volume Vb. When a spherical segmentation object SP1 intersects with the voxels of volume Vb, fewer voxels fit in the c' dimension than fit in the a' dimension. Because rectangular voxels cannot be represented as textures on a GPU (whether in 2D or 3D images), it is advantageous to work with cubic voxels for subsequent calculations. Such textures are always simply uniform grids of 2D or 3D values. This is shown as volume Vc in Figure 4C. Therefore, a segmentation object that appears spherical to the user must be treated as a sphere elongated inversely to the shape of the voxels, i.e., an ellipsoid. This can be achieved by using an inversely elongated ellipsoid E1, whose c-axis length is inversely proportional to the semi-axis c.

[0047] position(v x ,v y ,v z To determine whether a voxel at the center position (c x ,c y ,c z ) and semi-axial lengths (ax,ay,az) can be used.

number

[0048] Therefore, the voxel identifier module 101-12 of the computing device 101 is adapted to determine 1340 voxels of the label mask having positions inside the segmentation object based on the ratio of the distance between each voxel position in all three dimensions and the center position of the ellipsoid divided by the respective semi-axis lengths of the ellipsoid. Because the position and radius of the ellipsoid can be any real number, the system must operate with floating-point numbers, which creates a problem when performing such division on a GPU. However, even for integer values, the division is likely to produce a fraction. Floating-point numbers (floats) in CPU and GPU memory are represented by three integers: a sign, a mantissa, and an exponent.

[0049] Floating-point numbers (floats) in CPU and GPU memory are represented by three integers: a sign, a mantissa, and an exponent. Figure 5 shows an example of a single-precision (32-bit) floating-point number 500, as defined by the IEEE 754 standard for floating-point arithmetic. The 23-bit fractional part of the floating-point number 500 is stored in bits 0 through 22. The 8-bit exponent part is stored in bits 23 through 30, and the sign bit is stored in bit 31. The value of the floating-point number represented by the 32-bit floating-point number 500 is 0.15625. Because floating-point numbers have limited precision, problems arise because not all possible real numbers can be represented in 32 bits. As a result, some of the results of the F2 division described above are real numbers that cannot be accurately represented as floating-point numbers.

[0050] IEEE 754 requires exact rounding, i.e., the rounded result is the same as if the value were calculated using infinitely exact arithmetic and rounded to the nearest value representable as a floating-point number. Alternative rounding modes are specified by IEEE 754 in section 4.3. In GPUs, certain deviations from the standard are allowed by some graphics libraries, for example Microsoft's DirectX. This is mainly because GPUs are used primarily for video games and visual effects, where minor inaccuracies are not an issue and determinism is rarely required. Crucially, GPU manufacturers are permitted to select non-standard rounding modes and lower precision results for operations such as square root or division (see White, S., Coulter, D., Jacobs, M., Satran, M., "Floating-point rules (Direct3D 11)", Programming Guide for Direct3D 11, Microsoft, 2020, Accessed 23.11.2022, https: / / learn.microsoft.com / en-us / windows / win32 / direct3d11 / floating-point-rules). "IEEE 754 requires that floating-point operations produce a result that is the nearest representable value to the infinitely precise result, known as rounding to nearest even. Direct3D11 defines the same requirement as 32-bit floating-point operations producing a result within 0.5 least significant unit (ULP) of the infinitely precise result. This means, for example, that hardware is permitted to truncate the result to 32 bits, resulting in an error of up to 0.5 ULP, rather than performing rounding to nearest even. This rule applies only to addition, subtraction, and multiplication. sqrt and rcp have a tolerance of 1 ULP. The shader reciprocal and reciprocal square root instructions, rcp and rsq, have their own separate, relaxed precision requirements. Multiplication and division each operate at the 32-bit floating-point precision level (0.5 ULP precision for multiplication and 1.0 ULP precision for reciprocal).If x / y is performed directly, the results should be of greater or equal accuracy to the two-step method."

[0051] As a result of these allowable rounding deviations, if two connected computing devices use GPUs from different manufacturers, the devices may arrive at different label mask replication results, even though they started from the same initial state and executed the same label mask drawing commands (i.e., the same segmentation input data). In theory, different GPU models or series from the same manufacturer, or even the exact same GPU after a graphics driver update, may change behavior in the above situations, as this is left to the manufacturer's discretion.

[0052] This problem is visualized in Figures 6A and 6B. For simplicity, only the segmentation object and the 2D projection of each voxel are shown. Figure 6A illustrates a label mask 610 edited by a user on each computing device. The label mask is assumed to be empty (no signed voxels) before the user's editing command. The user positions the segmentation object SO1 so that its center CP1 is inside the voxel at position (6,5) in the label mask. Typically, the center CP1 does not coincide with the center of a voxel. The radius R1 of SO1 is indicated by a dashed line. For example, the GPU of the editing device complies with IEEE 754 and always rounds the results of floating-point operations to the nearest representable floating-point number. Voxels determined to be inside SO1 according to F2 (i.e., the center of each voxel is inside SO1) have a stippled texture. In this example, the voxels at positions (7,2) and (9,4) have center points CP11, CP12 near the surface of SO1, but the GPU of the editing device concludes that they are not inside SO1.

[0053] FIG. 6B illustrates a label mask 620 generated by a replica computing device with a GPU that uses a different rounding method. For example, the GPU of the editing device conforms to IEEE 754 and always rounds the results of floating-point operations to the nearest representable floating-point number. The GPU of the replica device may choose the permitted shortcut of truncating the result (always rounding down). A sphere SO2 is recreated based on the segmentation input data in the editing computing device, with position CP1=CP2 and radius R1=R2. However, because the GPU of the replica device calculates the distance to the center of the sphere for a given voxel slightly differently than the editing device, the GPU of the replica device concludes that the voxels at positions (7,2) and (9,4) have center points CP21 and CP22 that are inside the replicated sphere SO2. Therefore, these voxels are also labeled with the labels indicated in the segmentation input data (indicated by the stippled texture). Thus, to the user of the editing device and the replica device, there appears to be a difference in the label assignments in the label mask. Especially in medical applications, such deviations in the label mask of the replicating device, which was supposed to reflect the segmentation results of the editing device, are unacceptable.

[0054] Optionally, to detect such discrepancies between the label masks of different computing devices, a hash of the entire label mask may be calculated on each computing device and compared with the hash value at the computing device of the collaborative session host. If the hash values ​​differ, the session host may send the official version of the label mask to the connected computing device of the user with the out-of-sync hash value. However, this process may take several seconds, may result in data loss, and should preferably be avoided in real-time collaborative sessions.

[0055] To avoid such drawbacks, the approach disclosed herein provides a method and system that avoids generating different label masks on the replication computing device regardless of the GPU used. This is achieved by performing the division of formula F2 to determine whether a voxel is inside the ellipsoid by negating the exponent of each denominator using bitwise operations on the GPU of the connected computing device (specifically, the editing device 102 and the replication device 101 in the example of FIG. 1). This can be done by formula F3.

number

[0056] Finally, the update module 101-13 of the replicated computing device 101 is adapted to update 1360 the voxels determined in the replicated label mask 10 (i.e., the label mask generated by the replicated device 101 in response to the received segmentation input data 21) according to the label identifiers of the received segmentation input data 21.

[0057] Figure 2B shows the reciprocal of A and B, B, according to formula F3, where the exponent is stored in the 8 bits following the sign bit of a 32-bit floating point number with a bias of "127" (see Figure 5). -113 shows substeps of determining step 1340 detailing an example of implementing a bitwise division operation for the division A / B by multiplying 1342 the 32-bit floating-point number as an integer without changing its binary representation. In the example implementation, the interpreted integer is subtracted 1344 from the hexadecimal number 0x7F000000 (corresponding to the integer value "127" shifted into the 8-bit position that stores the exponent), and the result of the subtraction is reinterpreted 1346 as a floating-point number to obtain an approximation of the reciprocal of the original floating-point number (with the exponent negated in this implementation).

[0058] Returning to FIG. 1 , the segmentation input data 21 may further include an update mode associated with the segmentation object during editing 2-1 of the label mask 20 on the computing device 102 (i.e., the editing device). When using a spherical segmentation object, the user 2 can select a segmentation mode that determines how voxels that fall inside the spherical segmentation object are labeled. From the perspective of the replication device, the segmentation mode is applied when updating the corresponding replicated label mask. Therefore, when a segmentation mode is received as part of the segmentation input data, it is also referred to as an update mode. That is, the selected segmentation (update) mode becomes part of the segmentation input data 21 that is subsequently provided by the editing device 102 to connected devices. The following list provides examples of possible update modes (although this list is not intended to be limiting, and those skilled in the art may define additional update modes): Label setting mode: A mode in which determined voxels in the replicated label mask are set to the label identifiers of the segmentation input data. Label Unset Mode: A mode that removes specific previously set label identifiers from determined voxels in the cloned label mask. Label clearing mode: Resets all label identifiers of the determined voxels in the cloned label mask (resetting label identifiers means setting the label values ​​to their initial values, e.g., "0"). Labeling mode for unassigned voxels: A mode that assigns label identifiers of segmentation input data in a replicated label mask only to determined voxels that have not yet been labeled. Label Visible Voxels Mode: This mode assigns label identifiers from the segmentation input data in the replicated label mask only to voxels that are determined to be visible according to the applied transfer function.

[0059] The label identifiers in the label mask may typically be stored as 8-bit, 16-bit, or 32-bit values ​​for each voxel. Larger bit sizes are possible by using multiple texture channels and / or multiple textures. The label values ​​may be interpreted in various ways. In one implementation, the bits of the label identifier in the label mask are interpreted as a single integer label value for each voxel. That is, the label values ​​may cover a large value range, but only a single label can exist for each voxel. In another implementation, each bit of the label identifier may be interpreted as a label. That is, as many labels as there are bits in the label identifier may be assigned to a voxel.

[0060] FIG. 7 illustrates an example of segmentation results in a medical application where segmentation is applied to the vertebrae of a human skeleton 700. Each vertebra 700-1 through 700-n is segmented with a distinct segmentation color, such that adjacent vertebrae are assigned different segmentation colors. That is, each voxel in the label mask is assigned a label indicator that is associated with the color value associated with the segmentation object during each editing activity. When replicating a label mask based on an editing command for a spherical segmentation object according to the approach disclosed herein using a bitwise division operation, the exact label mask is reproduced on each connected replica device.

[0061] FIG. 8 shows a photograph of a real-world collaborative session 800 with four users 800-1 through 800-4 and four connected computing devices 800-11 through 800-14. In this example, the collaborative session is part of a neurosurgery course, with surgeon 800-3 and three students 800-1, 800-2, and 800-4 performing virtual surgery within a shared virtual environment. The surgeon is using a spherical segmentation object in eraser mode to remove a portion of bone in a patient's CT scan. The eraser mode may be implemented by using the segmentation object's label setting mode in combination with a label that is assigned a fully transparent color value. This operation is then synchronized over the network to the students' virtual reality devices, so that the students can view (from their perspective) the changes (edits) applied to the label mask by the surgeon.

Claims

1. A computer-implemented method (1000) for replicating a three-dimensional label mask (20) of a three-dimensional volumetric data set (190) in a network (100) of computing devices (101-10n), comprising: When a first computing device (101) joins a collaborative session on the network (100), initializing (1100) the first computing device (101) with the entire current label mask dataset and the three-dimensional volume dataset (190); receiving (1200) at the first computing device (101) a set of segmentation input data (21) generated by a second computing device (102), a particular segmentation input data comprising current position data, size data, and a label identifier associated with a spherical segmentation object (102-1) used by the second computing device (102) to interactively edit the label mask; For each of said set of segmentation input data: Computing (1320) each ellipsoid corresponding to the spherical segmentation object (102-1) stretched inversely proportional to the shape of the voxels in the label mask; determining (1340) voxels (vi) of the label mask having positions inside the segmentation object based on a ratio obtained by dividing the distance between each voxel position in all three dimensions and a center position of the ellipsoid by each semi-axis length of the ellipsoid as the denominator, wherein each semi-axis length is a floating-point number expressed by integers with respect to sign, mantissa, and exponent, and the division is performed on a graphics processing unit of the first computing device (101) by approximating the multiplicative inverse of each denominator by negating the exponent of each semi-axis length using bitwise arithmetic, and multiplying the approximated multiplicative inverse of each denominator by the respective numerator; updating (1360) the determined voxels in the replicated label mask (10) according to the label identifiers of the segmentation input data (21); replicating (1300) the edited label mask of the second computing device (102) associated with the set of segmentation input data in the first computing device (101) by A method for providing the above.

2. The bitwise division operation is B, which is the reciprocal of A and B. －１ The division A / B is performed by multiplying by an approximation of A / B, which is calculated by subtracting B, interpreted as an integer, from a predetermined integer constant, i.e. a compiler of the first computing device is instructed to interpret (1342) 32-bit floating-point numbers as integers without changing their binary representation; the resulting integer is subtracted (1344) from the predetermined integer constant, and by exploiting the standardized encoding format of floating-point numbers, in particular the position of the exponent and fraction in the binary representation, the result of the integer subtraction approximates the reciprocal of the floating-point number; 2. The method of claim 1, wherein the result of the subtraction is reinterpreted (1346) as a floating-point number to obtain an approximation of the reciprocal of the original floating-point number.

3. The method of claim 1 or 2, wherein the collaborative session is performed within a medical application.

4. 4. The method according to claim 1, wherein the first computing device (101) receives, together with the segmentation input data (21), a hash value of the corresponding edited label mask (20) of the second computing device (102), and further calculates a hash value of each of the duplicated label masks (10) to ensure accuracy of duplication of the label masks between the computing devices.

5. 5. The method of claim 1, wherein updating is performed using at least a label setting mode that sets the determined voxels in the replicated label mask to the label identifiers of the segmentation input data, and a label unsetting mode that removes certain previously set label identifiers from the determined voxels in the replicated label mask.

6. 6. The method of claim 5, wherein updating is performed using one of the following update modes: a label clearing mode that resets all label identifiers of the determined voxels in the replicated label mask; a label setting to unassigned voxels mode that sets the label identifiers of the segmentation input data in the replicated label mask only to determined voxels that have not yet been labeled; and a label setting to visible voxels mode that sets the label identifiers of the segmentation input data in the replicated label mask only to determined voxels that are visible according to an applied transfer function.

7. The method of any of claims 1 to 6, wherein for each voxel of the label mask, the label identifier of a single label is stored as an 8-bit, 16-bit, or 32-bit value.

8. 8. The method of claim 7, wherein for each voxel of the label mask, an 8-bit, 16-bit, 32-bit, or longer bit field is stored, each bit corresponding to a label, thereby allowing multiple labels to be set for each voxel.

9. 10. A computer program product for replicating a three-dimensional label mask (20) of a three-dimensional volumetric data set (190) in a network (100) of computing devices (101-10n), the computer program product comprising computer readable instructions that, when loaded into a memory of a computing device and executed by at least one processor of said computing device, cause said computing device to perform a method according to any of claims 1 to 8.

10. A computing device (101) for replicating a three-dimensional label mask (20) of a three-dimensional volume data set (190) in a network (100) of computing devices, comprising: an interface (110) adapted to receive, upon joining a collaborative session on the network (100) to initialize the computing device (101), a current label mask dataset and the entire three-dimensional volume dataset (190) from the network of computing devices, and further adapted to receive a set of segmentation input data (21) generated by a further computing device (102) of the network describing an edit (2-1) of the label mask (20) at the further computing device (102), wherein a particular segmentation input data comprises current position data, size data, and a label identifier associated with a spherical segmentation object (102-1) used by the second computing device (102) to interactively edit the label mask; Each of the set of segmentation input data an ellipsoid module (101-11) adapted to calculate a respective ellipsoid corresponding to said spherical segmentation object (102-1) stretched inversely proportional to the shape of the voxels in said label mask; a voxel identifier module (101-12) adapted to determine voxels (vi) of the label mask having a position inside the segmentation object based on a ratio obtained by dividing a distance between each voxel position in all three dimensions and a center position of the ellipsoid by a respective semi-axis length of the ellipsoid as a denominator, wherein each semi-axis length is a floating-point number expressed by an integer with respect to a sign, a mantissa, and an exponent, and the division is performed on a graphics processing unit of the computing device (101) by approximating a multiplicative inverse of each denominator by negating the exponent of each semi-axis length using bitwise arithmetic, and multiplying the approximated multiplicative inverse of each denominator by the respective numerator; and an update module (101-13) adapted to update the determined voxels in the replicated label mask (10) according to the label identifiers of the segmentation input data (21); a replication module (101-10) adapted to replicate the edited label mask in the further computing device (102) associated with the set of segmentation input data by processing the edited label mask in the further computing device (102) 1. A computing device comprising:

11. The voxel identifier is B, which is the reciprocal of A and B. －１ and an approximation of B, where B is interpreted as an integer and the approximation is calculated by subtracting B from a predetermined integer constant, the predetermined integer constant being predetermined by exploiting a standardized encoding format for floating-point numbers, in particular the position of the exponent and the fraction in a binary representation, such that the result of the integer subtraction approximates the reciprocal of the floating-point numbers, i.e. a compiler for the computing device is instructed to interpret 32-bit floating-point numbers as integers without modifying the binary representation; The resulting integer is subtracted from the predetermined integer constant; The device of claim 10 , wherein the result of the subtraction is reinterpreted as a floating-point number to provide an approximation of the reciprocal of the original floating-point number.

12. The device of claim 10 or 11, wherein the collaborative session is a session performed within a medical application.

13. The device according to any of claims 10 to 12, wherein the computing device (101) is further adapted to receive, together with the segmentation input data (21), a hash value of the corresponding edited label mask (20) of the further computing device (102) and to calculate a hash value of the respective duplicated label mask (10) to ensure accuracy of the duplication of the label mask between the two computing devices.

14. 14. The device of claim 10, wherein the update module is further adapted to support any one of a plurality of update modes, comprising: a label set mode that sets the determined voxels in the replicated label mask to the label identifiers of the segmentation input data; a label unset mode that removes certain previously set label identifiers from the determined voxels in the replicated label mask; a label clear mode that resets all label identifiers of the determined voxels in the replicated label mask; a label set to unassigned voxels mode that sets the label identifiers of the segmentation input data in the replicated label mask only to determined voxels that have not yet been labeled; and a label set to visible voxels mode that sets the label identifiers of the segmentation input data in the replicated label mask only to determined voxels that are visible according to an applied transfer function.

15. 15. The device of claim 10, wherein the bits of the voxel values ​​in the label mask represent a single integer label value for each voxel, or wherein each bit of the voxel values ​​in the label mask corresponds to a distinct label of the corresponding voxel.

Images