Can't send data with odd PixelData lenght

Hello,
I’m using Orthanc for the storage of some DICOM studies together with their segmentations and secondary capture images. The segmentations are created by a python library called pydicom-seg and I recently found out that sometimes the dicom output has an odd value in the lenght of the PixelData field (element (7fe0,0010)). For the DICOM communication with Orthanc I’m using the pynetdicom library, with a function I wrote myself which worked good with every file till now. When sending the odd PixelData files to Orthanc, the transfer fails because it receives an fragment with odd lenght and it aborts the association. I tried debugging using DCMTK’s storescp service and I found out that replacing the transfer syntax from Explicit VR Little Endian to Deflated Explicit VR Little Endian resolved the issue, by the way when testing this approach with my Orthanc instance, i get an error saying that such transfer syntax is unsupported (even if “DeflatedTransferSyntaxAccepted” is set to true in the json config file). How could I resolve this? I’m not finding any solution online.
For information: I’m running orthanc 1.9.7 in a docker container, I’ll leave here the errors

E0130 10:44:25.779967 StoreScp.cpp:272] Store SCP Failed: DIMSE: Odd Fragment Length: 4857 this is the error showed in the Orthanc docker log when trying to send the file with Explicit VR Little Endian.
(When using deflated, it won’t show anything in the log. I locally built a docker image and running it with --verbose showed me the “unsupported syntax” error).

def dimse_send(path_dcm_file, remoteAddress=‘’, remotePort=104, remoteAET=‘ANY-SCP’, task_name=‘PYNETDICOM’, SC=False):
LocalAE = AE(ae_title=task_name)
if isinstance(path_dcm_file, str):
dcm = dcmread(path_dcm_file)
else:
dcm=path_dcm_file #if it’s not a path then it must be a dicom dataset
if SC==False:
meta=dcm.file_meta
uid=‘’.join(meta[(0x0002,0x0002)]) #SOP Class UID
transfer_syntax=‘’.join(meta[(0x0002,0x0010)]) #dicomFile Transfer Syntax UID as string
if len(dcm[(0x7fe0,0x0010)].value)%2 != 0:
print(‘pixel data with odd lenght - using Deflated Explicit VR transfer syntax’)
transfer_syntax= ‘1.2.840.10008.1.2.1.99’
else:
uid=dcm.SOPClassUID
transfer_syntax=dcm.file_meta.TransferSyntaxUID
if len(dcm[(0x7fe0,0x0010)].value)%2 != 0:
print(‘pixel data with odd lenght - using Deflated Explicit VR transfer syntax’)
transfer_syntax= ‘1.2.840.10008.1.2.1.99’
print(‘dimse UID : {}’.format(uid))
print(‘dimse transfer_syntax : {}’.format(transfer_syntax))
LocalAE.requested_contexts=[build_context(uid,transfer_syntax), build_context(uid,‘1.2.840.10008.1.2.1.99’)] #Presentation context
assoc = LocalAE.associate(remoteAddress, remotePort, ae_title=remoteAET) #association between local and remote AE
if assoc.is_established:
# Association established
print(“DIMSE: Association established with REMOTE SCP!”)
status = assoc.send_c_store(dcm) #C-Store request with dicomFile attached
assoc.release()
if status:
if(‘{0:04x}’.format(status.Status)==‘0000’): #Check if C-Store method run without errors (status=0x0000)
print(‘DIMSE: C-Store message sent successfully to REMOTE SCP!’)
else:
print(‘No response received from Remote AE (timeout)’)
else:
# Association rejected, aborted or never connected
print(“DIMSE: Failed to associate”)

This is the python function used for the data send.

As for as the odd length for the PixelData field (element (7fe0,0010)) is concerned, I think the byte length needs to be even, like for other VR fields in DICOM, see:

https://dicom.nema.org/medical/Dicom/2016e/output/chtml/part05/chapter_8.html

“Also, the Value Field containing Pixel Data, like all other Value Fields in DICOM, shall be an even number of bytes in length. This means that the Value Field may need to be padded with data that is not part of the image and shall not be considered significant. If needed, the padding bits shall be appended to the end of the Value Field, and shall be used only to extend the data to the next even byte increment of length.”

Not sure you are padding that or not ? That might be one issue, but the other with the transfer syntax sounds like another ?

Also, not sure it would work, but you could probably use the Orthanc Python Plug-in to ‘edit’ that tag on ingress to check the byte length and pad accordingly.

See: https://book.orthanc-server.com/plugins/python.html?highlight=python#modifying-received-instances-new-in-4-0

Stephen D. Scotti