Comments (7)
I more and more get the impression, that by the DICOM standard DicomJson is intended for data exchange and similar to DICOM Media it is assumed that the data uns excanged uncompressed.
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 dcmtk
way, e.g. do not support InlineBinary
for compressed data, but unfortunately, we also don't support BuldDataURI
for that data, as it is handled the same way.
If there is no easy way to handle this in fo-dicom, I would propose that fo-dicom shall not write the pixel data in this case and issue a respective warning or error (and adapt the documentation, of course), at least for the current version.
This would at least avoid the crash.
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...
But this should probably be handled and discussed in a separate issue.
from fo-dicom.
Thank you for reporting this bug!
from fo-dicom.
@mrbean-bremen I am struggling with this, maybe you could help me with your knowledge from pydicom?
When parsing pixeldata, then fo-dicom distinguishes between "plain data", where the whole data is stored into a DicomOtherByte, or fragmented, where instead a DicomOtherByteFragment is instanciated and the data is split into fragments. The difference on how to tread the binary stream is well defined in Dicom standard.
But I do not find this difference in Dicom Json definition. So it seems even in case of fragmented data, the whole pixeldata has to be serialized as huge InlineBinary.
While for the serialization from DicomDataset to Json this would be fine, I wonder what to do when deserializing. When parsing a binary Dicom file, then the length of the DicomTag is important, if it is UndefinedLength (FFFFFFFF) then the following data is fragmented, else not. But the Json does not have a Length property. So this information is lost on serialization.
How does pydicom handle this? What is the json result, when serializing the file "CT1_J2KI" from fo-dicom.Tests/TestData?
from fo-dicom.
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 InlineBinary
for Pixel Data, but send it separately via BulkDataURI
.
The standard only says:
If an attribute contains an "InlineBinary", this contains the base64 encoding of the enclosing attribute's Value Field.
There is a single InlineBinary value representing the entire Value Field, and not one per Value in the case where the Value Multiplicity is greater than one.
It says nothing about encapsulated data, at least as far as I can see. As far as I know, pydicom
also handles it this way, e.g. as one opaque block of data.
from fo-dicom.
Sure, I will be able to serialize the fragmented data as one block of data. But how does pydicom then handle the deserialization?
from fo-dicom.
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.
There are some roundtrip tests (encoding in json, reading back from json and check that the datasets are equal), and this works also for compressed transfer syntaxes like JPEG2000.
Note though that pydicom always handles PixelData as opaque blobs until it is needed to read, so the inner structure (e.g. the embedded sequences) are not considered at all at this level.
from fo-dicom.
tried a lot, but still didn't manage to convert a jpeg2k compressed file with fragmented pixeldata into a json with available tools. some refused to convert.
And dcmt converted everything but the pixeldata and wrote to the output, that json inlinebinary is not suppored for compressed pixeldata.
I more and more get the impression, that by the DICOM standard DicomJson is intended for data exchange and similar to DICOM Media it is assumed that the data uns excanged uncompressed.
The currenst state, that an exception is throws, is not acceptable. As said, I try to serialize and deserialize the data in a compatible way, so that other applications still can work with the data that fo-dicom creates.
But other approaches would be, that
- first the data should be transformed to an uncompressed transfersyntax and then Json-serialized,
- or to skip the pixel data at all.
Any feedback is welcome!
from fo-dicom.
Related Issues (20)
- Code in fo-dicom to apply window width and center on an image HOT 1
- TCP listener stuck while processing TLS handshake HOT 4
- HTJ2K Throwing exception HOT 2
- The SCU client transmits images to the fo-dicom c-store-scp, and the speed decreases sequentially after each task is transmitted
- Korean Hangul characters incorrectly read from dicom file HOT 2
- fo-dicom v5 Dependency Injection Documentation HOT 4
- DicomServer performance regression HOT 6
- Microsoft Code Analysis HOT 2
- Creating a TCP connection using `DicomClient.SendAsync()` does not take `AssociationRequestTimeoutInMs` into account HOT 4
- DicomValidation for VR PN HOT 17
- dataset AddOrUpdate not find Encod args HOT 4
- Support proper encoding of strings with multi-valued encodings HOT 9
- Decimal String not adhering to standard? HOT 9
- Service stopped When Changing DICOM File Compression HOT 13
- Incorrect conversion between C# decimal and DICOM Decimal String HOT 1
- ISO 2022 IR 58 Encoded Strings Cannot Be Decoded Correctly HOT 3
- Performance impact in DicomDataset comparing HOT 5
- What is the plan for supporting .NET 8? HOT 3
- Ability to cancel the store request in C-Get HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fo-dicom.