New release 1.4.17alpha (beta2 May 2013 update below)

  • Very Nice Works , I learn on DICOM standard at my work ( working in Imaging Software Factory ) , and specialy on performance improvement of File Tranfers and automation .


    And This work is a very nice approach of DICOM World :)


    I'll Try the 1.4.17 ( currently working on a 1.4.16 rc4


    Thx , and long life :)

  • Marcel & Lambert,


    Firstly thank you for this excellent server!
    I have some wishlist requests below for which I have taken the liberty of suggesting priorities :)


    a) I noted that if the server gets sent two patients with the same PATIENTID, they seem to merge into one entry even if PATIENTNAM is different and one of them disappears... Not sure how this should be best handled...
    Priority: probably low - should probably not be sending it patients with the same ID (the reason this occured is because the studies are anonymized and end up with same ID at default)


    b) I use the server as part of a DICOM anonymization pathway, along with David Clunie's excellent DICOM anonymizer, so I use the Browse database function interactively. I note that it does not refresh automatically unless you change tabs and return. For example, new studies don't appear and if you delete a study within the database browser it ends up with an "image file not found" error. Can there be a manual "refresh" button in the browse database tab?
    Priority: low - one can change tabs and return to browser tab


    c) For the same reasons above, can the top left panel of the browse database tab be made resizable so one can view more than 4 patients at a time?
    Priority: low but I'm guessing this should be easy and welcomed (at least by me!)


    d) For the same reasons as b: is there an option to always display large files in the browse database?
    Priority: very low if (e) is achieved


    e) Even better than (d) would be the ability to view studies from Conquest fully in the K-browser. This doesn't work at all for me... Maybe I'm doing something wrong, but I have a number of study series that include echocardiograms. Such studies have multiple images and each image is often a 'movie' comprising of multiple (maybe hundernds) of frames ("multiframe object"). When I select the series and then view in K-Pacs, it only opens the very first 'image' (multiframe object) and its corresponding frames in K-Pacs but the rest of the 'images' in the series are not in there... Even if I select another 'image' within the series, right click and select KPacs, it still only opens the first one. Studies where each 'image' really is one image (such as a CT) rather than multiframe, the KPacs browsing works fine.
    Priority: at least medium for me...


    Many thanks,


    Nikos

  • a) I noted that if the server gets sent two patients with the same PATIENTID, they seem to merge into one entry even if PATIENTNAM is different and one of them disappears...
    Hi, this is inherent in the patientroot model used on the server. The original data is kept in the study table but not returned on queries. Maybe it could be on StudyRootQueries, I can look into that. EDIT: just validated that a study root query behaves correctly and does not look into the merged patient table. I.e., it is up to the user to choose a query that will keep differences in patient names or not.


    b) Can there be a manual "refresh" button in the browse database tab?
    Priority: low - one can change tabs and return to browser tab
    This already sits in the context menu ;->>>


    c) For the same reasons above, can the top left panel of the browse database tab be made resizable so one can view more than 4 patients at a time?
    Priority: low but I'm guessing this should be easy and welcomed (at least by me!)
    Hm, I will have a look. There is not much space. Now the image table resizes if you make the GUI bigger = I could make it the patient table.


    d) For the same reasons as b: is there an option to always display large files in the browse database?
    Priority: very low if (e) is achieved
    Already there; increase LargeFileSizeKB ;->>>


    e) Even better than (d) would be the ability to view studies from Conquest fully in the K-browser. This doesn't work at all for me... Maybe I'm doing something wrong, but I have a number of study series that include echocardiograms. Such studies have multiple images and each image is often a 'movie' comprising of multiple (maybe hundernds) of frames ("multiframe object"). When I select the series and then view in K-Pacs, it only opens the very first 'image' (multiframe object) and its corresponding frames in K-Pacs but the rest of the 'images' in the series are not in there... Even if I select another 'image' within the series, right click and select KPacs, it still only opens the first one. Studies where each 'image' really is one image (such as a CT) rather than multiframe, the KPacs browsing works fine.
    Priority: at least medium for me...
    Hm, this is a hard one that has been on the wishlist a long time.


    Regards, Marcel

  • Hi Marcel,


    Many thanks for the prompt reply. I found the context menu DBBrowser refresh and the option to display larger images in the ini.. I should have looked in there, but Conquest was so simple to set up and use with just the GUI that I never even looked at the ini file :-)
    I tried the StudyRoot query and it does indeed help resolve the two patients bearing the same ID.
    Having the patient table enlarge instead of the image table when resizing would be great.
    It's a shame about the KPacs integration for multiframe objects but not a big deal. I installed KPacs as standalone and will view images that way, although that will need them to be copied over rather than being viewed in situ.
    Many thanks again for this excellent software and your prompt response!


    Nikos

  • Hi Marcel,
    I'm intending install Lubuntu as the sever for Dicom images. Conquest works on Lubuntu or only on Ubuntu? I installed Conquest, as a experience, on a PC with Lubuntu 12.10, but on the web page, the space where I spected the servers list appear is clean. So, I can't see the images from the web. The Phillips CT has sent images with no difficults to Conquest. I could see the patients worklist on the Mysql Conquest db. The acrnema.map is ok. I tried many things and I think maybe the error is in the dgate. Tryed erasing the dicom.ini from the cgi-bin and from the Conquest files and the web interface works, again with the blank servers list. On the user's PC (Lubuntu or Ubuntu) I installed Aeskulap, that works with an AET. The echotest from Aeskulap works finely. It mounts the patients list, but it can't receive images from Conquest. From the server LXTERMINAL could see communication Conquest-Aeskulap, but appear a message that the CMove trying from Aeskulap was blocked. Could help me?

  • Hi Marcel,
    This is my acrnema.map:
    /* **********************************************************
    * *
    * DICOM AE (Application entity) -> IP address / Port map *
    * (This is file ACRNEMA.MAP) *
    * *
    * All DICOM systems that want to retrieve images from the *
    * Conquest DICOM server must be listed here with correct *
    * AE name, (IP adress or hostname) and port number. *
    * The first entry is the Conquest system as example. *
    * *
    * *
    * The syntax for each entry is : *
    * AE <IP adress|Host name> port number compression *
    * *
    * For compression see manual. Values are un=uncompressed; *
    * j1,j2=lossless jpeg;j3..j6=lossy jpeg;n1..n4=nki private *
    * jk=lossless jpeg2000;jl=lossy jpeg2000 *
    * *
    ********************************************************** */


    teste 127.0.0.1 1033 as



    V* * 1234 as
    S* * 5678 un


    EBW 10.40.144.22 104 un
    AESKULAP-032 hcap-032 6000 as


    root@hcap-144:/home/hcap/conquest# ./dgate -v -m
    ** AE / IP-PORT Map dump


    teste 127.0.0.1 1033 as
    V* * 1234 as
    S* * 5678 un
    EBW 10.40.144.22 104 un
    AESKULAP-032 hcap-032 6000 as
    root@hcap-144:/home/hcap/conquest#

  • Hi,


    'as' is never a good idea as outgoing compression, make that 'un'.


    And put the "V* * 1234 as" and "S* * 5678 un" at the bottom of the list, these are wildcards.


    Another issue is that the temp file might be impossible to create. The default is in data/printer_files


    Marcel

  • Hi Marcel,


    I have some Intravascular Ultrasound images (IVUS). They are ultrasound images from inside vessels. They are admittedly very large series of images (the first 'image' I have consists of 2586 frames!). I sent them to Conquest ok..
    When I try to view them off Conquest using K-PACS it fails and the server status reveals memory errors:
    [UN2CADW14] UPACS THREAD 4: STARTED AT: Fri Apr 19 20:05:09 2013
    [UN2CADW14] Calling Application Title : "KPServer"
    [UN2CADW14] Called Application Title : "UN2CADW14 "
    [UN2CADW14] Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384
    [UN2CADW14] Presentation Context 0 "1.2.840.10008.5.1.4.1.2.2.2" 1
    [UN2CADW14] C-Move Destination: "KPServer"
    [UN2CADW14] Number of Images to send: 6
    [UN2CADW14] Accepted compression: ui
    [UN2CADW14] ***VR:ReAlloc out of memory allocating 1766596680 bytes
    [UN2CADW14] ***A fatal error occurred (out of memory) - closing server


    This may be because, no matter what setting the KPServer is at (uncompressed, prefer JPEG lossy, prefer JPEG lossnes, compatibility), the only way transfers work is if the CONQUEST Known Providers entry is KPServer [IP] [port] u1
    I don't seem to be able to get jpeg to work despite trying various combinations of settings int he KPserver side and CONQUEST 'known providers' entry (tried j2, j2, j6).


    I'm guessing the memory error happens as CONQUEST tries to convert these massive files to 'uncompressed'.


    Is this a bug or a feature I'm using wrong?
    :)
    Many thanks,
    Nikos

  • Hi Marcel,


    I am using ConQuest 1.4.17alpha.
    I also filled in a bug report and Lambert got back to me. One of the things he suggested was to try to read the files directly off the ConQuest data directory to see whether the error starts there (before sending to KPACs). I tried opening those files with all kinds of viewers to no avail - they appear to be invalid. Interestingly, however, they can be viewed by ConQuest in the database browser (if I force viewing large images).


    I exported the original DICOMs from the originating server onto a CD and tried throwing them back at ConQuest (in case the problem arose due to the transfer into ConQuest over the network) but the same thing happened. The files written on the data directory are readable by ConQuest but nothing else, unlike the images on the CD that are readable.
    I also tried sending to another server (instead of KPACS) and the files are no good when they get there either, so I don't think it's a KPACS issue.


    The ConQuest settings were to enable JPEG(2000) support and keep images on disk as JPEG or Uncompressed and name as DCMs.


    I then disabled JPEG(2000) support and chose to save images on disk as uncompressed. I then re-imported the DICOMs to ConQuest off the CD.
    Once I did that, the images in the ConQuest Data Directory were now readable by various viewers. I can still not send them to KPACS even if uncompressed setting is selected.


    So I guess there may be two problems here:
    a) Why are the images becoming unreadable when selecting JPEG and
    b) Why can they not be sent to KPACS even when stored uncompressed.


    How would you suggest I proceed?


    Nikos

  • UPDATE:
    I tried replicating the process - turned JPEG(2000) off, chose uncompressed for disc storage and now get this error:


    ------------ Adding image files to server -----------
    [UN2CADW14] [recompress]: recompressed with mode = un (strip=0)
    [UN2CADW14] Added file: C:\dicomserver\data\PATID203\1.2.528.1.1001.100.3.3833.461.753637600.20130430145802312_0001_000006_13673446430000.dcm
    [UN2CADW14] ***[DecompressJPEGL]: Could not allocate decompressed image memory.
    [UN2CADW14] ***[DecompressImage]: JPEG library decompression error
    [UN2CADW14] Added file: C:\dicomserver\data\PATID203\1.2.528.1.1001.100.3.3833.461.753637600.20130430145802312_0001_000001_13673447030001.dcm
    [UN2CADW14] [recompress]: recompressed with mode = un (strip=0)
    [UN2CADW14] Added file: C:\dicomserver\data\PATID203\1.2.528.1.1001.100.3.3833.461.753637600.20130430145802312_0001_000002_13673447210002.dcm
    [UN2CADW14] ***[DecompressJPEGL]: Could not allocate decompressed image memory.
    [UN2CADW14] ***[DecompressImage]: JPEG library decompression error
    [UN2CADW14] Added file: C:\dicomserver\data\PATID203\1.2.528.1.1001.100.3.3833.461.753637600.20130430145802312_0001_000003_13673447710003.dcm
    [UN2CADW14] [recompress]: recompressed with mode = un (strip=0)
    [UN2CADW14] Added file: C:\dicomserver\data\PATID203\1.2.528.1.1001.100.3.3833.461.753637600.20130430145802312_0001_000004_13673447830004.dcm
    [UN2CADW14] ***[DecompressJPEGL]: Could not allocate decompressed image memory.
    [UN2CADW14] ***[DecompressImage]: JPEG library decompression error
    [UN2CADW14] Added file: C:\dicomserver\data\PATID203\1.2.528.1.1001.100.3.3833.461.753637600.20130430145802312_0001_000005_13673448050005.dcm


    KR


    Nikos

  • More info:


    Despite the JPEG library decompression error noted in my last post when importing images into ConQuest, the files in the Data directory remain readable by other DICOM software.
    If I then try to anonymize the series the new (anonymized) images written in the data directory are messed up and unreadable... No errors are recorded in the server status during the anonymization process.


    I hope this observation helps pinpoint the problem.


    Nikos

  • Hi Nikos,


    one problem is that the images are too big to fit into memory once uncompressed. So uncompression will always fail. As orginally designed, a failed uncompression will leave the original compressed images. Not sure that the
    new jpeg code in 1.4.16up adheres to that.


    There is a compression naming problem in 1.4.17alpha that is fixed in 1.4.17beta (http://forum.image-systems.biz…c.php?f=33&t=15757#p24694). This may cause the images to become unreadable by others. IK would try to replicate the process with 1.4.17beta.


    Marcel

  • Hi Marcel,


    I updated to the beta. When I first import the DICOMs I get the following:
    ------------ Adding image files to server -----------
    [UN2CADW14] [recompress]: recompressed with mode = un (strip=0)
    [UN2CADW14] Added file: C:\dicomserver\data\PATID203\1.2.528.1.1001.100.3.3833.461.753637600.20130430145802312_0001_000006_13674141180000.dcm
    [UN2CADW14] ***[DecompressJPEGL]: Could not allocate decompressed image memory.
    [UN2CADW14] ***[DecompressImage]: JPEG library decompression error
    [UN2CADW14] Added file: C:\dicomserver\data\PATID203\1.2.528.1.1001.100.3.3833.461.753637600.20130430145802312_0001_000001_13674141790001.dcm
    [UN2CADW14] [recompress]: recompressed with mode = un (strip=0)
    [UN2CADW14] Added file: C:\dicomserver\data\PATID203\1.2.528.1.1001.100.3.3833.461.753637600.20130430145802312_0001_000002_13674141970002.dcm
    [UN2CADW14] ***[DecompressJPEGL]: Could not allocate decompressed image memory.
    [UN2CADW14] ***[DecompressImage]: JPEG library decompression error
    [UN2CADW14] Added file: C:\dicomserver\data\PATID203\1.2.528.1.1001.100.3.3833.461.753637600.20130430145802312_0001_000003_13674142460003.dcm
    [UN2CADW14] [recompress]: recompressed with mode = un (strip=0)
    [UN2CADW14] Added file: C:\dicomserver\data\PATID203\1.2.528.1.1001.100.3.3833.461.753637600.20130430145802312_0001_000004_13674142560004.dcm
    [UN2CADW14] ***[DecompressJPEGL]: Could not allocate decompressed image memory.
    [UN2CADW14] ***[DecompressImage]: JPEG library decompression error
    [UN2CADW14] Added file: C:\dicomserver\data\PATID203\1.2.528.1.1001.100.3.3833.461.753637600.20130430145802312_0001_000005_13674142790005.dcm
    -----------------------------------------------------


    At this point the DICOMs written in the data directory are nicely readable.
    Of note, when I browse the library, the ones that work on import are RGB but the others are YBR_FULL_422 500x500x8bit. The ones that work are also small at about 100 frames compared to about 2000 for the others.


    If I chose to change patient ID that works fine. The ID is changed, the images are moved in the data directory and they do remain readable.


    If I chose anonymize, the database is updated with the new name/ID and the images moved to the new directory.
    With anonymize,however, something bad happens to the larger images and they become unreadable. The smaller ones work fine.


    I hope this helps,


    Nikos


    PS: The GUI still says 1.4.17alpha but the DGATE does report beta on startup

  • Hi Nikos,


    I guess that the main issue is that it tries to uncompress images that then will not fit into memory. Did you try UJ (uncompressed or JPEG) as compression? This should keep the images as is. And you anonymize from the GUI?


    Marcel

  • Hi Marcel,


    I enabled JPEG(2000) and chose the Uncompressed/JPEG storage option.


    It now does not give error on importing:
    ------------ Adding image files to server -----------
    [UN2CADW14] Added file: C:\dicomserver\data\PATID203\1.2.528.1.1001.100.3.3833.461.753637600.20130430145802312_0001_000002_13674306970000.dcm
    [UN2CADW14] Added file: C:\dicomserver\data\PATID203\1.2.528.1.1001.100.3.3833.461.753637600.20130430145802312_0001_000003_13674307420001.dcm
    [UN2CADW14] Added file: C:\dicomserver\data\PATID203\1.2.528.1.1001.100.3.3833.461.753637600.20130430145802312_0001_000004_13674307600002.dcm
    [UN2CADW14] Added file: C:\dicomserver\data\PATID203\1.2.528.1.1001.100.3.3833.461.753637600.20130430145802312_0001_000005_13674307800003.dcm
    [UN2CADW14] Added file: C:\dicomserver\data\PATID203\1.2.528.1.1001.100.3.3833.461.753637600.20130430145802312_0001_000006_13674307840004.dcm
    [UN2CADW14] Added file: C:\dicomserver\data\PATID203\1.2.528.1.1001.100.3.3833.461.753637600.20130430145802312_0001_000001_13674308410005.dcm
    -----------------------------------------------------


    Changing the patient ID works fine (images renamed, moved and still remain readable)


    I then try anonymize (from GUI by right clicking on the patient in the Browse Database tab.


    Things are now worse. Even the small images become unreadable after anonymizing... I also note that although before the small images were turned into RGB and only the large images were UBR_FULL-422 now all of them are like that...


    So - something happens to the images with anonymize that doesn't happen when changing the patientID... Maybe the anonymization messes something in the DICOM 'headers' that makes the images unreadable by other software?


    Nikos

  • Hi Nikos,


    It is good to see the two problems separated.


    I now realize I had not tested 'Make anonymous' in the server GUI for a long time and looking at it now I fear it is broken, it attempts to replace some items in the header but does not generate new UIDS. Which version (date) of cqdicom.dll is on your system. In other words does it come from 1.4.17alpha or from 1.4.16?


    Marcel

Participate now!

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