-
Notifications
You must be signed in to change notification settings - Fork 638
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DicomJsonConverter throws for non-DicomElements #1792
Comments
Thank you for reporting this bug! |
@mrbean-bremen I am struggling with this, maybe you could help me with your knowledge from pydicom? How does pydicom handle this? What is the json result, when serializing the file "CT1_J2KI" from fo-dicom.Tests/TestData? |
Interesting question - I have to admit that I haven't thought about this. My understanding so far was that each tag (including PixelData, even if it is encapsulated) is encoded as one single base64 encoded value. Admittedly, the cases I have heard of in practice have not used The standard only says:
It says nothing about encapsulated data, at least as far as I can see. As far as I know, |
Sure, I will be able to serialize the fragmented data as one block of data. But how does pydicom then handle the deserialization? |
As far as I can see, there is no special handling - it is just decoded from base64 and added as (byte array) value to the PixelData element, and handled as if read from a stream. |
I don't think so. If the data is compressed, it would not be a good idea to uncompress it before transferring it over the wire, as that that may substantially increase the needed time. I would say that we go the Ultimately though this should be implemented, as I think this use case gets ever more common. I don't really know the code here, but I think the easiest way would probably be to write the pixel data into a buffer the same way it is written to a stream or file, and use that buffer for serialization. This would be memory intensive and not very efficient, so in the long run this should be optimized, for example by retaining the pixel data buffer as a byte array, and decoding (e.g. writing it into the fragment objects) only if needed. Or retain the pixel data buffer and have the fragment objects point to different offsets of the buffer. Or something else... |
Describe the bug
Trying to serialize a DICOM header that contains
DicomItem
s that are notDicomElement
. This results in exceptions.To Reproduce
Minimal program:
Expected behavior
To handle serialization gracefully, according to type. There are probably variations based on the subclass of DicomItem.
Basically, the code in the serializer is:
There is no check anywhere that the
item
is actually a DicomElement.Environment
fo-dicom 5.1.2
The text was updated successfully, but these errors were encountered: