Posts by marcelvanherk

    Hi,


    The next version (1.4.14a) will have a script file "anonymize_script.cq" , that has the same syntax and function as an importconverter, i.e., it can modify any dicom tag. Furthermore it will update all UID's, including those in deep sequences.


    As for Steini, the same new functions that do the anonimization ("newuids except", and "set gggg,eeee to"), can be called from an importconverter. The link between the original UIDs and new UIDs is kept in table UIDmods. So in priciple, it could be possible to make the process reversible. The same could be made to hold true for the patientID.


    To de-anonymize on retrieve, you need to take a query object, anonymize it (so that the right patient is found), and de-anonimize the results on retrieve. The anonymization of the query object will be possible in 1.4.14a (with command QueryConverter0), but there is nothing yet for de-anonymization.


    Marcel

    Hi,


    V* and S* are wildcard AE's that are explained in the manual:


    "Conquest addition: this file supports a simple wild-card mechanism. The AE, host name and IP port may all end on a *. The * part of the AE is copied into the host name and/or IP port without change. In the following example any application with an AE of “V” followed by its IP number or host name will be allowed to communicate through port 1234. The wildcard option is highly useful to let a group of, e.g., viewer applications or servers communicate without having to configure each of them individually in the server. "


    If you put anything starting with an V or an S below them, they will NOT be read. You have no problem because your items do not start with a V or an S.


    Marcel

    Hi,


    we have not observed the issue because we read almost all our data series by series. The problem is that the virtual server code gets an unsorted list of requests, which is than has to reassemble in one or more moves. The logic is:


    if all images belong to same patient, study and series, move all at once (specifying patient/study/series and a list of sops), otherwise move image by image.


    I can change the code, and send you a prerelease, but that would be experimental, since it is a fairly major change. Would you test it for me?


    Marcel

    Hi,


    why is your application getting images one at a time? The problem is that every virtual query has to do a long query of the conected server. If you get a while series at once, all queries will be assembled to one and it will be much much faster.


    To test, try to access the virtual server from another conquest server, and see what happens then. We use the virtual server all the time and it is really fast.


    Marcel

    Hi,


    Try using "forward series to XXXXX" or "forward study to XXXXX". This will wait a while and then asynchroniously send the entore recieved series/study over a single association. The queue for forward should probably be thousands of images for it to not slow down the server, especially when the server being forwarded to is slow.


    Marcel

    Hi,


    Take care: this feature has been tested with MSSql only, and will may work (but is untested) with MySQL. It will fail with the more simple database driver. An indeed, with that feature each server will have another port. I am not sure it will solve your problem though. Did you figure out why your server is slow?


    Marcel

    Hi,


    From the log you can see the last succeeded file during regen .. and go from there. You can test suspicious files with OFFIS tool DCMDUMP. Or you can run dgate --testimages:MAG0 (if you have a database). But that will crash just like regen on the first corrupt file. But probably there are just a few (power failure is the most common file corruptor).


    In the next release, the readers will be better in detecting and skipping corrupt files.


    Marcel

    Hi,


    this error occurs when a DICOM image is corrupted on disk: the reader gets out of sync, and reads a really large number as VR length. Normally IgnoreOutOfMemoryErrors gets you past that - you did restart after changing the flag?. The other option is to locate and remove the corrupted file(s).


    Marcel

    Hi,


    indeed this is the case. dcmcjpeg cannot compress the image. The uncompressed image is then left in the printer_files directory and can be inspected to see what goes wrong, for instance by giving the dcmcjpeg command (as show in the log) yourself. The code is such that failure of dcmdjpeg or dcmcjpeg will not lead to data loss: the original image is kept when that fails.


    Marcel

    Hi,


    Sorry, no mpeg export for now. I am looking for a good mpeg code that would not require dozens of source files.


    I am adding jpeg export in 1.4.14a, and maybe animated gif.


    Marcel

    For the record,


    we came up with the following extension for 1.4.14a:


    There are 3 (only) extra converters, which can do similar things as ImportConverter0..9 can do, including logging and modifying the query, conditionally abort the query, start executables and much more.


    If you add these lines to dicom.ini as a test, the server will log calling (%u), called (%c) of each normal query (first line) and worklist query (second line). The move shows calling and called plus the destination (%s) of each move.


    You can read all query items using %Vgggg,eeee, and you can change or add items, e.g., to allow limited access for certain stations.


    Code
    QueryConverter0 = nop This is a query: from %u to %c with patient %i
    WorkListQueryConverter0 = nop This is a workListQuery from %u to %c with patient %i
    RetrieveConverter0 = nop This is a retrieve from %u to %c destination %s patient %i


    Marcel

    Hi,


    I have no clue, maybe a firewall issue, or an automatic update that broke something? You could try to install conquest on your e-film station and check basic connectivity. Dis you also try to rebuild your e-film database?


    Marcel

    Hi,


    you can do that. An easy alterative is to define the same conquest server twice in your scanner with different AE's: e.g., conquest_thin, and conquest_thick with the same IP and port. You would forward thin slices in their protocol to conquest_thin and thick slices in their protocol to conquest_thick: the exportconverters can test the called AE to specify which forwarding to use.


    This has the advantage that is does not require substring matching, which is not available at present, and does not deped on editing human-readable strings.


    Marcel

    Hi,


    if e-film won't recieve from conquest (when conquest is sending), then the configuration of conquest in e-film is probaly incorrect. You have to double check that e-film knows conquest and conquest knows e-film.


    Marcel