Posts by snalbansed

  • Troubleshooting -FAILED: Error on Load

    Hi Marcel


    I made the changes suggested to line 3093 onward of src/dgate/src/dgate.cpp, and repeated ./maklinux and made sure the dgate file in /usr/lib/cgi-bin/newweb/ had a new datestamp.


    When I retried copying a QA's worth of mammo DICOM images, all but about 6 failed. Only one of the successful ones appears to have been one that previously failed (and it was the previous line in the shell output).


    How would I know that the changes I have made have gone through to the dgate in use?


    As an alternative approach, I copied all the files to a folder in MAGDevice0/data then when the copy was complete, I 'moved' them into the incoming folder. As you might expect, the move was instantaneous and all the files imported into conquest without error.


    Ed

  • Troubleshooting -FAILED: Error on Load

    I'm thinking that maybe all the invalid group order messages related to .bmp and Thumbs.db files that were inadvertently copied with the DICOM (blimmin K-PACS!)


    In which case the checking for load then delay-repeat if it fails would be good. I think this will work for the mid-size files, etc DX, MG, but the delay wouldn't be enough for a large file such as a BTO or enhanced CT. For the most part, we wouldn't be dropping those files with this mechanism, but on a new server I'd like to make things as robust as they can be!


    Is it worth looping around this, or maybe I need to investigate another mechanism of some description - drop the files in a different folder, then trigger a Lua script by going to a URL or something.


    What do you think?

  • Troubleshooting -FAILED: Error on Load

    Looks like that is the issue. A large collection of imports worked when dgate wasn't running until after the copy was complete.


    I guess it might be my setup that is causing the problem:

    • Conquest is running on linux
    • MAGDevice0 is a CIFS mount
    • Mounted share is provided by Synology NAS
    • Share is also accessed on Windows PCs; this is how the DICOM files will be copied into 'incoming'

  • Troubleshooting -FAILED: Error on Load

    Sorry, I'm stuck again.


    I am having trouble with importing mammo images through the 'incoming' folder. I think I am right in saying that if I DICOM Store the images to conquest (from KPACS or dcmtk storescu), everything works fine every time.


    However, if I drop them into 'incoming', sometimes they work just fine, and other times they don't. On the same images with a delete/regeneration in-between.


    The most common errors are a simple:

    Code
    ***[AddImageFile] /mnt/archive/data/incoming/1.2.840.113619.2.66.2218493241.1747160229131157.339.dcm -FAILED: Error on Load


    or

    Code
    ***(Dyn) Encountered an invalid group order during load of DCM file (after 4d42305e)


    I can't see that there is anything unusual about these images.


    I haven't found the same issue with any other modalities yet, but I haven't been through methodically.


    I have tried doing two things: one is to add 'NoDICOMCheck = 1' to dicom.ini - this appeared to increase the number of errors printed and writes corrupted DICOM files to disk. The other was to use './dgate --debuglevel:3' - this didn't seem to make any difference to the file imports.


    What can I do to establish what is happening?


    Thanks


    Ed

  • PatientID conflicts with QA data

    Hello, sorry, me again.


    I am setting up a DICOM server for diagnostic radiology physics quality assurance images. I now have mechanisms for QA images to be sent via DICOM or placed in 'incoming', where they are then placed in a nice human navigable structure (site/unit/year/month/day+patientname/series/UID).


    The issue I need to address now is inconsistencies in the database. I could run this as a null database server, but I'd like to have the option of using the web interface to quickly review the images, and I like to dream of a time when I can get my QA image analysis tools to find images by a database lookup rather than pointing to a directory and indexing them each time.


    Our current practice is to name our QA patients 'Physics^TypeOfTest' with ID 'phy12345' or similar and date of birth as today's date, or exactly 100 years ago. This therefore causes conflicts when importing into conquest; in particular one patient ID with different dates of birth. It is this I need to resolve.


    I can see that patient ID is central to the way the database is designed and maintained, and I assume from looking through the documentation the patient ID must be unique (with date of birth and maybe name) in conquest. Is this the case?


    Should I be modifying the PatientID on import, or forcing the team to use a different ID each time (which we sometimes do anyway for similar reasons on other systems, ie 'phy1234520161202a')? Or just ignore the error messages as we don't tend to rely on patient ID or date of birth anyway when analysing the data.


    In an ideal world I would store the site and unit (ie one particular scanner) in the database, then write a new web interface search that allows search on these terms and completely ignores the patient ID and date of birth :D


    As always I appreciate any pointers or help that you can offer me.


    Kind regards


    Ed

  • Using lua to import and move DICOM from disk

    Hello again. I'm hoping someone can give me some pointers.


    I'm setting up conquest as a QA image server (replacing KPACS plus manual archiving). I have created a lua makefilename file so images that are sent directly from modalities can be placed into a logical human-friendly files structure for ease of subsequent analysis using a variety if tools. The makefilename script uses modalities, station names and serial numbers to work out which bit of kit/site etc each image comes from.


    A good proportion of our QA images however are copied onto the server from USB or CD/DVD. I'd like to be able to 'dump' these into a folder, then run a script to import them to conquest, with the objects being moved to the locations determined by the same makefilname.lua script.


    I'm assuming I'd need to do something along the following lines; am I right?


    Code
    -- iterate through folder, or somehow get individual DICOM objects to read

    new_dcm = readdicom(filename)

    new_filename = dofile('makefilename.lua') -- or is that just in dicom.ini, and either way how do I pass my DICOM object?

    os.rename(filename, new_filename)

    new_dcm = readdicom(new_filename)

    addimage(new_dcm)


    Any help or advice would be most welcome. I could also upload an abbreviated version of my makefilename.lua if anyone might find it useful?


    Ed

  • Forcing dgatesop.lst to be recognised!

    Hi Marcel


    I've finally been able to return to this, and it turns out that conquest was playing nicely all along. Once the dgatesop.lst was updated anyway!


    DCMTK Storescu has a limitation of 128 presentation contexts, so there are a handful that don't make the cut. By replacing something that I would never ever come across with something more useful like BreastTomosynthesisImageStorage, storescu to conquest now works. Hoorah.


    Thanks for investigating this with me Marcel.


    Ed

  • Forcing dgatesop.lst to be recognised!

    I moved it up to the first row, confirmed with


    Code
    ⟫ ./dgate --get_sop:11.2.840.10008.5.1.4.1.1.13.1.3 BreastTomosynthesisImageStorage


    The result is the same:


  • Forcing dgatesop.lst to be recognised!

    That's a good point - I wonder if it is to do with the transfer syntax. With the debug option passed, I get the following when trying to storescu a BTO to conquest:


    Code
    Testing transfer: '1.2.840.10008.1.2.1' against list #0 = '1.2.840.10008.1.2'Testing transfer: '1.2.840.10008.1.2.1' against list #1 = '1.2.840.10008.1.2.1'Testing transfer: '1.2.840.10008.1.2.2' against list #0 = '1.2.840.10008.1.2'Testing transfer: '1.2.840.10008.1.2.2' against list #1 = '1.2.840.10008.1.2.1'Testing transfer: '1.2.840.10008.1.2.2' against list #2 = '1.2.840.10008.1.2.2'


    which is repeated many many times. Then:


    Code
    Arena 0:system bytes     =    1368064in use bytes     =    1079760Arena 1:system bytes     =    1155072in use bytes     =     665504Arena 2:system bytes     =     614400in use bytes     =       2224Total (incl. mmap):system bytes     =    3272704in use bytes     =    1882656max mmap regions =          2max mmap bytes   =     446464UPACS THREAD 67: STARTED AT: Wed Nov 23 09:39:26 2016*** connection terminatedUPACS THREAD 67: ENDED AT: Wed Nov 23 09:39:28 2016UPACS THREAD 67: TOTAL RUNNING TIME: 2 SECONDS


    At the storescu end, the message remains:


    Code
    E: No presentation context for: (BT) 1.2.840.10008.5.1.4.1.1.13.1.3E: Store SCU Failed: 0006:0208 DIMSE No valid Presentation Context ID


    From the newweb interface:

    Code
    (version 1.4.19beta3a, port 104, bits 64) was started on Tue Nov 22 22:44:51 2016

    Old JPEG decoder=0, JPEGLIB jpeg codec=1, LIBJASPER jpeg2000 codec=1

  • Forcing dgatesop.lst to be recognised!

    Hmm, that's strange! I get the following:


    Code
    ⟫ ./dgate --get_sop:551.2.840.10008.5.1.4.1.1.13.1.3 BreastTomosynthesisImageStorage


    But if I try and send using dcmtk storescu, I get the following:

    Code
    E: No presentation context for: (BT) 1.2.840.10008.5.1.4.1.1.13.1.3

    E: Store SCU Failed: 0006:0208 DIMSE No valid Presentation Context ID


    Does dgate have a debug level of logging mode?

  • Forcing dgatesop.lst to be recognised!

    Hi


    I'm using version 1.4.19beta3a on linux, and I'm running dgate from sudo /usr/lib/cgi-bin/newweb/dgate -v


    I've copied the dgatesop.lst to the same folder, and in my dicom.ini I have tried both

    Code
    SOPClassList             = /usr/lib/cgi-bin/newweb/dgatesop.lst

    and simply

    Code
    SOPClassList             = dgatesop.lst


    Either way, I can't get dgate to propose the BTO presentation context that is included in the dgatesop.lst.


    I'm sure I have had it working at one point, but it isn't working now!


    Any idea what I am doing wrong?

  • Ubuntu install: /usr/bin/ld: cannot find -ljpeg

    My final setup notes, in case it is of use for editing the linux instructions. This is on a fresh Ubuntu 16.04.1 server installed as a LXD container:


    Code
    sudo apt install build-essential apache2 libpq-dev postgresql unzipsudo a2enmod cgidsudo service apache2 restart


    Copied download of dicomserver1419beta3b.zip


    Code
    mkdir conquestcd conquestunzip ../dicomserver1419beta3b.zip


    We need a new version of maklinux from Marcel van Herk http://forum.image-systems.biz…eply&f=33&t=45654#pr59441


    Code
    mv maklinux{,.original}nano maklinux


    Paste in new version copied from forum

    Code
    chmod 777 maklinuxchmod 777 src/dgate/jpeg-6c/configuresudo mkdir /usr/local/man/man1./maklinux


    Chose option 3) sqlite for now, just to get started
    For some reason, the script complained that

    Code
    cp: cannot create regular file '/usr/lib/cgi-bin/newweb/dgate': No such file or directorycp: cannot create regular file '/usr/lib/cgi-bin/newweb/acrnema.map': No such file or directory


    despite the fact that it did exist. Ran it a second time and this time the only complaint was regarding the directory data/dbase already existing.


    Copied dicom.sql and dgatesop.lst into /usr/lib/cgi-bin/newweb/ as they are both missing. It works without dgatesop.lst, but doesn't have the newer SOP Class UIDs such as BTO


    Code
    mkdir /mnt/archive/datachmod 777 /mnt/archive/data


    Edited dicom.ini, partly to add specific paths, partly because the version in /usr/lib/cgi-bin/newweb is relatively brief!: sudo nano /usr/lib/cgi-bin/newweb/dicom.ini


    Code
    #mvh 20151206  1.4.17d compatibility#mvh 20160314  for 1.4.19beta[sscscp]MicroPACS                = sscscpACRNemaMap               = acrnema.mapDictionary               = dgate.dicWebServerFor             = 127.0.0.1MyACRNema                = MYAETTCPPort                  = 104SOPClassList             = dgatesop.lstSQLServer                = /path/to/conquest/data/dbase/conquest.db3SQLite                   = 1# Configure serverImportExportDragAndDrop  = 1ZipTime                  = 05:UIDPrefix                = 99999.99999EnableComputedFields     = 1# Configuration of compression for incoming images and archivalDroppedFileCompression   = unIncomingCompression      = unArchiveCompression       = as# For debug informationPACSName                 = CONQUESTSRV1OperatorConsole          = 127.0.0.1DebugLevel               = 0# Configuration of disk(s) to store imagesMAGDeviceFullThreshold   = 30MAGDevices               = 1MAGDevice0               = /path/to/data/[webdefaults]size     = 560dsize    = 0compress = j2iconsize = 84graphic  = jpgviewer   = wadoseriesviewerstudyviewer = wadostudyviewer[DefaultPage]source = *.lua[AnyPage]source = start.luaexceptions=start,listpatients,liststudies,listseries,listimageswiththumbs,listimages,wadostudyviewer,wadoseriesviewer,wadoviewerhelp,slice,listtrials,listtrialpatients


    Edited acrnema.map to match MyACRNema setting.


    Finally:

    Code
    sudo /usr/lib/cgi-bin/newweb/dgate -v -r 

    sudo /usr/lib/cgi-bin/newweb/dgate -v