BRIEF DESCRIPTION OF THE DRAWINGS
The present invention will now be described in more detail, by way of example, with reference to the accompanying drawings, wherein:
FIG. 1 illustrates a conventional method for storing 3D images;
FIG. 2 and FIG. 3 illustrate a method of the invention;
FIG. 4 show pixels that belong to an overlap between adjacent stripes according to the invention;
FIG. 5 is a memory of the invention; and,
FIG. 6 is a picture of the invention.
Throughout the drawing, the same reference numeral refers to the same element, or an element that performs substantially the same function.
DETAILED DESCRIPTION
The invention relates to a way of storing 3D images that optimizes visualization and processing. Although the invention is particularly advantageous in the medical domain, its features are generic enough so that it can be applied to any sort of video application. The invention is based on the concept that 3D images can be represented as a stack of 2D slices. Each 2D slice is treated as a conventional 2D image and is basically composed of an array of columns and rows of pixel data. Pixel data can be colour values, luminance or chrominance values, opacity or reflectivity values depending on the video application and the designer's choice. Each 2D image can be thus graphically represented by a two-dimensional array of points, each point representing a pixel.
FIG. 1 shows 2D slices 102, 104 and 106 of a 3D image 100. 2D image 102 is represented in the drawing by a square array having six rows of pixel data. Conventionally, pixel data is stored in memory in series, row after row, starting with the pixel data in the upper left corner. For example, segment 108 of pixel data is stored in a first memory area, segment 110 is stored in an adjacent second memory area or in a next memory block, and so on until the last segment. A disadvantage of this embodiment is the discontinuities in the storage of a pixel and its upper and lower neighbours pixels. Indeed, adjacent pixels, especially in the vertical direction, will most certainly be stored in distinct and non-contiguous memory locations and different cachelines will be called upon when these pixels need to be retrieved.
FIG. 2 and FIG. 3 illustrate some basic characteristics of the invention. Picture 102 is represented in the form of an array 114 of pixels positioned at regular intervals in the X and Y directions. In this exemplary embodiment, the array of pixels 114 is partitioned into a finite number of vertical overlapping stripes. Adjacent first and second stripes 116 and 118 are shown. Contrary to the embodiment shown in FIG. 1, pixels are stored in memory, stripe by stripe, which means that all pixels of a given stripe are stored together in a memory area. Stripe 116 may be stored first, starting with its pixel in the top left corner and adjacent stripe 118 is stored thereafter. The top left corner pixel of stripe 118 may be stored in a memory location adjacent to where the bottom right pixel of stripe 116 (pixel of stripe 116 stored last) was stored.
Stripe 116 is stored as follows. The pixel in the top left corner of stripe 116 is stored first and pixels are subsequently stored in series going right and down through stripe 116. Stripe 118 is stored in a similar fashion. In this embodiment, stripes 116 and 118 have the same width being a fraction of a cacheline of the memory. Segment 150 and 152 are cachelines stored in memory.
Additionally, as seen in FIG. 2, stripes 116 and 118 have an overlap 120 of two pixels, which means that pixel data in area 120 is redundant in memory. The choice of the number of overlapping pixels is arbitrary and may be selected to best fit implementation designs and memory load. Although it results in an overhead, data in overlap 120 is advantageously used for algorithms that require information on surrounding pixels. Indeed, the resulting data redundancy facilitates the performance of linear and cubic interpolations, for example, because information on the adjacent pixels is required to compute interpolation results. This is explained in more details with reference to FIG. 4.
FIG. 4 shows the last few pixels of the first row of stripe 116 and the first few pixels of the first row of stripe 118. As mentioned in a previous paragraph with respect to U.S. Pat. No. 6,028,612 if pixel data is stored in non-overlapping stripes, interpolation of the pixels at the edges requires access to the adjacent stripe, and thus access to different cachelines, memory areas or even different memory entities. Such implementation unduly restrains the process performance. In the invention where stripes overlap, an additional restriction may be put on the algorithm on which pixels in the overlap to process. In this embodiment, the interpolation algorithm will be restricted to process stripe pixels located within a portion of the overlap only and the algorithm will not process, and thus interpolate, pixels located outside the allowed overlap portion. For example, in reference to FIG. 4, when processing stripe 116, the interpolation algorithm is set up to only interpolate a pixel value for pixel 122 and the algorithm will not compute any interpolated value for pixel 124. Assuming that the interpolation algorithm only requires the pixel values of the closest pixels, the algorithm can easily compute a result for pixel 122 without requesting any additional cacheline. Similarly, when processing stripe 118, the interpolation algorithm is set up to compute an interpolation result for pixel 124 only. The edge pixels of each stripe 116 and 118 are ignored during processing of the stripe and since the information is redundant, the same edge pixels will be present in the adjacent stripe as non-edge pixels and thus still be processed in the end. This embodiment prevents unnecessary calls for cachelines that burden data links and consume bandwidth. The above is only given as an exemplary embodiment and any size of overlap may be chosen that satisfies the algorithm process. In a similar fashion, the width of the stripes 116 and 118 is selected to optimize the number of cacheline access during runtime. Stripes 116 and 118 may have different widths if needed.
FIG. 5 illustrates an exemplary embodiment of the invention where memory addresses are assigned efficiently. FIG. 5 shows upper left corner pixel 130, and adjacent pixels 132-136 of 2D slice 102 and upper left corner pixel 138 of the next 2D slice 104 forming 3D image 100. FIG. 5 also includes a block unit representing internal organization of memory 140. Memory 140 is represented as a two-column table with memory addresses in the left column and data pixels in the right column. As shown, data associated with pixel 130 is stored at memory address 0, pixel 132 at address 1, pixel 134 at address X0, pixel 136 at address 2X0 and pixel 138 at address Y0. As explained above, pixels located in the same row are stored in series in memory 140 and first pixels of each row are stored in memory next to the last pixel of the preceding row. In this implementation, a constant address offset, namely X0, is introduced between a pixel and the pixel beneath it in the 2D slice. Pixels 130, 134 and 136 are therefore stored in memory 140 at addresses 0, X0 and 2X0, respectively. Pixel 142 located beneath pixel 132 is also stored in memory 140 at the address 1+X0. A similar address offset Y0 is introduced between pixels of slice 102 and pixels of slice 104. Indeed, pixel 130 and 138 are stored in memory 140 at respective addresses 0 and Y0. The introduced constant offsets allow a quick retrieval of pixel data related to neighboring pixels.
The proposed stripe-based storage method imposes a condition on the stripe width but leaves open the thickness and the height of the stripes. This freedom in the choice of the two remaining dimensions allows great flexibility during processing and virtual block building. In FIG. 6, image 102 includes contour 142 of a body organ. Contour 142 is the intersection with the plane of image 102 of the organ outer surface or shell. In order to process pixel data forming the contour 142, 2D virtual blocks, 114, 146 and 148 that include the whole contour 142 may be computed. The X dimension of virtual blocks 144, 146, 148 is the same as the width of the stripes 116, 188 and the Y dimension is left to the designer's choice. The Y dimensions of the blocks may be chosen to cover the stripe portion that includes the intersection of the contour and the stripe. Resulting virtual blocks 144-148 as seen in FIG. 6 are obtained.
It must be noted that 3D virtual blocks may also be built to cover the 3D shell of the body organ. To this end, a thickness in the Z direction is computed for blocks 144, 146 and 148. Compared with a traditional block-based storage implementation where fixed-size blocks are stored in memory, the invention permits greater flexibility and speeds up processes. Such implementation is particularly suited for medical applications where body surfaces or shells need be processed and visualized.
Moreover, although the disclosed storage architecture is based on cachelines, other storage arrangements are also well suited to the implement the invention. And other it may be more advantageous in view of the memory architecture to modify the width of the stripes which may be greater than a cacheline or other memory transfer entity.
Attention is also brought to the fact that the invention the slicing of the 3D array of pixels into 2D arrays is only given as an exemplary embodiment and the invention is first directed to 3D arrays of information data samples representative of physical data, radiation data, measurements results associated with voxels. Obviously, stripes may have a thickness of one or more information data samples.
The foregoing merely illustrates the principles of the invention. It will thus be appreciated that those skilled in the art will be able to devise various arrangements which, although not explicitly described or shown herein, embody the principles of the invention and are thus within the spirit and scope of the following claims.
In interpreting these claims, it should be understood that:
a) the word “comprising” does not exclude the presence of other elements or acts than those listed in a given claim;
b) the word “a” or “an” preceding an element does not exclude the presence of a plurality of such elements;
c) any reference signs in the claims do not limit their scope;
d) several “means” may be represented by the same item or hardware or software implemented structure or function;
e) each of the disclosed elements may be comprised of hardware portions (e.g., including discrete and integrated electronic circuitry), software portions (e.g., computer programming), and any combination thereof;
f) hardware portions may be comprised of one or both of analog and digital portions;
g) any of the disclosed devices or portions thereof may be combined together or separated into further portions unless specifically stated otherwise; and
h) no specific sequence of acts is intended to be required unless specifically indicated.
Patent Application
20080094406
