Cannot read properties of undefined (reading 'byteLength')

[junxiant]

Hello,

I am trying to run MonaiLabel segmentation on a CT scan, but I encountered this error.

Server logs seems fine as there are no errors here.

Could this be a dicom header issue?

[tangy5]

Hi @junxiant , thanks for reporting the issue. We haven't see the error before, which viewer are you using, 3D Slicer?

[junxiant]

I'm using OHIF-XNAT viewer,

OHIF-XNAT viewer = 3.4.1 monai = 1.1.0 monailabel = 0.6.0

[tangy5]

Hi @AHarouni, could you help and share some experience a little here? The OHIF and XNAT integration is a new stuff right? Thank you!

[junxiant]

I managed to narrow it down to this Tag which causes this issue: (0020,0037) ImageOrientationPatient,

by changing the value using pydicom,

import pydicom

ds = pydicom.dcmread('file1.dcm')

print("Orientation", ds.ImageOrientationPatient)
ds.ImageOrientationPatient = [round(x) for x in ds.ImageOrientationPatient]
print("Orientation", ds.ImageOrientationPatient)

ds.save_as('file1_fix.dcm', write_like_original=False)

Outputs:

For Coronal: ['1', '0', '0', '0', '0', '-1']

For Sagittal: ['0', '1', '0', '0', '0', '-1']

For Axial: ['1', '0', '0', '0', '1', '0']

I'm assuming these values are to be rounded otherwise it will throw the byteLength error

On OHIF-XNAT viewer, Working:

Gives 'byteLength' error

[lassoan]

ImageOrientationPatient and ImagePositionPatient are required values. The values are not rounded.

If they are not present then the images are corrupted and should probably not be used.

Where do these images come from? Are they actual CTs or just secondary captures (screenshots)?

[junxiant]

How do i differentiate if its actual CT or just screenshots? These are all in .dcm format.

Also, changing the ImageOrientationPatient doesn't entirely work. It worked for a Plain Fine Axial scan but not on a Bone Fine Axial scan

[lassoan]

How do i differentiate if its actual CT or just screenshots? These are all in .dcm format.

Hard to tell a single tag. SC modality defines it clearly but often reprocessed images don't use this modality. It may also be an incorrectly anonymized data set. Can you provide a download link to the image?

[AHarouni]

Hi @tangy5 I have been helping @junxiant with the Xnat - monai label integration. It works fine now. This seems like a dicom issue, orthanc and xnat manage to read dicoms that don't comply with all dicom standards.

@junxiant:

• I think I faced a similar orientation issue before. In my case rounding to 2 or 3 decimal places avoided that error. please try changing your code to keep just 2 decimal places as the orientation is a float number.
• If not could you clarify, where did you get this dicom ? may it it was damaged when anonymized.
• It could be an issue when converting the nifti inference to dicom seg. @junxiant could you take the changes to the xnat datastore, run batch inference on this patient and store the nifti and dicom-seg to disk. That way you could narrow down the issue

[lassoan]

Rounding to 2 decimals would ruin the image (it could introduce several mm errors), so I would not recommend it even as a workaround. Rounding to 7 should be sufficient.

[junxiant]

Rounding the values to 2 decimal places or 7 did not work, error still pops up after inference.

The dicom file i'm working on is confidential so i don't think i am able to share that. But i have a public available dataset which i have converted from .nii format to .dcm format, and I was able to recreate the error just by changing the ImageOrientationPatient value.

Here is the public dataset which is in .nii format.

I have extracted out one slice (1 .dcm file), with ImageOrientationPatient of 1\0\0\0\1\0 which works fine Original_1.zip

and modified it to the values which were giving the error 0.99366-0.08474-0.07381\0.07984\0.99455-0.06702 Changed_Orientation_1.zip

unless this is the wrong way and i should not just change the values just like that?

I'll look into the nifti inference to dicom seg part

[lassoan]

This image slice gets loaded into Slicer-5.2.2. The only problem that I saw with this image slice is that the two axes are not orthogonal (dot product is not zero), which Slicer reports as a warning (Irregular volume geometry detected, but maximum error is within tolerance (maximum error of 0.000981303 mm, tolerance threshold is 0.001 mm)):

>>> 
import numpy as np
x = np.array([0.99366, -0.08474, -0.07381])
y = np.array([0.07984, 0.99455, -0.06702])
print(np.cross(x,y))
[0.07908701 0.0607021  0.99501019]
>>> print(np.dot(x,y))
2.393599999992238e-06

You can orthogonalize the two vectors to fix this. If you want to load a 3D image (multiple slices) then you also need to make sure that the image position patient increments are consistent with the direction vectors.

Overall, a potential explanation for the root cause of the issue is that the images were corrupted because someone at some point thought that rounding to 5 decimals is fine. It is not. Especially for the orientation.

[junxiant]

Unfortunately I am back with this issue again. I am using OHIF-XNAT Viewer==3.5.1. This time, when I opened the console, it displayed this error:

Rounding the ImagePositionPatient or setting ImageOrientationPatient doesn't seem to be the full solution.

When I tried to open the dicom file on 3D Slicer, this warning popped up:

However, inference runs just fine, no errors on server's logs and the output segmentation displays just fine on 3D Slicer.

A working scan which works on the OHIF-XNAT Viewer (Segmentation output displays with no errors), when loaded onto the 3D Slicer, also displayed this warning, but the output segmentation displays just fine on 3D Slicer.

Could it possibly be something wrong with the segmentation output which cant be displayed on the OHIF-XNAT Viewer?

[AHarouni]

Hi @junxiant

Are these real dicom images from pacs/ scanners or they are converted diocms using some tools ? I suggest you try multiple dicom files and narrow down similarities of the ones which gives errors.

This seems to be either an issue with the dicom segmentation object generated by monai label or an issue with xnat viewer not supporting this orientation, Monai label generates nifti file out of the inference then it is converted using external libs to dicom seg. Could you check the patient orientation for the original image and the one from the nifti file ? then the dicom seg sent over

Most prob the nifit file is automatically deleted by monai label so you should add a save nifti transform to your inference as below to keep a copy.

SaveImaged(keys=["pred"], resample=False, separate_folder=False, output_dir='your debug subdir')

if you think this is a viewer issue with xnat you should get the browser console logs / errors and open an issue on xnat viewer repo https://bitbucket.org/icrimaginginformatics/ohif-viewer-xnat-plugin/issues?status=new&status=open.

[junxiant]

Hello @AHarouni,

Working dicom images are taken from the CQ500 dataset. Non-working dicom images are from pacs and has been anonymized.

I have exported segmentation nifti files from inference for both working and not working scans, and both was viewable on ITK-Snap.

Taking a look at the nifti output file's info from the working dicom images: Info:

Metadata:

Nifti output files's info from non-working dicom images: Info:

Metadata:

A difference I noticed is the Orientation, which is "Oblique (closest to RAI)".

I have opened an issue on ohif-viewer repo here: https://bitbucket.org/icrimaginginformatics/ohif-viewer-xnat-plugin/issues/49/segmentations-oblique-to-the-acquisition

Meanwhile, this is the ImagePositionPatient and ImageOrientationPatient of working dicom files:

And for the non-working dicom files: I'll try to see if there is any other metadata i can change to make it work on ohif-viewer

thank you :-)

[junxiant]

I have uploaded the failed dicom file in a zip folder here The segmentation output in nifti format here The segmentation output in dcm format converted through 3D Slicer here

This is CQ296 converted into dicom files using 3D Slicer export here

[junxiant]

Oh v3-demo.ohif.org , I was able to load the seg file:

I think this should confirm that the issue is on the ohif-xnat viewer plugin