built in jpg compression doesn't work properly

    Hi Conquest users!


    I switched
    from 1.4.13 built in dbf incoming compression j2 over external compression
    to 1.4.16 built in sqlite incoming compression j2 over internal compression (the external compression-executables do not exist any more)


    When sending to 1.4.16 the logging says to recompress to j2 before writing to mag0:
    [CONQUESTSRV1] [recompress]: recompressed with mode = j2 (strip=0)
    [CONQUESTSRV1] Rewritten file: ...,
    but it actually compresses to j1. In the dicom-header of the written files I find:
    (0002,0010) UI [1.2.840.10008.1.2.4.70] # 22 TransferSyntaxUID, which is j1.
    Retrieving these files whith a client configured to prefer j1, the data is sent directly without recompressing (which proofs, that they are j1).
    A j2-configured client lets conquest recompress to j2 before sending (which proofs, that they are not j2).


    But when I send already j2-compressed files to conquest, they are not recompressed and so they are stored as j2 (1.2.840.10008.1.2.4.57).
    These files are not recompressed for a j2-configured client (proof, that they are really stored as j2).


    My workaround so far: putting the executables of external compression in the binary directory and modifying dicom.ini: UseBuiltInJPEG = 0.


    Does anybody know a solution for that problem?



    Thanx in advance,
    Heinz Liesenfeld

    Hi Marcel,


    thanks for your fast reply. In the meantime I'll switch back to 1.4.14, as this version can handle decompression with fast builtin-jpg-support, so the very slow binaries of the dcmtk are only needed for compression. 1.4.16 just has one switch in dicom.ini for both compression and decompression internal or external.


    One hypothesis is, that the compression is correct, but the dicom tag (0002,0010) TransferSyntaxUID is updated to [1.2.840.10008.1.2.4.70] instead of [...57] by mistake. I don't know how to test this, and so far I have not read a line of the source code, sorry for that, I ought to be ashamed of myself :oops: !


    Heinz

    Hi Marcel,


    could this be the bug in line 4633ff of nkiqrsop.cpp: ?


    Code
    // bcb: should not j1 & J2 offer both types of lossless.			case '1': // lossless			case '2': // losless sv 6				  uid.Set("1.2.840.10008.1.2.4.57"); TrnSyntax.Set(uid);				  PresContext.AddTransferSyntax(TrnSyntax);				  uid.Set("1.2.840.10008.1.2.4.70"); TrnSyntax.Set(uid);				  PresContext.AddTransferSyntax(TrnSyntax);				  break;


    be better:

    Code
    case '1': // lossless

    				  uid.Set("1.2.840.10008.1.2.4.70"); TrnSyntax.Set(uid);

    				  PresContext.AddTransferSyntax(TrnSyntax);

    				  break;

    			case '2': // losless sv 6

    				  uid.Set("1.2.840.10008.1.2.4.57"); TrnSyntax.Set(uid);

    				  PresContext.AddTransferSyntax(TrnSyntax);

    				  break;


    It's a long time ago that I coded in c/c++, so it's no more than a guess. Could you please post me, when you compile a new version?


    Thank you very much for all!
    Heinz

    Hi,


    I just looked at bruce his code, and it seems that his code does not differentiate between J1 and J2, it always sets 1.2.840.10008.1.2.4.70 after lossless lpeg compression, which is J1 (line 6307). So it seems that J2 is not supported with the new internal code, while J2 is actually the default conquest JPEG mode. I see that this is an issue. I will think about a solution.


    The 1.4.16 implementations can use the external compression executables; you just have to add them to the conquest folder.


    Marcel

    Hi Marcel,


    I guessed it was just the uid set wrong because retrieving with a j2-configured client lets conquest recompress to j2.
    My setup for this:
    Conquest1: getting all dicom-pictures from the modalities, wrongly stored as j1, forwarding to Conquest2 as j2, all forwarded pictures get recompressed to j2 before sending, in Conquest2 they are just stored with correct uid ...57 without recompression. Clients configured to j2 get them from Conquest2 without recompression.


    Does this help?
    Heinz

    Hi Heinz,


    J1 is JPEG Lossless (1.2.840.10008.1.2.4.70), Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1]).
    J2 is JPEG Lossless (1.2.840.10008.1.2.4.57), Non-Hierarchical (Process 14) and I've only seen the First-Order Prediction set to 1
    Or basically the same thing with the First-Order Prediction defined as 1.
    The techie stuff: DICOM standard PS 3.5-2008, sec 10.2, page 58 states that lossless is 1.2.840.10008.1.2.4.70.
    So what does all this mean.
    My logic:
    If it comes in as J2, leave it alone, it is already what I want, DICOM 3 will have no problem with it.
    If it comes in as anything else, make it J1, the default for lossless, even if the older J2 is selected.
    The questions:
    Is there a reason for needing tag (0002,0010 ) set to 1.2.840.10008.1.2.4.57?
    Is an older system having trouble with 1.2.840.10008.1.2.4.70?
    Do you have images with the First-Order Prediction not set to 1? (I would love to see them)
    The solution?:
    It would be an easy change to let the older tag be used (the compression is the same), but not DICOM 3 standard.


    Bruce

    Hi Bruce,


    j1 has selection value 1, j2 has selection value 6, see here for the difference:


    http://en.wikipedia.org/wiki/JPEG-LS#JPEG-LS


    It is a problem, cause conquest makes that difference. All my clients are configured to prefer j2, so the files stored with dicom tag ...70 instead of ...57 get recompressed (decompressed and again compressed), which means a very high load on the server. I switched back to version 1.4.14, because no recompression is required with the files stores with tag ...57, they are just sent.


    With several concurrent threads this means an improvement of up to factor 20 in time.


    Best regards,
    Heinz

    Hi Heinz,


    I looked at the wikipedia page and it speaks about the true lossless and near true lossless. For this, PS 3.5-2008, section A4.3, page 68 added 1.2.840.10008.1.2.4.80 and 1.2.840.10008.1.2.4.81, though I have not seen them used yet.


    The "lossless SV6" in the code came from the original nkiqrsop.cxx. Looking closely at the old code, I see for J1 the option passed is "e1" and for J2 is "el".
    You are correct, to correctly send "1.2.840.10008.1.2.4.57", I think the predictor must be 6.
    I also think this needs to be fixed.
    If you want to play with compiling, I have fixed this version of nkiqrsop.cpp and put it here:
    http://www.bitsltd.net/images/…ces_software/nkiqrsop.cpp
    I compiled it, but have not tested it yet, however the code changes are very small.


    Bruce

    Hi Marcel, hi Bruce,


    my link to wikipedia was some lines to far in that file, the explanation of sv1 vs. sv6 is just above JPEG-LS.
    Cluny describes the differences between lossless jpeg sv1..6..8 vs. JPEG-LS vs. J2K and several other compression algorithms on medical images in


    http://www.dclunie.com/papers/…comCompression_Clunie.pdf


    Lossless jpeg sv6 seems to have slightly better compression than sv1, which is identical to my own experience, but the difference is very small.
    So my suggestion for a quick and dirty fix:
    - Use the new internal j1 compression, even if j2 is configured
    - do not recompress incoming j2 files, just store them
    - write correct tags (...70 for j1, leave ...57 for incoming j2)
    - send the files as they are without recompression on both requests by the client j1 or j2
    - add optional modification of tag from ...70 to ...57 on outgoing files if client rejects ...70 (not DICOM-conform)
    The decompression algorithms are identical, so I see no problem in this optional deviation of the standard.


    Heinz

    Hi Marcel,


    Is the new code posted? It is an easy change. It all takes place in CompressJPG. If the code is on the site, I will pull it down and modify it or I can send you a "From To" file. Also, you can e-mail the file. Let me know.


    Bruce

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login