JPEG encoded image transfert problem

Well, I have been using Conquest for a couple of year now. Great and stable. Thanks a lot.

We are putting together a project to migrate old data from an AGFA IMPAX 3.5 where the data are all in dicom JPEG compressed. The exact Transfert Syntax is JPEGLosslessNH14 1.2.840.10008.1.2.4.57 . Now I have setup Conquest 1.4.14beta 20070322., down to 1.4.11 trying to get the dcmdjeg.exe to do the decompressing but it is never even invoked, What we have is an association that never happens because Conquest claims that the list of SOP should be added to the dgatesop.lst file. Now if I use dcmdjpeg of the source file and send the output file to Conquest all is fine. If I comment out or not the JPEGLosslessNH14 entry in dgatesop.lst it does not change the issue. It's like it's never getting there. I activated the use of DCMTK OFFIS in the GUI and using .dcm extension. I compared all entries in the log generated from storescu with the -d switch . Can't figure out that one. Not related to modality type. It's purely JPEG related and/or LittleEndian/Explicit/Implicit sort of problem.

Here is the complaint

C:\DCMTK>storescu -v 127.0.0.1 5678 NM.dcm
Requesting Association
Association Accepted (Max Send PDV: 16372)
--------------------------
Sending file: NM.dcm
Transfer: JPEGLossless:Non-hierarchical:Process14 -> LittleEndianImplicit
Store SCU RQ: MsgID 1, (NM)
XMIT:DIMSE Warning: (STORESCU,ANY-SCP): sendMessage: unable to convert dataset
from 'JPEG Lossless, Non-hierarchical, Process 14' transfer syntax to 'LittleEndianImplicit'.

storescu: Store Failed, file: NM.dcm:
0006:020e DIMSE Failed to send message
storescu: SCU Failed:
0006:020e DIMSE Failed to send message
Aborting Association

Note: Inspection of the Conquest log indicates all negotiations over the modality source but never indicate the transfer sysntax that was proposed and/or the answer received it would help if negative answers would show in the Conquest logs.

Has someone had the problem before...

Marcel! Welcome back! Tomorrow is my turn for vacation....

You identified correctly the source of the error. I thought that all was fixed and I was getting the same error both with the original file from impax or after decompression and recompression. I used the dcmdjep.exe and dcmcjpeg.exe tools. Now after recompression the type of compressed file is "JPEG Lossless, Non-hierarchical, 1st Order Prediction" and that is well handled with the switch --propose-lossless but for the original impax file the type of compressed file is actually "JPEG Lossless, Non-hierarchical, Process 14" ?? The same command is not successful.
I don't know how to handle that TS.

Stéphane

Well Marcel I finally resolved that one (with you wise guidance)!!!

I looked at the code for storescu and noticed that the "JPEG Lossless, Non-hierarchical, Process 14" does exist in the dcmtk 3.5.3 environment but simply was not implemented as an option on the storescu utility. I modified the option parsing lines (only 4 lines to add) and now the option --propose-jpegprocess14 invoke the EXS_JPEGProcess14TransferSyntax TS whereas the --propose-lossless invoke the EXS_JPEGProcess14SV1TransferSyntax TS. I know this is not a DCMTK forum but since it is the final word on the issue. I transfered the image over to Conquest and confirmed that all is saved as is by the Conquest server (if one want it that way). In my case it will speed up the migration progress significantly.

Great !

Now I can leave later today for my vacations with complete peace of mind.

Thanks again Marcel!