Surface Segmentation (Supp 132): How to store "Point Index List"

[Jörg Illmann]

Hi Group,

I have a question on how to create a Surface Segmentation Storage
(SopClassUid 1.2.840.10008.5.1.4.1.1.66.5).

The Surface Mesh Primitives Macro (see Dicom Standard PS 3.3-2011, C.
27.4) contains Point Index Lists, fe. Triangle Point Index List
(0066,0023). The value representation in PS 3.6-2001 is given as OW
(Other Word). From the value representation OW, I do not know how many
bits are used to represent each point index in the list. I assume that
16 bits shall be used (but I did not find it in the standard, it might
even be 32 bits if Point Coordinates Data (0066,0016) contains more
than 65535 points).

Did I miss something? In case of Lookup Tables a descriptor specifies
how many bits are used (fe. (0028,1101) Red Palette Color Lookup Table
Descriptor specifies how the data in (0028,1201) Red Palette Color
Lookup Table Data is encoded).

best regards

[David Clunie]

Hi Jörg

I too assume these are meant to be interpreted as 16 bit unsigned integers,
which then imposes size limits as you point out.

It should definitely be made explicit, so I will submit a CP.

These limits should also be discussed.

David

[David_F]

Hello,

currently, i am implementing a class storing surfaces to DICOM by using the Surface Segmentation IOD. The amount of points I am dealing with heavily exceeds the amount of 65535 points.
Since "(0066,0029) Primitive Point Index List" has a VR of OW, which means 16 bit unsigned integers, I can't reference points beyond the index of 65535 in "(0066,0016) Point Coordinates Data" (where the actual coordinates are stored).

Would it be possible resp. would it make sense to add to Table C.27-4 in PS 3.3 - 2011 additionally to the already existing attribute "(0066,0029) Primitive Point Index List" another attribute like "Primitive Point Long Index List" with a VM of 1-N (N=Number Of Surface points) and a VR of UL (unsigned long)? Like that 4 bytes could be used for index storing.

Or is there another solution for my use case?

Kind regards,
David

[David Clunie]

Hi David

When we discussed Jörg Illmann's original question that lead to
CP 1198, the conclusion was that regardless of the reason for
the choice of OW, we should not change the VR from OW to UL,
since that would break any existing implementations, assuming
there were any.

One of the suggestions at the time, from Michael Gessat, was
that if there ever was a need to send a larger number than
would fit, one could split the surface into "patches", and encode
multiple such patches as multiple surfaces in the same instance.

As he said, "that sucks", but it might be sufficient for your use
case, since adding a new attribute as an alternative to Primitive
Point Index List would take time, and would raise the question of
what receiving applications that didn't know about it would do.

I don't think anyone has thought this through in detail, but if
you wanted to convey the notion that each of these patches was then
part of the same surface (as opposed to a different surface in
the same instance), you could use the same Surface Number in
multiple items of Surface Sequence (the definition says that
the number uniquely identifies the same surface, not that it
has to be different for every sequence item, though this was
perhaps not considered at the time, and considering all the
other attributes in the Surface Sequence items, was not what
was intended).

Or if you didn't need to convey the notion that the "patches"
were related, you could just label them as different (numbered)
surfaces.

David

PS. Have you looked at the Surface Scan Point Cloud object in
Sup 154? I am not sure what your use case is that gives rise
to the large number of points, and that object doesn't need
the (limited number of) indices. Maybe we need a generic
"point cloud" objects that is not related to surfaces and is
not restricted to optical surface scanners.