addressing faulty jpeg-ls compressed data on a production system (related to http://www.dcm4che.org/jira/browse/DCMEE-1144)

[Petr Kalina]

dear community,

all our data is compressed with a faulty jpeg-ls compression rendering it unreadable for some of our clients. the problem is related to the bug in the used java imageio library (http://www.dcm4che.org/jira/browse/DCMEE-1144). we're using dcm4chee 2.14.1 which is affected by this bug. 

what is the correct way to address this? more specifically:

1) is there a way how to patch the existing system in order to address the situation? 

2) is it possible to configure for specific aets for the system to not to offer the jpegls transfer syntax and therefore force the data to be sent in some uncorrupted way?

3) what is the preferred way to repair the faulty historical binary data files on disc?

4) if i send the jpegls compressed data to a new chee instance running 2.17+ version of the software, will they be re-compressed so that they are correct within the new system?

i researched the problem somewhat, and i noticed that:

1) by 2.17.1 the compression system of dcm4chee has been fixed tp produce correct jpeg-ls data

2) there is a fixjpegls commad in the dcm4che2 library enabling fixing of corrupted streams

than you on participating on finding a solution to this problem!

peter

[Peter Heiles]

Hi Petr,

@1: the description on how to enable the correction on outbound (e.g. C-MOVE) can be found in this issue:

http://www.dcm4che.org/jira/browse/DCMEE-1528

http://www.dcm4che.org/jira/browse/DCMEE-1520

@2: only by duplicating the dicom server, storescp, etc. in the deployment or by putting a dicom proxy in front of the archive 

or you remove the JPEGLS support from the storescp config and avoid accepting any jpeg-ls compressed data

@3: leave it as is and rely on correction feature

@4: they will be corrected (if the implemantation class uid matches), see

http://www.dcm4che.org/jira/browse/DCMEE-1682 

regards,

Peter

[Petr Kalina]

Hi Peter,

thank you very much for your response! I've been hoping to report back after I successfully manage to address current problems, but I'm still struggling a bit.

the core of the problem is, that I have a huge archive running 2.14.8 version of chee which doesn't have the outbount correction filter yet. in order to upgrade, I have to also update the database. however, as the schema changed slightly (using bigint types instead of int(11) types for pk and fk columns) it is not easy to upgrade (I have over 40M instances in the DB). if I managed to update the database, the rest would be a cakewalk.

it seems to me that this is a major problem that many people must be facing, but I had no success on the forums.do you have any suggestion concerning this?

thanks really!!

peter

[Petr Kalina]

Hi Peter and the community,

I'm just concluding this thread with a solution that I found.

Eventually I managed to run 2.18 over existing database and data, using a specific dump-and-restore appraoch for the mysql database which I describe in another thread. Therefore it's possible for me to use the outbound correction filter now, addressing the problem I was facing without the need to convert all the data.

hope this helps someone, thanks a lot Peter for previous clarifications,

peter :-)