Posts by skrani

  • Updating Dicom Information using Conquest

    In case this helps anyone.


    It took a while for me to get this working.
    Eventually this worked.


    Code
    c:\dicomserver\dgate.exe "--modifyseries:0070071234,,set 0008,1030 to \"Test-Description\""


    That is, I had to use " around the whole thing after dgate.exe then I needed to put backslash before the " around the Test-Description as shown above.
    Finaly it worked like expected.


    Thanks again for all your work Marcel.

  • Weasis & Conquest working yet with WADO?

    Try to use uncompressed images in conquest (with .dcm extension).


    I had the same result, the thumbnails show up, and immediately disappear, and it was due to some compression "mismatch" somehow


    I will take a closer look at your problem if this does not help at all.
    If you need compression, just try this first uncompressed, then try to figure out compression settings that work.


    (hint: if you configure conquest to store images uncompressed, then send the images from the conquest to it self, they will be rewritten uncompressed)


    best regards
    Skrani.

  • WADO - how to control transfer syntax.

    Hello.


    I have been playing with WADO and 1.4.16h on windows (XP SP3)


    Certainly improvement.


    If images are stored uncompressed on disk, it works as I expect, that is if I request image to be transferred uncompressed, it is, and jpeg compressed also works.


    How ever if the images are stored compressed on disk, and they are requested uncompressed with WADO that does not work, they will be compressed.


    Is this normal behaviour or bug?


    Best regards
    Steini.

  • Weasis & Conquest working yet with WADO?

    Yes I managed to get it working.


    Below is the procedure--- in short - By no means is the below instructions, just my notes, so I could possibly repeat the process.


    and you need to have the images stored uncompressed on the Conquest server (at least I had to)



    I wish you luck.


    Skrani.

  • WADO - how to control transfer syntax.

    Hello.


    I have been trying to use the WADO function, and it works for the Weasis viewer, as long as I have images stored uncompressed.


    I would like to choose the transfer syntax used when sending the images.


    I tryed to change the transfersyntax used by WADO without luck, it only accepts Little endian implicit 1.2.840.10008.1.2 or explicit 1.2.840.10008.1.2.1


    All others I tried, end up with error (I just used the link in IE, if ok it downloads the file, else there is a error.)


    Example: this works.
    http://localhost/cgi-bin/dgate…rSyntax=1.2.840.10008.1.2


    This does not work (only difference the transfer syntax requested at the end)
    http://localhost/cgi-bin/dgate…ax=1.2.840.10008.1.2.4.51


    error is...
    [CONQUESTWEASIS] Warn[CompressJPEGImage]: JPEG changed to lossless (J1) for 16 bits data
    [CONQUESTWEASIS] [recompress]: recompressed with mode = j3 (strip=0)
    [CONQUESTWEASIS] Recompress: cannot rewrite jpeg/rle image in v2 format


    Images are stored in .DCM file uncompressed.


    If images are stored J1 I could not get them in any format.
    Basicly always the error
    [CONQUESTWEASIS] Recompress: cannot rewrite jpeg/rle image in v2 format


    I used filenamesyntax=4 (data is stored in chapter 10 format)


    I am using 1.4.16g


    Any ideas for me?
    Am I doing something wrong, or is this just not supported yet?


    Best regards
    Skrani.

  • Conquest 1.4.15 released at last

    Regarding issue 2:
    I belive I have a clue why this is happening.
    On windows servers, you can default have 3 desktop sessions, 1 console and 2 terminal sessions. If conquest GUI is running in more than one session, this happens. (I assume both GUI's start to create the zip files, then something goes wrong).


    Best regards
    Steini.

  • ZipMsgXX.res is probably not linked to the executable.

    I belive I know the reason for this behaviour.


    Before we had windows XP, now we have Windows Server. On XP you only have one session, console. On Server you have the console and 2 terminal sessions. If the GUI is running in more than one session this zip issue happens.


    Best regards


    steini.

  • High CPU

    Hello Marcel.


    Sorry, this is all there is in the previous log files....but please read on.


    Interesting thing is, that when I "fixed" the issue with another system trying to store images with already existing images from another patient on the same image UID then the system is no longer getting up to 100% cpu.


    This Conquest server is used as backup for Carestream System 5 server that keeps retrying to send the studies over until it manages to do so successfully. Since it never managed to get a success when sending those over, it kept trying, and in this process it seems to have used up 1 core for every retry. The server has now been running 24 hours and is still at "0%" cpu use. (before I fixed the issue with the studies it would be at 100% after 24 hours for sure)


    I managed to replicate this :-)


    I did the same change in Carestream System as before, that is, merge a study to another patient. Doing so seems to change the patient name and ID of the images, without changing the UID.
    First I tested with US images, and I would not get any cpu load when sending them over to Conquest.
    Then I tested with MG images like those that caused the problem before and "hurray" it worked.... eh that is.. it fails...


    Each time the Carestream system tryes to send this "merged" study over, it will "freeze" one CPU core.


    I did this with test images so I could send them to you for testing. I hope you dont mind, but I uploaded them.


    During the test I enabled Debug logging and this is the result of trying to send one "changed" study over.




    Unfortunately for the progress of this matter, but fortunately for me :-) I am going on 2 weeks holiday now. (I will leave on monday afternoon)
    During my holiday I can not connect into the server, but still can answer some questions.


    Thanks for the help and for Conquest, it certainly is great dicom server.


    Best regards
    Steini.

  • High CPU

    Found one more thing...


    in the PacsTrouble.log file there are these 2 lines (I have 2 hanging Cores now)


    20090529 21:35:07 *** connection terminated
    20090529 21:36:45 *** connection terminated


    and in the log at the same time...


    5/29/2009 8:54:04 PM killed and restarted the server
    5/29/2009 8:55:38 PM killed and restarted the server
    5/29/2009 9:35:07 PM [ICSREMOTEBACKUP] *** connection terminated
    5/29/2009 9:36:45 PM [ICSREMOTEBACKUP] *** connection terminated
    5/29/2009 9:37:06 PM [ICSREMOTEBACKUP] ***Error saving to SQL: xx\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000001_12436330260000.v2
    5/29/2009 9:37:06 PM [ICSREMOTEBACKUP] ***Error saving to SQL: xx\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000002_12436330260001.v2
    5/29/2009 9:37:06 PM [ICSREMOTEBACKUP] ***Error saving to SQL: xx\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000003_12436330260002.v2
    5/29/2009 9:37:06 PM [ICSREMOTEBACKUP] ***Error saving to SQL: xx\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000004_12436330260003.v2
    5/29/2009 9:37:06 PM [ICSREMOTEBACKUP] ***Error saving to SQL: xx\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000005_12436330260004.v2
    5/29/2009 9:37:06 PM [ICSREMOTEBACKUP] ***Error saving to SQL: xx\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000006_12436330260005.v2
    5/29/2009 9:37:06 PM [ICSREMOTEBACKUP] ***Error saving to SQL: xx\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000007_12436330260006.v2
    5/29/2009 9:38:35 PM [ICSREMOTEBACKUP] ***Error saving to SQL: yy\1.2.392.200036.9116.7.8.6.48513238.5.0.167536458011499_0001_000001_12436331150007.v2
    5/29/2009 9:38:36 PM [ICSREMOTEBACKUP] ***Error saving to SQL: yy\1.2.392.200036.9116.7.8.6.48513238.5.0.167536458011499_0001_000002_12436331160008.v2
    5/29/2009 9:38:36 PM [ICSREMOTEBACKUP] ***Error saving to SQL: yy\1.2.392.200036.9116.7.8.6.48513238.5.0.167536458011499_0001_000003_12436331160009.v2
    5/29/2009 9:38:36 PM [ICSREMOTEBACKUP] ***Error saving to SQL: yy\1.2.392.200036.9116.7.8.6.48513238.5.0.167536458011499_0001_000004_1243633116000a.v2
    5/29/2009 9:38:36 PM [ICSREMOTEBACKUP] ***Error saving to SQL: yy\1.2.392.200036.9116.7.8.6.48513238.5.0.167536458011499_0001_000005_1243633116000b.v2
    5/29/2009 9:38:36 PM [ICSREMOTEBACKUP] ***Error saving to SQL: yy\1.2.840.113704.7.1.1.1837551895.3256165612.17995.59.84.592_0001_000001_1243633116000c.v2
    5/29/2009 9:38:36 PM [ICSREMOTEBACKUP] ***Error saving to SQL: yy\1.2.840.113704.7.1.1.1837551895.3256165612.17995.59.84.592_0001_000001_1243633116000d.v2
    5/29/2009 9:38:36 PM [ICSREMOTEBACKUP] ***Error saving to SQL: yy\1.2.840.113704.7.1.1.1837551895.3256165612.17995.59.84.592_0001_000001_1243633116000e.v2
    5/29/2009 9:39:03 PM [ICSREMOTEBACKUP] ***Error saving to SQL: uu\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000001_1243633143000f.v2
    5/29/2009 9:39:03 PM [ICSREMOTEBACKUP] ***Error saving to SQL: uu\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000002_12436331430010.v2
    5/29/2009 9:39:03 PM [ICSREMOTEBACKUP] ***Error saving to SQL: uu\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000003_12436331430011.v2
    5/29/2009 9:39:03 PM [ICSREMOTEBACKUP] ***Error saving to SQL: uu\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000004_12436331430012.v2
    5/29/2009 9:39:03 PM [ICSREMOTEBACKUP] ***Error saving to SQL: uu\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000005_12436331430013.v2
    5/29/2009 9:39:03 PM [ICSREMOTEBACKUP] ***Error saving to SQL: uu\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000006_12436331430014.v2
    5/29/2009 9:39:03 PM [ICSREMOTEBACKUP] ***Error saving to SQL: uu\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000007_12436331430015.v2


    Will fix the PatID - UID collision and see if that helps keeping the server cpu load down.


    Best regards
    steini.

  • High CPU

    Hi Marcel.


    I have been really busy last couple of days, sorry for late reply.


    I found out what is causing the SQL write errors (a program that changes Pat ID without modifing UID´s)
    They are retried every now and then. I am wondering if that causes the dgate64.exe process to hang
    (because I have similar setup in another location that does NOT hang so frequently)
    I will now "cleanup" the mess so that the images can be sent from the archive that keeps trying to send them.


    On to the debug versions of Dgate.


    I replaced dgate64.exe with the one in the .zip file and the .pdb file is there as well.
    Killed the server and waited (about 2 hours)


    Now I have 2 "cpus" at 100%.


    But I cant see any difference in the Stack data (maybe you can) (will post "stack" below)


    The Dgate64.exe taking up the cpu time is under DgateServ.exe (running as service) see below.


    [Blocked Image: http://www.skrani.com/conquest/ProcessExplorer.GIF]


    Stack data - Again it keeps changing....

    Code
    ntoskrnl.exe+0x549c5dgate64.exe+0x1f5282dgate64.exe+0x442d8


    Code
    ntoskrnl.exe+0x549c5dgate64.exe+0x5539ddgate64.exe+0x82b86dgate64.exe+0x553badgate64.exe+0x2426c0


    Code
    ntoskrnl.exe+0x549c5

    dgate64.exe+0x44150

    dgate64.exe+0x553ba

    dgate64.exe+0x82c58

    dgate64.exe+0x553ba

    dgate64.exe+0x2426c0


    I hope this helps (guess not though)


    Best regards
    steini.

  • eFilm query conquest with MySQL

    Hello Andreas.


    I had similar problems when I upgraded to efilm 3.0 (I assume you might be using e-Film 3.x)


    It is due to the fact that efilm somehow "needs" to have data is "study ID" and if there is nothing there nothing will display when you query the archive, but you can still push images from conquest to efilm just like you describe.


    I Posted my problems some time ago here,
    http://www.image-systems.biz/f…=1315&start=0&hilit=efilm
    (Search for "efilm 3.0 gold - does not display list of patients.)
    and more info here.
    http://www.image-systems.biz/f…=1526&start=0&hilit=efilm



    In short description is below, you will need some database knowledge but not much to solve this, if this is your problem.


    Good luck
    Steini.



    .............................
    After a while I found out that e-Film 3.0 will not properly display query result if the field StudyID is missing. some of the modalities at the site I did the upgrade on e-Film at, do not send anything in the StudyID DICOM tag, and that "confused" e-Film 3.0 somehow.


    To "solve" this I modified the MySQL database a little.


    First did a count on how many studies have nothing in the studyID:
    select count(*) FROM `conquest`.`dicomstudies` where StudyID is null


    Then added "studyID" of my own. (dummy one, checked the affected rows against the count above):
    update `conquest`.`dicomstudies`
    set StudyID = 'steini123'
    where StudyID is null


    And finally, changed the table so it would have default value if nothing is sent:
    ALTER TABLE `conquest`.`dicomstudies` MODIFY COLUMN `StudyID` VARCHAR(16) CHARACTER SET latin1 COLLATE latin1_swedish_ci DEFAULT 'steini123';


    This way, when Conquest is queried it will return something in the StudyID.
    I considered using Importconverters, but that would permanently change the images, and I was not to confortable with that idea.

  • High CPU

    Hello Marcel.


    Sorry for my late reply, I have been really busy lately.


    I have spent some time on this now and have some additional info.


    I have NO export or inport converters (see dicom.ini file in previous post)


    I had to get the server working this afternoon (release the cpu from 100%) so I killed and restarted the server.
    It is now 4 hours later at 14% cpu time, one core running full time, how ever this load has jumped between all the cores in about 30 minutes (only stopping for few seconds on 2 of them). Process ID (PID) did not change (4308)


    This might also be related to SQL writing errors, this server has loads of them for some reason.
    I have turned on debugging now to figure out a little more about the SQL errors.
    (Since I restarted it I have had SQL errors)


    Code
    20090514 20:38:47 *** connection terminated20090514 20:39:31 *** connection terminated20090514 20:39:32 ***Error saving to SQL: bbbbbbbbbb\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000001_12423335720000.v220090514 20:39:32 ***Error saving to SQL: bbbbbbbbbb\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000002_12423335720001.v220090514 20:39:32 ***Error saving to SQL: bbbbbbbbbb\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000003_12423335720002.v220090514 20:39:32 ***Error saving to SQL: bbbbbbbbbb\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000004_12423335720003.v220090514 20:39:32 ***Error saving to SQL: bbbbbbbbbb\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000005_12423335720004.v220090514 20:39:32 ***Error saving to SQL: bbbbbbbbbb\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000006_12423335720005.v220090514 20:39:32 ***Error saving to SQL: bbbbbbbbbb\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000007_12423335720006.v220090514 20:39:32 ***Error saving to SQL: bbbbbbbbbb\1.2.392.200036.9116.7.8.6.48513238.5.0.88893212188901_0001_000008_12423335720007.v220090514 20:40:15 ***Error saving to SQL: yyyyyyyyyy\1.2.392.200036.9116.7.8.6.48513238.5.0.167536458011499_0001_000001_12423336150008.v220090514 20:40:15 ***Error saving to SQL: yyyyyyyyyy\1.2.392.200036.9116.7.8.6.48513238.5.0.167536458011499_0001_000002_12423336150009.v220090514 20:40:15 ***Error saving to SQL: yyyyyyyyyy\1.2.392.200036.9116.7.8.6.48513238.5.0.167536458011499_0001_000003_1242333615000a.v220090514 20:40:16 ***Error saving to SQL: yyyyyyyyyy\1.2.392.200036.9116.7.8.6.48513238.5.0.167536458011499_0001_000004_1242333616000b.v220090514 20:40:16 ***Error saving to SQL: yyyyyyyyyy\1.2.392.200036.9116.7.8.6.48513238.5.0.167536458011499_0001_000005_1242333616000c.v220090514 20:40:16 ***Error saving to SQL: yyyyyyyyyy\1.2.840.113704.7.1.1.1837551895.3256165612.17995.59.84.592_0001_000001_1242333616000d.v220090514 20:40:16 ***Error saving to SQL: yyyyyyyyyy\1.2.840.113704.7.1.1.1837551895.3256165612.17995.59.84.592_0001_000001_1242333616000e.v220090514 20:40:16 ***Error saving to SQL: yyyyyyyyyy\1.2.840.113704.7.1.1.1837551895.3256165612.17995.59.84.592_0001_000001_1242333616000f.v220090514 20:40:37 ***Error saving to SQL: xxxxxxxxxx\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000001_12423336370010.v220090514 20:40:37 ***Error saving to SQL: xxxxxxxxxx\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000002_12423336370011.v220090514 20:40:37 ***Error saving to SQL: xxxxxxxxxx\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000003_12423336370012.v220090514 20:40:37 ***Error saving to SQL: xxxxxxxxxx\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000004_12423336370013.v220090514 20:40:37 ***Error saving to SQL: xxxxxxxxxx\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000005_12423336370014.v220090514 20:40:37 ***Error saving to SQL: xxxxxxxxxx\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000006_12423336370015.v220090514 20:40:37 ***Error saving to SQL: xxxxxxxxxx\1.2.392.200036.9116.7.8.6.48513238.5.0.185561895581167_0001_000007_12423336370016.v220090514 20:40:53 Inconsistent StudyTime in DICOMStudies: PatientID = 'uuuuuuuuuu' StudyInsta = '1.2.392.200036.9116.7.8.6.48513238.5.0.198671771682584', Old='090058.343000', New='090058'20090514 20:40:53 Inconsistent StudyModal in DICOMStudies: PatientID = 'uuuuuuuuuu' StudyInsta = '1.2.392.200036.9116.7.8.6.48513238.5.0.198671771682584', Old='US', New='SR\\US'


    Images sent to this server are LARGE 20MB or so each (Mammograpy images), but not that many. (less than 1000 images each day)


    About the Process explorer.


    I tryed opening up ConquestDICOMserver.exe but under that there was no CPU usage.


    I found the CPU usage under dgate64.exe - It keeps changing, these below were taken with approx 10 seconds between....

    Code
    ntoskrnl.exe+0x549c5dgate64.exe+0x14fafc


    Code
    ntoskrnl.exe+0x549c5dgate64.exe+0x279f0dgate64.exe+0x33aeadgate64.exe+0x55db8dgate64.exe+0x33aeadgate64.exe+0x1896c0


    Code
    ntoskrnl.exe+0x549c5

    dgate64.exe+0x279f0

    dgate64.exe+0x33aea

    dgate64.exe+0x55db8

    dgate64.exe+0x33aea

    dgate64.exe+0x1896c0


    I sure hope this is helpful in figuring out what is going on.


    Best regards


    steini.