Posts by lhendricks

    The images are dicom, themselves, but it uses the format of a 'dicomdir' file with generically labelled folders and dicom files. I think the dicomdir file is a database of some sort so you need to be able to open that file and read it. I'll probably just get efilm workstation and use conquest as a background pacs as needed.

    Hello,


    I'm wondering if there is a way built into Conquest to import scans archived to MO disc by the GE/Irix setup. I'm trying to retire my radworks stations, but as of now they are the only ones I have that can read these studies I have archived to MO disc.


    Thanks,
    Lucas

    1. Even if you are logged in on an administrator account, when installing has issues on Windows 7 in general (as mentioned above) you often have to right click and "run as administrator" for it to work. It might work to right-click and run command line as administrator if you wanted to install it that way.


    2. Services can have permission issues like the above, you may want to set up the compatability tab for the actual exe files (dgateserv.exe and possibly dgate.exe) to always run as administrator (right-click, compatability, change compatability for all users, enable run as admin and probably run as "xp sp 3" also).

    I use conquest primarily for the web viewer. I was just saying "yay" because you said you added jpeg support in this latest version according to the first post. I have just used your format but I will have something new to play with just in case it comes in handy.


    The pre-caching for the web viewer is just a convenience thing for to make a single server setup more robust. One can easily have conquest running on a local workstation for their location, and then users can use the push feature view the web interface to get images to their local server before viewing.


    Any fancy printing features probably are not worth the programming effort unless it's already built into the K-PACS viewer and just needs a button added (K-PACS is what you are creating the web-viewer from, right?).


    Thanks again. These are just my ideas in case you are looking for any. It is great "as is" and has come in handy for me on multiple occasions.

    YAY jpeg through web viewer. The web viewer is such a nice viewer.


    If this is the thread for wishlist items in your next revisions I think automatic image caching in the web viewer would help it's viability over wan connections a lot. Currently it seems as if you must manually click through each image to have it download and cache.


    Then one or two or three versions after that a special print button with various format options =).

    Hey, we've switched to using this in production now as it has gotten so useful. Still on wishlist for webviewer:


    -pre-caching the images as you view
    -either preset buttons for W/C to switch easily to something like bone view, and/or allow dgate.exe cgi to accept w/c levels and set them in the viewer

    The bulk of your data is in the data folder and file size and number of folders would not have a direct impact on database queries. Day to day data queries would come from the tables which are designed to hold millions of records for most database types and still query quickly (assuming a decent database design and query optimization).


    Re-initalizing within Conquest means it's reading the data folder, pulling information from each folder and file and putting info *into* the database which is why it takes a long time. Normal use is to query the database to get locations of files and pull them without having to crawl through the directory structure or read files not specifically pertinent to the study/patient you want to view.


    I would guess you can create a mysql database and then re-index to fill it with info. That is the situation for which the re-initializing is designed for, I think.


    The later versions do have a web viewer. The latest one, in my opinion, is superior to a lot of the paid for web viewers out there. It's simple but functional with the only downside being that it's ActiveX and requires permission to install activex on the target computer to be used.


    P.S. One of my fav things about the Conquest web viewer is it handles image compression on the server side before sending it to the viewer through the cgi. With the dsize option you can make a vpn-friendly low resolution setup so images do not take very long to transmit over a low bandwidth connection. This obviously takes some server resource so you have to balance between overhead on the server and bandwidth usage. You would have to check with Marcel about which dgate.exe is doing the image manipulation (dgate.exe server side or cgi side) to consider if it would be worthwhile to have a separate server running the webview if you do have a high number of web viewers and server overhead is a concern.

    OK -- Just since I was playing with this viewer I am testing this: I prefer the current OCX version over any web viewer I've seen so far. I took my test subject (which was sent and stored uncompressed) and served dicomviewer the images directly from the mag0 mapping and they work fine in dicomviewer.


    If I pass the images via http with dgate.exe as cgi I get the EOFException. When sent and stored uncompressed dgate.exe will serve a viewable image to dicomviewer but it still gives an EOFException and when you use any feature on the viewer IE hardlocks. If it was stored as j2, or served as j2 it gives EOFException and shows nothing.


    These are CT images. If it is sent and received by conquest uncompressed does the file get altered at all? It only seems like when the file passes through dgate to be compressed or via cgi that I get issues with dicomviewer. Although no other viewers have had issues with these files that I've seen. I think with a little better error handling the dicomviewer could be made to work without an issue at least on uncompressed format. Unfortunately his website is down and I don't know if he's ever updating it.

    Jason, how are your images stored? I can only get the Dicomviewer to work when the images are received and stored uncompressed.


    With jpeg lossless storage I could not get images even served by dgate.exe as uncompressed (Not sure if it changes the file to an uncompressed format or just leaves it alone, though). I have mag0 mapped and going directly to the file did not work, either.


    I changed to uncompressed on the server and sent a test study and that opens in the dicomviewer without the EOF related Nullpointer error.


    **I still get EOFException but it shows the image anyway. If I try to do more than one slice, though, it fails. I think I finally just gave up on this viewer. I had these types of issues with every server I tried to use it on.



    Other problems I had with dicomviewer: the basic example references Dicom.dic which is not found in the zip file on his site. I could not use conquest's dicom.dic I had to go find and download the Dicom.dic from the Dicomviewer example. This was the only way I got it to work at all.

    Thanks for the heads up.


    I edited the above code and updated it to strip the correct new header and body tags for replacemet later on and fixed the typo. It is designed for people who know some basics about html and php though so that they can customize their own look and feel. The only real features I add "out of the box" are the kpacs viewer sizing and lowres option.

    This is not a big issue for me because I have no reason not to use nki but:


    I still have issues viewing non-NKI image format through the built-in kpacs viewer. Whenever I switch my server to jpeg lossless the images seem fairly normal in any non-kpacs viewer but the server side viewer and the kpacs web viewer (and the kpacs viewer launched from server browser) have issues with the level and contrast. In kpacs if I crank the W/C over in the multi-thousands the image shows up normal. It's odd. This happens if the images is ever jpeg (if i store it jpeg and serve it to the web viewer as n4, un, or j2 it has this issue). If I store it as nki compression, and serve it as j2 it has this problem. If I store it as nki compression and serve it as un, or nki I have no issues.


    Again it only seems to be the kpacs viewer and server-side viewer with issues. If I grab the image from url (one of the url's used for the viewer) and save as .dcm when it's stored as jpeg and served as j2 then I can open it in ezdicom and view it and it looks normal.


    Your kpacs web viewer is still my favorite one from what I've looked at and I really like getting the images from dgate since it presizes and compresses on the server. I just look forward to flip option(s).

    OK I tossed apache 2.2.9 and php5.2.6 on my workstation and it did NOT like to serve php from the cgi-bin. I have adjusted the file a bit to be more portable with some better coding standards and by default does not use the NTLM (must uncomment that and comment out the no auth to use it). Replace localhost with your webserver's proper domain name and the path after that to wherever you are running dgate.exe from. Put the php file created from the below code anywhere you like now and set the $php_wrapper value to point to that as a url relative to the root ("/path/filename.php") including the file name. The example below has it as index.php in the root directory with dgate.exe running from cgi-bin. I tested this on apache and on IIS with and without the NTLM and it worked for me in all cases. Also this might have some more of the features I've tweaked in like javascript resizing and the lowres option (not sure if I posted the last version before or after I added those).


    Do you get any errors or warnings? The way I have it set up the index.php resides with the dgate.exe but make sure you can actually use php files in that directory on your webserver setup. The script will need some tweaking if you cannot view php files from within cgi-bin. I don't have any windows boxes running apache so I don't have a quick way to test it out. Try putting a file like test.php in the cgi-bin with nothing but: <? phpinfo(); ?> in the file and see if that returns the php config when you go to http://servername/cgi-bin/test.php


    Make sure when you comment out the NTLM part you *uncomment* the $rawstr portion below that for no auth required.

    The viewer that he has created is pretty nice. I hope he will get a chance to add some more of the kpacs viewer features in the near future but as is it's still superior to a few of the commercial web viewers that I looked at. If you are just wanting or needing to develop your own you can use the existing web client to see pretty easily how to grab images for any other client you want to use. Just pass the dicom images that dgate.exe can serve up (compressed or uncompressed) as the parameter for the image. Query the database to get the dicom info and create your pages with links and then pass the below information in the cgi to retrieve images:


    e.g.: (replace yourserver/cgi-bin with the url path to dgate.exe)

    Code
    http://yourserver/cgi-bin/dgate.exe?port=5678&address=127.0.0.1&mode=dicom&slice=524478:1.2.840.113619.2.22.288.1.8754.2.1.20080624.194958&dsize=0&compress=j2


    As of versoin .14 beta this serves a good file for use with a dicom viewer (.13 seemed to have some oddities in format but that might have been my mime setup on webserver). dsize is the actual image max width/height and for remote vpn connections I use 320 as a low res image. It downloads pretty quick that way.


    (j2 being jpeg lossless, un being uncompressed -- that info is in the dicom.ini for web client). You can build your own web client from scratch by interacting directly with the database if you use something like mysql with the native driver or you can parse the dgate.exe cgi pages via something like the PHP wrapper I posted below.


    If you use dgate.exe cgi to get the images then the only API you need to figure out is in the URL for parameters and in the database layout (easily accessible by just viewing the database layout or using an admin tool). You will find more info on the command line stuff he mentioned in the PDF manual found in the server zip. You would just need to create the viewer to accept files via http request and read them as jpegs if you want a faster client.


    EDIT: There are a few open source viewers out there that you could probably adapt instead of writing it from scratch, and some libraries like he used such as ezdicom already built for activex. I have gotten the Java Viewer to work with the uncompressed dgate.exe images but not with j2 yet. I don't think the source for the conquest web viewer is available, though.

    Well we only have one modality and it seems that ideally for a specific study the ImageOrientationPatient would be the same (unless it gets recalibrated or something, maybe).


    On the 2 separate LTD scans I am viewing it shows "-1.0000000\\0.0000000\\0.0000000\\0.0000000\\-0.9396926\\-0.3420201" So if that is a constant I could ideally do something like:
    ImportConverter2 = ifequal "%V0008,0020", "-1.0000000\\0.0000000\\0.0000000\\0.0000000\\-0.9396926\\-0.3420201"; flipimage.exe


    In the flip image executable I could hopefully take the 1st and 5th values and reverse the sign to get the desired effect on the headers and then just flip the image.


    Or will importconverter call an exe? I only see that option on exportconverter in the manual. Thanks for the response this is a really nice system. If I can just figure out this one last thing I think it will be ideal for our clinic.

    Hello, I thought I'd post this question since I'm still fairly new to the dicom standard and headers. Is there a way to use the ImportConverter to detect the orientation of the image and possibly flip it using an external program (such as imagemagick, maybe) and update the header to the new orientation? I've been digging around a bunch so far but this seemed like the best bet.


    Basically any image that our docs look at they want the Right side of the patient to be on the left side (as if they are looking at them face to face). Depending on the type of scan this is not always true so if I can detect and convert a series on the way in then it would remove the step of having to flip the image in the viewer (which isn't built in yet).

    EDIT: I have the low-res link added to my php wrapper which sets dsize to 320. It loaded fairly well over vpn and image quality was not too bad(although there was a noticible degredation).


    Edit2: the inability to flip the images in the viewer is going to to be my #1 suggestion.


    Edit3: To maybe add portability to web interface: if dgate.exe cgi version had an XML switch in dicom.ini to respond with XML instead of HTML it would allow maximum customization of the pages that are viewed. Then eventually it could possibly take XML requests on a custom port instead of needing a cgi interface and respond with XML responses although the cgi interface might still be necessary to provide the actual images to the activex control.



    Original msg:
    For web interface it would be great if it would automatically start preloading the images in the series, not sure if that is an option with the K-Pacs viewer. An alternative to that idea (since it might limit viewing slices not preloaded) might just be a Hi res link and a Low res Link which makes the dsize change. Low-res could be for vpn web viewing and a value of 320 or so would give a fairly quick load time (obviously you lose some quality but if a physician is just needing a quick view over a vpn or something it would be sufficient). Hi res would be the dsize=0 value to give best quality. I'm working on a way to do this just by parsing and editing the html dgate.exe gives back for now.


    Is the source for the ActiveForm in the downloads somewhere? I couldn't find it. I was going to play around (not that I have any business doing much in c++). Really hoping to get a way to flip a series permanently (doesn't have to be a viewer option).

    NOTE: Since I got my integrated auth working with dgate.exe above: If you use IIS with integrated authentication you will need to impliment something like the NTLM proxy described in user contributions on file_get_contents() of the php.net documentation to get access to dgate.exe through file_get_contents(). Alternatively you can just set the file security as anonymous access, but if you are looking for a smooth security setup with no extra logins then you can get it working like this. The latest version only allows connections from the local host by default so it's pretty secure.


    EDIT: Here is an updated version that works with the NTLM proxy for IIS6 integrated auth on dgate.exe. Make this into index.php in your dgate.exe directory and go in and set the $app_base variable either in this file or in a separate file to use in the require() line. This also gets more specific on the dgate.exe replacements to fix a problem viewing images outside of the viewer and creates a link on the viewer page to see a Low Res series view (max dsize=320) for faster image loading. See file comments for more info:


    See newest version below


    Lucas