Scrambled images

  • We are having some issues with images arriving scrambled on some of our Hologic review stations
    I have spent quote a few hours troubleshooting the issue and I think I found what is causing it, but not sure what the best way forward is.
    Example of one of the scrambled images arriving: (all headers show up ok)
    [Blocked Image:]

    The issue is only occurring from some of our conquest servers, and so far only seems to happen when we send compressed images. Compression does not seem to matter.
    If we set the compression to un the images arrive correctly.
    All servers are running 1.4.17e

    The review station is set up as:
    rws1 4006 j2

    the working conquest servers show the following in the log:
    10/4/2016 8:19:19 AM [CONQUEST1] UPACS THREAD 42951: STARTED AT: Tue Oct 04 08:19:19 2016
    10/4/2016 8:19:19 AM [CONQUEST1] Calling Application Title : "CONQUEST1 "
    10/4/2016 8:19:19 AM [CONQUEST1] Called Application Title : "CONQUEST1 "
    10/4/2016 8:19:19 AM [CONQUEST1] Application Context : "1.2.840.10008.", PDU length: 16384
    10/4/2016 8:19:19 AM [CONQUEST1] Presentation Context 0 "1.2.840.10008." 1
    10/4/2016 8:19:19 AM [CONQUEST1] Presentation Context 1 "1.2.840.10008." 1
    10/4/2016 8:19:19 AM [CONQUEST1] C-Move Destination: "rws1 "
    10/4/2016 8:19:19 AM [CONQUEST1] Number of Images to send: 23
    10/4/2016 8:19:20 AM [CONQUEST1] Accepted compression: ui
    10/4/2016 8:19:20 AM [CONQUEST1] Sending file : E:\shimages\xxxxxxxxx\1.2.840.113663.1500.1.168875912.2.1.20160303.94628.843_0001_000001_14570163012be2.v2
    10/4/2016 8:19:20 AM [CONQUEST1] [recompress]: recompressed with mode = ui (strip=1)
    10/4/2016 8:19:20 AM [CONQUEST1] Accepted compression: ui

    The compression for the transfer is changed to ui, which I can't seem to find any info on in the manual

    a server that does not work shows:
    10/4/2016 8:14:34 AM [CONQUEST] UPACS THREAD 11104: STARTED AT: Tue Oct 04 08:14:28 2016
    10/4/2016 8:14:34 AM [CONQUEST] Calling Application Title : "CONQUEST "
    10/4/2016 8:14:34 AM [CONQUEST] Called Application Title : "CONQUEST "
    10/4/2016 8:14:34 AM [CONQUEST] Application Context : "1.2.840.10008.", PDU length: 16384
    10/4/2016 8:14:34 AM [CONQUEST] Presentation Context 0 "1.2.840.10008." 1
    10/4/2016 8:14:34 AM [CONQUEST] Presentation Context 1 "1.2.840.10008." 1
    10/4/2016 8:14:34 AM [CONQUEST] Presentation Context 2 "1.2.840.10008." 1
    10/4/2016 8:14:34 AM [CONQUEST] C-Move Destination: "RWS1 "
    10/4/2016 8:14:34 AM [CONQUEST] Number of images to send: 28
    10/4/2016 8:14:34 AM [CONQUEST] Accepted compression: ui
    10/4/2016 8:14:34 AM [CONQUEST] Sending file : F:\pacsimages\xxxxxxxxxxx\1.2.840.113619.2.227.207919569228.7858110310083250.10005_0560_000004_14755832214a0f.dcm
    10/4/2016 8:14:34 AM [CONQUEST] [recompress]: recompressed with mode = j2 (strip=0)

    When going over all the differences between the pacs servers that work and the ones giving issues, the only difference I can find is 2 different dgatesop.lst files
    The one that works is at the top and seems to be older, the one scrambling the images, is below and is newer

    ## DICOM Application / sop / transfer UID list.## This list is used by the CheckedPDU_Service ( "filename" ) service# class. All incoming associations will be verified against this# file.## Revision 2: disabled GEMRStorage and GECTStorage# Revision 3: extended with new sops and with JPEG transfer syntaxes# Revision 4: added Modality Worklist query##None none RemoteAE#None none LocalAE#DICOM 1.2.840.10008. applicationVerification 1.2.840.10008.1.1 sopStoredPrintStorage 1.2.840.10008. sopHardcopyGrayscaleImageStorage 1.2.840.10008. sopHardcopyColorImageStorage 1.2.840.10008. sopCRStorage 1.2.840.10008. sopDXStorageForPresentation 1.2.840.10008. sopDXStorageForProcessing 1.2.840.10008. sopDMStorageForPresentation 1.2.840.10008. sopDMStorageForProcessing 1.2.840.10008. sopDOralStorageForPresentation 1.2.840.10008. sopDOralStorageForProcessing 1.2.840.10008. sopCTStorage 1.2.840.10008. sopRetiredUSMultiframeStorage 1.2.840.10008. sopUSMultiframeStorage 1.2.840.10008. sopMRStorage 1.2.840.10008. sopMRImageStorageEnhanced 1.2.840.10008. sopMRStorageSpectroscopy 1.2.840.10008. sopRetiredNMStorage 1.2.840.10008. sopRetiredUSStorage 1.2.840.10008. sopUSStorage 1.2.840.10008. sopSCStorage 1.2.840.10008. sopSCStorageSingleBitMF 1.2.840.10008. sopSCStorageGrayscaleByteMF 1.2.840.10008. sopSCStorageGrayscaleWordMF 1.2.840.10008. sopSCStorageTrueColorMF 1.2.840.10008. sopStandaloneOverlayStorage 1.2.840.10008. sopStandaloneCurveStorage 1.2.840.10008. sop#WFStorageTwelveLeadECG 1.2.840.10008. sop#WFStorageGeneralECG 1.2.840.10008. sop#WFStorageAmbulatoryECG 1.2.840.10008. sop#WFStorageHemodynamic 1.2.840.10008. sop#WFStorageCardiacElectrophysiology 1.2.840.10008. sop#WFStorageBasicVoiceAudio 1.2.840.10008. sopStandaloneModalityLUTStorage 1.2.840.10008. sopStandaloneVOILUTStorage 1.2.840.10008. sopGrayscaleSoftcopyPresentationStateStorage 1.2.840.10008. sopRetiredXASinglePlaneStorage 1.2.840.10008. sopXASinglePlaneStorage 1.2.840.10008. sopRFStorage 1.2.840.10008. sopXABiPlaneStorage 1.2.840.10008. sopNMStorage 1.2.840.10008. sopVLImageStorage 1.2.840.10008. sopVLMultiFrameImageStorage 1.2.840.10008. sopVLMicroscopicSlideStorage 1.2.840.10008. sopVLPhotographicStorage 1.2.840.10008. sopVLEndoscopicImageStorage 1.2.840.10008. sopVLMicroscopicImageStorage 1.2.840.10008. sopVLSlideCoordinatesMicroscopicImageStorage 1.2.840.10008. sopVLPhotographicImageStorage 1.2.840.10008. sopBasicTextSR 1.2.840.10008. sopEnhancedSR 1.2.840.10008. sopComprehensiveSR 1.2.840.10008. sopMammographyCADSR 1.2.840.10008. sopKeyObjectSelectionDocument 1.2.840.10008. sopPETStorage 1.2.840.10008. sopStandalonePETCurveStorage 1.2.840.10008. sopRTImageStorage 1.2.840.10008. sopRTDoseStorage 1.2.840.10008. sopRTStructureStorage 1.2.840.10008. sopRTTreatmentRecordStorage 1.2.840.10008. sopRTPlanStorage 1.2.840.10008. sopRTBrachyTreatmentRecordStorage 1.2.840.10008. sopRTTreatmentSummaryRecordStorage 1.2.840.10008. sop#GEMRStorage 1.2.840.113619.4.2 sop#GECTStorage 1.2.840.113619.4.3 sopGE3DModelObjectStorage 1.2.840.113619.4.26 sopGERTPlanStorage 1.2.840.113619.5.249 sopGERTPlanStorage2 1.2.840.113619.4.5.249 sopGESaturnTDSObjectStorage 1.2.840.113619.5.253 sopPhilips3DVolumeStorage sopPhilips3DObjectStorage sopPhilipsSurfaceStorage sopPhilipsCompositeObjectStorage sopPhilipsMRCardioProfileStorage sopPhilipsMRCardioImageStorage sopPatientRootQuery 1.2.840.10008. sopPatientRootRetrieve 1.2.840.10008. sopStudyRootQuery 1.2.840.10008. sopStudyRootRetrieve 1.2.840.10008. sopPatientStudyOnlyQuery 1.2.840.10008. sopPatientStudyOnlyRetrieve 1.2.840.10008. sopFindModalityWorkList 1.2.840.10008. sopPatientRootRetrieveNKI 1.2.826.0.1.3680043.2.135.1066. sopStudyRootRetrieveNKI 1.2.826.0.1.3680043.2.135.1066. sopPatientStudyOnlyRetrieveNKI 1.2.826.0.1.3680043.2.135.1066. sopBasicGrayscalePrintManagementMeta 1.2.840.10008. sopBasicColorPrintManagementMeta 1.2.840.10008. sopBasicFilmSession 1.2.840.10008. sopBasicFilmBox 1.2.840.10008. sopBasicGrayscaleImageBox 1.2.840.10008. sopBasicColorImageBox 1.2.840.10008. sopBasicPrinter 1.2.840.10008. sopLittleEndianImplicit 1.2.840.10008.1.2 transferLittleEndianExplicit 1.2.840.10008.1.2.1 transfer#BigEndianExplicit 1.2.840.10008.1.2.2 transferJPEGBaseLine1 1.2.840.10008. transfer LittleEndianExplicitJPEGExtended2and4 1.2.840.10008. transfer LittleEndianExplicit#JPEGExtended3and5 1.2.840.10008. transfer LittleEndianExplicitJPEGSpectralNH6and8 1.2.840.10008. transfer LittleEndianExplicit#JPEGSpectralNH7and9 1.2.840.10008. transfer LittleEndianExplicitJPEGFulllNH10and12 1.2.840.10008. transfer LittleEndianExplicit#JPEGFulllNH11and13 1.2.840.10008. transfer LittleEndianExplicitJPEGLosslessNH14 1.2.840.10008. transfer LittleEndianExplicit#JPEGLosslessNH15 1.2.840.10008. transfer LittleEndianExplicit#JPEGExtended16and18 1.2.840.10008. transfer LittleEndianExplicit#JPEGExtended17and19 1.2.840.10008. transfer LittleEndianExplicit#JPEGSpectral20and22 1.2.840.10008. transfer LittleEndianExplicit#JPEGSpectral21and23 1.2.840.10008. transfer LittleEndianExplicit#JPEGFull24and26 1.2.840.10008. transfer LittleEndianExplicit#JPEGFull25and27 1.2.840.10008. transfer LittleEndianExplicit#JPEGLossless28 1.2.840.10008. transfer LittleEndianExplicit#JPEGLossless29 1.2.840.10008. transfer LittleEndianExplicitJPEGLossless 1.2.840.10008. transfer LittleEndianExplicit#JPEGLS_Lossless 1.2.840.10008. transfer LittleEndianExplicit#JPEGLS_Lossy 1.2.840.10008. transfer LittleEndianExplicit#RLELossless 1.2.840.10008.1.2.5 transfer LittleEndianExplicit#LittleEndianExplicitDeflated 1.2.840.10008. transfer LittleEndianExplicitJPEG2000LosslessOnly 1.2.840.10008. transfer LittleEndianExplicitJPEG2000 1.2.840.10008. transfer LittleEndianExplicit

    I'm not really sure what in here might be breaking the transfers, but if someone could help out that would be great.
    Or point me to a possible other cause for this issue.

    And we would need the later version of the file to support BTO images I think, so reverting all servers to the older file might not be an option.


  • Hi David,

    ui = LittleEndianImplicit; the default transfer syntax. When the transfer goes wrong, the server recompresses to jpeg (J2), which is set in It goes right when compression does not happen (UI), but I actually see no relevant difference in dgatesop.lst; the jpeg lines are the same. Can you see a difference in the log, maybe enable debug?


  • I tested different transfer by replacing the dgatesop.lst files on 1 server with different versions, but could not get it to go and transfer images in j2, even though that is what is defined in the acrnemap
    So now I think it must be due to the version of dgate
    I have no idea which version of the dgate executables I'm running, and the properties don't really help.
    What is the best idea of finding out which version you are running?
    the interface and logs don't really show me, even when restarting the server

    is there something to run on the command line to show the version?

  • Found the command, it is dgate --display_status:

    The difference between the 2 servers is that one of them is on 1.4.17d and one is 1.4.17beta3
    Beta 3 never switches back to the J2 compression and is transferring the images correctly
    1.4.17d is sending them as J2 and they show up garbled

  • Hi, is configured as j2, but apparently hologic does not support it. So the difference is that the newer version correctly refuses to send j2. Would you mind testing the latest beta as well? Just to make sure that behaves correctly.


  • Hello Marcel
    it seems like I'm having same problem, but in my case I don't get scrambled images, my issues is that when my conquest forwards images to one of our servers it doesn't go in compression as it was set.
    so in acraname I have set server2 IP**** PORT*** j2 and when images are sent to server2 from server1 in server status shows that:
    C-Move Destination: "server2 "
    Number of images to send: 22
    Accepted compression: j1
    Sending file :********
    [recompress]: recompressed with mode = j1 (strip=1)

    so is this a fault of server2 that it's not getting j2 compression? because if the same images will be forwarded to server3 from server1 it will go in j2 as it was set.

    Edit: server1 that sends images to server2 and server3 is 1.4.17d

Participate now!

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