Conquest problem with Philips Ingenia 3T

  • Hi everybody,


    After doing modification on dgatesop.lst as I said before, Osirix and Achieva 3T can send images to Conquest, and Osirix can retrieve it too, but eFilm can't retrieve the studies, do anybody know why??


    Conquest log tells me that eFilm did not accept the connection...


    Thanks,

  • Quote from marcelvanherk

    Hi,


    as conquest, efilm will have a list of accepted modalities, which might be changeable. But as the modalities are private objects efilm may not support them.


    Marcel


    I thought the problem was the same Marcel, but you or someone know if is there a way to edit this list of classes that eFilm accepted and include the classes that are in dgatesop.lst to solve the problem, as I did with the Conquest? Or how can I discover what are the classes that eFilm reject?


    Thank you

  • You could try to just delete the private sop classes when they enter conquest.
    Philips Private MR Series Data Storage 1.3.46.670589.11.0.0.12.2 and Philips Private MR Examcard Storage 1.3.46.670589.11.0.0.12.4
    are not images so you could delete them if you're only interested in seeing images.

  • Hello,


    we have kinda the same error here. The pictures are already stored in conquest, but when we try to get them out (send, dgate --move whatever) conquest just freezes and writes a

    ***Implicit_Parse encountered an invalid element length during load of DCM file (in 68506c69)

    in the PACStrouble.log


    The pictures are stored as v2 so I tried to convert them to dcm with the WatchFolder-option. Same result. Conquest writes the first picture on the file system with 0kb size, takes all memory available and does nothing after that.


    Any ideas how to send them as v2 away or uncompress them and then send the dcm/ work from there?


    Regards

    Sebastian

  • Hi Ther,


    maybe my question shall fit to this topic. I have connected newest Philips Intellispace Portal (treated as workstation-client for me) to 1.5.0 conquest version with default config (syntax 4=dcm witn un compression), transfers are working fine but in trouble log i have a log of Inconsistent info with data changes. Please have a look in attached log. Should I worry about it? Could You suggest if i can fix anything in configuration?

  • Hi,


    It is interesting, for instance in the log you see that in one study you have images of a male and female patient - this must be incorrect. The conquest warnings indicate it database will be 'confused', a study belong to one patient and can have only one sex. Have a look at the one with *** which are more of a problem:


    ***Truncated FrameOfRef -- this is a UID which is max 64 characters but it is passed 88

    ***Inconsistent PatientBir -- could be scans of the different patients mixed

    *** connection terminated -- aborted a transfer on the scanner?


    So no big worries but I have the impression your scanner data is a mess.


    Marcel

  • Hi,


    NEVER use V2 with modern images. Your only salvage would be to look in the images, and make sure that all sequences in there are known in dgate.dic.


    Marcel

    What do you recommend Marcel? We're beginning to handle very large ultrasound content and I'm running into compression bottlenecks. Our cluster is 4 hosts for HA and throughput but they are only 3cpu/3gigs of mem so we are going to need to bump that up. We prefer jp2k generally and have not yet moved to 1.5 though I'm trying to make some progress on that today.

  • Jp2k is slow. The faster lossless compressor with good compression is jpegls. Here are some test results for a 512 x 512 image:


    J2: 25 ms, 40%

    J7: 31 ms, 32%

    N2: 15 ms, 42%

    JK: 88 ms. 33%


    regards,


    Marcel

Participate now!

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