GE PACS system Kakadu-generated JP2 throws error
David Carman
I am working with JP2 images on a GE PACS system and have posted an
example of a fractured head of radius at
http://bobbejaan.net/pacs.eg.jp2
The DICOM data is kept in a separate file. I am using the
Ubuntu-packaged libopenjpeg2 v1.3+dfsg-4
david@lapdev:~$ j2k_to_image -i pacs.eg.jp2 -o test.bmp gives:
[ERROR] Expected JP Marker
[ERROR] Failed to decode jp2 structure
ERROR -> j2k_to_image: failed to decode image!
Jasper doesn't read either. Binary read of file shows "Kakadu-2.0.2"
in header. Kakadu reads its own file correctly.
Is it possible to read this file using OpenJPEG instead of Kakadu?
David Carman
Mathieu Malaterre
> I am working with JP2 images on a GE PACS system and have posted an
> example of a fractured head of radius at
> http://bobbejaan.net/pacs.eg.jp2
>
> The DICOM data is kept in a separate file. I am using the
> Ubuntu-packaged libopenjpeg2 v1.3+dfsg-4
This is a bug either in openjpeg 1.3 or in the debian packaging of
openjpeg. I can read this image file with gdcm which internally either
use openjpeg 1.2 or 1.4
Could you please fill in a bug report (debian bug tracker) ?
HTH
--
Mathieu
szuk...@arcor.de
>On Mon, Oct 31, 2011 at 7:53 AM, David Carman <tid...@gmail.com> wrote:
>> I am working with JP2 images on a GE PACS system and have posted an
>> example of a fractured head of radius at
>> http://bobbejaan.net/pacs.eg.jp2
>>
>> The DICOM data is kept in a separate file. I am using the
>> Ubuntu-packaged libopenjpeg2 v1.3+dfsg-4
>
>This is a bug either in openjpeg 1.3 or in the debian packaging of
>openjpeg. I can read this image file with gdcm which internally either
>use openjpeg 1.2 or 1.4
The bug is inherent:
branch15-r1033
==============
./j2k_to_image -i pacs.eg.jp2 -o pacs.bmp
[ERROR] Expected JP Marker
[ERROR] Failed to decode jp2 structure
ERROR -> j2k_to_image: failed to decode image!
trunk14-r1033
=============
./j2k_to_image -i pacs.eg.jp2 -o pacs.bmp
[INFO] Stream reached its end !
[ERROR] Problem with skipping JPEG2000 box, stream error
ERROR -> j2k_to_image: failed to read the header
v2-revision-1033/BUILD
======================
szukw000: bin/j2k_to_image -i pacs.eg.jp2 -o pacs.bmp
ERROR -> j2k_to_image: failed to decode image!
It is inherent, because the applications of the libraries do
not look for the magic of the file; but for the extension.
Renaming pacs.eg.jp2 to pacs.eg.j2k:
v2-revision-1033
================
bin/j2k_to_image -i /tmp/pacs.eg.j2k -o pacs.bmp
BMP CONVERSION: Truncating component 0 from 16 bits to 8 bits
Generated Outfile pacs.bmp
Because the file IS a J2K file; not a JP2 file.
winfried
David Carman
> Because the file IS a J2K file; not a JP2 file.
Spot on Winfried!
On Mon, Oct 31, 2011 at 1:34 PM, Mathieu Malaterre
<mathieu....@gmail.com> wrote:
> Could you please fill in a bug report (debian bug tracker) ?
I shall file a bug report with ubuntu as it crashes nautilus, and a
misnamed file should not be able to.
David
Mickaël Savinaud
It could be fine to keep a track of this issue in our issue tracking system: http://code.google.com/p/openjpeg/issues/list
Please David, post an issue with a link to the bug report of ubuntu.
I will add your file to the test suite as done by winfried to spot the problem.
Best Regards
Savinaud Mickael
 |
Mickaël SAVINAUD, PhD
Ingénieur Études et Développement CS Systèmes d'Information - Division Espace & Renseignement Département Information Géographique & Image Parc de la Grande Plaine - 5, Rue Brindejonc des Moulinais - BP 15872 31506 TOULOUSE - FRANCE Tel : +33 561 17 63 13 / Fax : +33 561 34 84 15 Email : mickael....@c-s.fr |
szuk...@arcor.de
>It could be fine to keep a track of this issue in our issue
>tracking system:
Solving this bug is (fairly) simple. No issue tracker necessary.
Changing 'j2k_to_image' I get:
---------------------------------------------------
./j2k_to_image -i /tmp/pacs.eg.jp2 -o pacs.eg.png
[INFO] Start to read j2k main header (0).
[INFO] Main header has been correctly decode.
[INFO] No decoded area parameters, set the decoded area to the all image
[INFO] Header of tile 1 / 1 has been read.
[INFO] Tile 1/1 has been decode.
COMPO[0]:
SRC: l_start_x_src=0, l_start_y_src=0, l_width_src=512, l_height_src=512
tile offset:0, 0, 0, 0
buffer offset: 0; 0, 0
DEST: l_start_x_dest=0, l_start_y_dest=0, l_width_dest=512, l_height_dest=512
start offset: 0, line offset= 0
[INFO] Image data has been updated with tile 1.
image is decoded!
Successfully generated Outfile pacs.eg.png
---------------------------------------------------
The patch is attached. It has one flaw: it seems that a magic
for JPIP/JPT does not exist. So I have used the usual filename
extension test for ".jpt". Should there be a test for ".jpp" too?
winfried
Mickaël Savinaud
Thanks Winfried, this patch seems good (I have just changed strcasecmp to _strnicmp to avoid problem with win32 platform).
However I think, it should be useful to merge the two approaches and warn the user about the fact that its file has not the right extension.
Any idea or comments ?
Best
Savinaud Mickael
szuk...@arcor.de
>However I think, it should be useful to merge the two approaches
>and warn the user about the fact that its file has not the right
>extension.
>
>Any idea or comments ?
Yes.
winfried.
./j2k_to_image -i pacs.eg.jp2 -o pacs.eg.png
===========================================
The extension of this file is incorrect.
FOUND .jp2. SHOULD BE .j2k or .jpc or .j2c
===========================================
Mickaël Savinaud
Done with rev 1052.
Best
Mickaël