We have a Brainlab system that can send empty images when different images in the hierarchy are not fused properly. When that happens it sends the header but m_BodySizeToRead becomes 0 and so it does not send any more data. Then AllocatePack()/AllocateBuffer() will think we are actually sending an image instead of receiving and thus sets the message to 130 (IGTL_HEADER_SIZE + IGTL_IMAGE_HEADER_SIZE)
The example code given on line 66 of the file igtlMessageHeader.h will then hang waiting for data that is never send from the Brainlab system. This is because the code uses GetPackBodySize() to get the data size, which is 72. To remedy this one should first check that GetBodySizeToRead() > 0 before trying executing the code on line 66.
I know this is a niche case and would not occur if the brainlab system would not report empty images as available. But that is out of our control. I don't know if this can be patched in the library but it might be worth modifying the example code to warn for this.
We have a Brainlab system that can send empty images when different images in the hierarchy are not fused properly. When that happens it sends the header but m_BodySizeToRead becomes 0 and so it does not send any more data. Then AllocatePack()/AllocateBuffer() will think we are actually sending an image instead of receiving and thus sets the message to 130 (IGTL_HEADER_SIZE + IGTL_IMAGE_HEADER_SIZE) The example code given on line 66 of the file igtlMessageHeader.h will then hang waiting for data that is never send from the Brainlab system. This is because the code uses GetPackBodySize() to get the data size, which is 72. To remedy this one should first check that GetBodySizeToRead() > 0 before trying executing the code on line 66.
I know this is a niche case and would not occur if the brainlab system would not report empty images as available. But that is out of our control. I don't know if this can be patched in the library but it might be worth modifying the example code to warn for this.