compression j2 and j1 faulty

    Hi Marcel,


    just trying 1.4.17alpha. Again the issue with j2 and j1:


    I configured conquest: dropped j2, incoming j2, archiving as. When sending already j2 compressed (1.2.840.10008.1.2.4.57) to conquest, they are just stored without recompression and also retreived with j2-configured client without recompression (good so far), but when sending uncompressed data to conquest, conquest says they are compressed as j2 but actually they are stored as j1 (in 0002,0010 in conquest header dump 1.2.840.10008.1.2.4.70) and need to get recompressed to a retrieving client configured to accept j2. In the client the dicom header then is 1.2.840.10008.1.2.4.57. Sending these files back to conquest is handled correctly: just stored without recompression, and by again retrieving no recompression required.


    Sending files retrieved from older version of conquest identically configured (stored as j2 and retrieved without recompression, tag 0008,2111 lossless jpeg selection value 6) to new conquest-server get recompressed and header in new conquest server shows (0002,0010) UI [1.2.840.10008.1.2.4.57] # 22 TransferSyntaxUID. But when retrieving again these files again are recompressed by conquest server to j2 although they should already be stored as j2! [CONQUESTSRV1] [recompress]: recompressed with mode = j2 (strip=0)
    Some confusion on my side!


    As I changed my job, it is not essential for me, but I think it's an issue.


    Best wishes for the new year!


    Heinz

    Hi Marcel,


    it seams that conquest writes dicom tag 0002,0010 to 1.2.840.10008.1.2.4.70 instead of ...57 when compressing incoming uncompressed images to j2! That seems to be the only bug.


    Everything else behaves like it should. So when retrieving these files they get recompressed because of the wrong header: ...57 is requested, but ...70 is stored so they get recompressed althoug actually they are already j2 (there is no more j1 compression in the code) but with wrong header and then by recompressing they get the correct tag ...57.


    Incoming files already having tag 0002,0010 set to ...57 are stored as is whithout recompression and ...57 stays in the header.


    Hope this helps!


    Heinz

    HI,


    I would just like to comment that though J1 and J2 are the same, not all commercial and freeware software are able to
    import J2 implementation of jpeg lossless. J1=UID 70 and j2= UID 57 should be compatible
    and interchangeable, but unfortunately UID 70 seems to be more universally accepted jpeg lossless transfer syntax implementation.
    I would have wished jpeg J1 was the version you choose to retain. So that Kpacs and efilm ver 1x to 2x can import them directly.



    see comment of David Clunie.
    https://groups.google.com/foru…otocols.dicom/jLCdCsrhi7s


    ajgg

Participate now!

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

Register Yourself Login