Encapsulated Data Without End Delimiter about dicomparser HOT 10 OPEN

Hi Keean - This sounds like a violation of the DICOM standard. The strategy for this library is to be strictly DICOM compliant. That being said, we do want to expose hooks so applications like yours can implement such workarounds if desired. If you have a design in mind for these hooks, feel free to propose it.

from dicomparser.

It seems the only way we know it is an encapsulated image is because of the transfer encoding. What I need is a way to defragment the data in the pixel element.

If I could do:

switch(transfer_syntax) {
    case '1.2.840.10008.1.2.4.70':
        var pixel_data_element = data_set.elements.x7fe00010
        var pixels = dicomParser.getEncapsulatedData(pixel_data_element);
        // pixels is an ArrayBuffer of the defragmented data.
        ...
}

Because as far as I know if the data is compressed it must be encapsulated.

Is there a way to do this with the current library API?

from dicomparser.

You can work around this today by replacing the dicomParser.readDicomElementExplicit function with your own implementation. While this works, we could reduce the code you have to maintain for this specific issue by moving the logic for determining if pixel data is encapsulated to a function dicomParser.isEncapsulated() that you could override with your own implementation.

from dicomparser.

I like the idea of "dicomParser.isEncapsulated()"

from dicomparser.

OK, feel free to submit a PR!

from dicomparser.

Can I get access to DICOM properties from inside "readDicomElementExplicit"? For example I want to check the TransferSyntax, but the dataSet is not passed into "readDicomElementExplicit" as a parameter, is it available as on object property of the dicomParser object (this)?

from dicomparser.

There is a problem with getting the data needed for "isEncapsulated()". The normal method requires the element.length which is straightforward.

The patched version will need the byte-stream (to check if it starts xfffee000) and the transferSyntax, as if we know the image is a JPEG (which starts xd8ff), and the pixel-element actually starts xfffee000 we know it must be encapsulated. In this way we avoid false detection of encapsulation on an uncompressed image that starts with the pixels (xfe xff x00 xe0), which although unlikely is an issue with the current implementation that does not get passed the transferSyntax.

So the current implementation would require "dicomParser.isEncapsulated(element, byteStream)", but somehow we need to find a way for it to access the transferSyntax. As transferSyntax is read from the meta-header, the ideal option would seem to be to store it as a property "dicomParser.transferSyntax",
and then it can be read from "isEncapsulated" without having to thread it into the arguments of every function call down from the top-level of the parser.

If this is an acceptable solution I can send a pull request.

from dicomparser.

We don't want to store any data in the dicomParser object itself (it is stateless). Your best option is to store the transfer syntax in the byteStream object. You can do this by passing the transferSyntax to the ByteStream() constructor when it is created in getDataSetByteStream().

Ideally the entire dataset would be available to isEncapsulated() so the logic can reference any attribute already parsed. The complexity and effort needed to do this though is hard to justify given the low chance anyone would every use it

from dicomparser.

I have submitted a pull request. Does it look okay?

from dicomparser.

Any news on the pull request? I am about to deploy the fixes, and I would like to know if these changes are going to get incorporated into the dicomParser library, as I don't want to have to maintain a fork of the library. If they are not going to get incorporated, It would be better to know sooner rather than later so that I can look for a different way to do it.

from dicomparser.