ohif / image-jpeg2000 Goto Github PK

The decoder currently returns either a Uint16 or Int16 thus wasting memory when only 8 bits are required.

Test jp2_U16bit_test fails with

jp2_U16bit_test.js
✔ file_860AE501
✖ file_lossyhdr

Assertion Message: 1994381 / 1998132 degraded pixels, MSE=46125280.03677685 Max err= 65535

When compared with Matlab's JPEG 2000 decoder, almost every pixels appears incorrectly reconstructed. This is illustrated in the attached figure where black represents perfect reconstruction and white represents a difference of 1000. Pixel close to 0 and 65,535 can roll over resulting in very obvious distortions.

I am trying to convert png images into JP2 with sampling factor. I am imagemagick tool for conversion, as they mentioned in docs -sampling-factor is used for sampling but it did not work.

http://ftp.icm.edu.pl/pub/unix/graphics/ImageMagick/www/jp2.html

convert wizard.png -colorspace YUV -sampling-factor 2,2 wizard.jp2

My command, it did not work
convert test/images/kodim$i.png -quality $(($j*5)) -colorspace YUV -sampling-factor 4,2 test/JP2/kodim$i/printf "%02d" $j.jp2

@jpambrun great work.
Would you mind publishing this library as an npm package?

With best regrads.

Hi, I would like some clarification about the documentation:
In the readme, it states that jpxData is uint8 and returns pixelData as int16.

Is it always the case? or somehow it could sometimers return uint8, int8, uint16 and int16?

Thanks!

jpxImage.parse(jpxData);
var width = jpxImage.width;
var height = jpxImage.height;
var pixelData = tileComponents.items;

Hi!

I'm having some problems using the lib on linux os. When I open a page and try to convert the image my chrome almost close and it happens only on linux os.

After that my computer gets so slow that I have do restart it.

Anyone have had the same problem? I tested on others computers and all linux had the problem.

I'm using Ubuntu 14.04 and the other computer is a Arch Linux OS.

Sorry if this is the wrong place to post it.

Saturn is failing due to a bug in the inclusion tag tree decoding.

I got this error for a JPEG2000 image I have using the latest version of the library:

Uncaught Error: JPX Error: Unsupported COD options (selectiveArithmeticCodingBypass)

I can provide image if needed

I had issues decoding a 16 bits DICOM image encoded using JPEG2000. After some debugging, I saw that the values from the storedPixelData array had negative values. Investigating further, I saw that JPEG2000 was storing the pixels in an Int16Array instead of a Uint16Array (which is used for raw images).

The following patch seems to work for me:

diff --git a/dist/jpx.js b/dist/jpx.js
index 14da7c9..e0095b7
--- a/dist/jpx.js
+++ b/dist/jpx.js
@@ -1383,7 +1383,7 @@ var JpxImage = (function JpxImageClosure() {
         transformedTiles[c] = transformTile(context, tile, c);
       }
       var tile0 = transformedTiles[0];
-      var out = new Int16Array(tile0.items.length * componentsCount);
+      var out = new Uint16Array(tile0.items.length * componentsCount);
       var result = {
         left: tile0.left,
         top: tile0.top,
diff --git a/dist/jpx.min.js b/dist/jpx.min.js

"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');

Some images don't produce the same result when decompressed with Matlab.

5-8% of pixels in cameraman and peppers are not reconstructed identically in lossy mode.

1.4% of pixels in 00000.dcm are not reconstructed perfectly in lossless mode (!!). All in the last few rows.

Subsampling 1 and 2 fails completely with the code from pdf.js.