search

OHIF / image-JPEG2000

30 stars 21 forks source link

Error while parsing COC information #8

Open hroenick opened 8 years ago

hroenick commented 8 years ago

"Cannot read property 'decompositionLevelsCount" error is thrown when trying to parse DICOM JPEG2000 images with COC information. On some type of exams (e.g., US) we reproduce this error when loading with cornerstoneWADOImageLoader. The parsing error is thrown at:

function decodeJPEG2000(dataSet, frame) { var height = dataSet.uint16('x00280010'); var width = dataSet.uint16('x00280011'); var compressedPixelData = dicomParser.readEncapsulatedPixelData(dataSet, dataSet.elements.x7fe00010, frame); var jpxImage = new JpxImage(); jpxImage.parse(compressedPixelData); <<<-------- ERROR! ...

The cause is the inability of the JPEG 2000 library to parse the COC information:

case 0xFF53: // Coding style component (COC) throw new Error('JPX Error: Codestream code 0xFF53 (COC) is ' + 'not implemented');

hroenick commented 8 years ago

I checked the mozilla upstream and this funcionallity still is not implemented. https://github.com/mozilla/pdf.js/blob/master/src/core/jpx.js

hroenick commented 8 years ago

I am experimenting a fix in this fork: https://github.com/hroenick/image-JPEG2000 Apparently it is working in my tests but I'm not completed sure if it is correct and if some side-effects (bugs) were inserted.

jpambrun commented 8 years ago

Hi,

First off, thank you for your contribution.

1) I initially did not consider the possibility of having 8-bit signed components. Have you encountered that case? If so, in what context? I'm just curious.

2) Your solution, skipping the COC, block is not robust enough.

The coding parameters are globally stored in the Coding style default (COD) segment. It contains information such as progression order, number of layers, number of decomposition levels, code-block/precinct size, transformation used, etc.

The Coding style component (COC) segment can redefine some of these parameters on a tile basis. As a consequence, your solution works if and only if the optional COC segment is identical to the global COD segment. It seems that the internal structure to support per-tile COC is already implemented which means that only the parser would need to be updated.

hroenick commented 8 years ago

1) Yes I did. I'm working with some US images that were converted to DICOM encoded in JPEG 2000. I do not know the original image format (encoding) but some colleges developed a converter using GDCM [1]. I placed a sample image in the original cornerstone thread [2] if you are curious about it. Github is not allowing me to attach the image here.

2)

Your solution, skipping the COC, block is not robust enough.

Agreed!

As a consequence, your solution works if and only if the optional COC segment is identical to the global COD segment.

I was aware of that limitation, but so far I only encountered these exact cases where the COC information is identical to the COD.

It seems that the internal structure to support per-tile COC is already implemented which means that only the parser would need to be updated.

I thought in implementing the parser, because in theory the COD's parser implements more than the necessary information of COC, But I would need some more time to study the specification to implement that. Still didn't have time to do so. And not knowing if the structure to use the COC was already built made me decide to just skip that data. If the COC logic is already implemented it's is a great news.

[1] http://gdcm.sourceforge.net/wiki/index.php/Main_Page [2] https://groups.google.com/forum/#!topic/cornerstone-platform/NOscLaUk7Nw