Compression and routing problem

    Hi!

    I'm struggling with the following situation:


    Two sites (A and B) connected by a 10 Mbps symmetric link.

    Site A: two modalities (Elscint Twin CT Scanner and Philips Intera 0.5T MRI Scanner).

    Site B: two DICOM storage nodes: a PACS (Carestream VuePACS) and a Disc Publisher (Codonics Virtua).

    Due to the small bandwith, the image sending from A to B is painfully slow (upgrading the link is impossible right now due to ISP restrictions).

    So I mounted Conquest in site A acting like a dicom router: compressing and sending studies to their corresponding destination.

    However, if I use JPG-2000 or JGP-LS for image compression, Conquest fails with a "OPENJP2: compress input data out of range" error message.

    So I ended up using JPEG-Lossless instead (that works). The problem is, that neither the PACS nor the DiscPublisher recognize the compression type, so I had to install a second "Conquest-Router" in site B that basically does the reverse operation, that is, receives compressed images from Router-A and send them uncompressed to each node in site B.


    I set up this so far (names are fictitious as an example):


    SITE A


    - Both modalities have the site B destinations with their respective AE Titles, but the IP address and port of Router A instead.

    - Conquest 1.4.19b running in Windows 7 with SQLite DB (and cleanup at night) and listen at 5678.


    ACRNEMA.MAP:

    ROUTER_A 127.0.0.1 5678 un

    PACS <ip_addr_router_B> 5678 j2

    DISC_PUB <ip_addr_router_B> 5678 j2


    Rules:

    ExportConverters = 4


    ExportCallingAE0 = CT_SCANNER

    ExportCalledAE0 = PACS

    ExportConverter0 = forward compressed as j2 to PACS org CT_SCANNER


    ExportCallingAE1 = MRI_SCANNER

    ExportCalledAE1 = PACS

    ExportConverter1 = forward compressed as j2 to PACS org MRI_SCANNER


    ExportCallingAE2 = CT_SCANNER

    ExportCalledAE2 = DISC_PUB

    ExportConverter2 = forward compressed as j2 to DISC_PUB org CT_SCANNER


    ExportCallingAE3 = MRI_SCANNER

    ExportCalledAE3 = DISC_PUB

    ExportConverter3 = forward compressed as j2 to DISC_PUB org MRI_SCANNER




    SITE B


    - Conquest 1.4.19b running in Windows 7 without database (null).


    ACRNEMA.MAP

    ROUTER_B 127.0.0.1 5678 un

    PACS <ip_addr_PACS> 2104 un

    DISC_PUB <ip_addr_DISCPUB> 104 un


    Rules:

    ImportConverter0 = ifequal “%c”, “PACS”; { forward to PACS channel *; destroy;}

    ImportConverter1 = ifequal “%c”, “DISC_PUB”; { forward to DISC_PUB channel *; destroy; }


    The above works and the transfer speeds increased considerably! ...but the problem that arise now is:


    How to make Conquest Routers "AE Title-transparent"? (in the sense that the PACS and DiscPublisher believe they are communicating directly with the modalities).


    Looking at the studies that are stored in the PACS, it seems that the calling AET is modified and replaced with the conquest AET (ie: ROUTER_B). How can I change that so the original (ie: the modalities) AET remains ? ¿It's that possible?


    And why does Conquest fail to compress with that message? Don't know where to start looking...


    I read the DICOM Conformance Statement of VuePACS and says it supports JPG-2000 maybe by solving that I could spare the Conquest in site B and avoid the problem of the AET at all.


    Any help is appreciated. Thanks in advance! (and sorry my bad english, i'm from Argentina).

    Good work,


    data out of range happens when the header says it is 12 bits, and higher values are used. These cannot be compressed hence the error message. Futher, the 'forward' command ORG clause can also be used in server B where you can pass the AE to be used, e.g. the receiving AE. You should be able to use that.


    regards,


    Marcel

    Thanks for the quick reply Marcel!

    I'll check the header of the images from that modalities to see what is going on with the bit depth.


    Regarding the rules, yes, I thought about adding the ORG clause in the ImportConverter rules, but in that case, how many rules should I create? Four rules? Because I would have to identify where each image comes from and make two chained ifequal-blocks. That is, first compare the calling AE to see the origin and then compare again, but this time the called AE to to check where its going. And the append the ORG clause with the modality name. Right ?

    Or maybe I can just to make two rules like above and simply use a variable?

    I mean something like this:

    ImportConverter0 = ifequal “%c”, “PACS”; { forward to PACS channel * ORG "%u"; destroy;}

    ImportConverter1 = ifequal “%c”, “DISC_PUB”; { forward to DISC_PUB channel * ORG "%u"; destroy; }


    Thanks again!

    You're right, I was overcomplicating things!

    I replaced the rules in both sites with just the one you indicated and now it works flawlessly. Thanks!


    Regarding the compression error, I checked the headers and I have:


    Allocated Bits: 16

    Stored Bits: 12 (*)

    High bit: 11


    which is consistent with CT images.


    (*) However, inquiring a little more I realized that this equipment is quite old (Elscint Mx Twin) and that it stores information of the overlay data in the 4 unused bits of the PixelData. So I took a couple of files and pass them thru the gdcmconv tool to remove this overlay data (gdcmconv --raw --force <input.dcm> <output.dcm>) and then re-imported them into Conquest. This time the compression went without problems !


    So now, how can I make Conquest ignore / remove that overlay data from the 4 unused bits? It's that possible?


    Thanks again.

    Hi,


    You might try something like:


    [lua]

    ImportConverter0 = if Data.Manufacturer == 'Elscint' then Data.BitsStored=16 end


    You can write a lua script to remove the high 4 bits, using Data:GetImage() and Data:SetImage but that would be very slow. You can also potentially run gdcmconv for every image.


    regards,


    Marcel

    Marcel,


    I tried the lua script that you suggest. It doesn't fail but it doesn't work either.

    I also tried this:


    ImportConverters = 1

    ImportModality0 = CT

    ImportConverter0 = set 0028,0101 to 16


    but it doesn't work, the image still has 12 bits in the BitsStored tag. However with similar rules I can change others tags, strings for example, therefore I assumed that it would be the missing quotes. But no, doesn't work with: set 0028,0101 to "16" (nor '16').

    In a last attempt, I tried to copy the value of one tag to another: BitsAllocated to BitsStored (set 0028,0101 to "%V0028,0100") but it doesn't work either.
    What am I doing wrong ?

    :-/

    Hi,


    this lua code works for me:


    print(Data.BitsStored, Data.BitsAllocated)

    Data.BitsStored = 16

    print(Data.BitsStored, Data.BitsAllocated)

    Data.BitsStored = 12

    Data:Script('set 0028,0101 to "16"') -- the "" are necessary

    print(Data.BitsStored, Data.BitsAllocated)


    It prints


    1216

    1616

    1616


    I tested it by opening an image in the browser, right click modify-this image (advanced), and then test syntax.


    Of course an importconverter only runs when an image is loaded. If you want to modify the image going out use

    RetrieveConverter0.


    Marcel

    Marcel, you're right!

    The script works, and the importconverter rules I had tried works too!


    My problems were two:


    1) The quotes are indeed necessary, but I had to put a space after the number and before the last quotes, only then the rules work: set 0028,0101 to "16 "


    2) the viewer I was using, MicroDicom, shows me that the image still has 12 bits stored, even though I made the modification! That's why I thought it did not work. When I open it with other dicom viewers, they show me correctly that BitsStored=16 (in fact, it was much easier to check it from ConQuest itself by right clicking the image and then clicking on Show Header ... do'h! :-P.


    Now, while the rules work, I notice that it still gives the error of OpenJP2 when receiving images, so I suspect that the ImportConverter rule is running after the image was stored and compressed.


    What should I do to apply the rule before the compression of the received images?

    Hi,


    Indeed, you can try this, a scripted compressor:


    IncomingCompression = s0


    [lua]

    CompressionConverter0= if Data.Manufacturer == 'Elscint' then Data.BitsStored=16 end; Data:Compress('JS')


    Marcel

    Solved!


    Carefully inspecting the CS PACS configuration I found that JPG-NH14 transfer syntax was supported... but disabled (facepalm).

    Once enabled, I deleted ConQuest from site B, leaving only site A and now I send to both destinations (PACS and DiscPub) in a compressed and transparent manner.

    Since J2 compression does not fail with the CT images, it works.

    Thank you very very much for the help Marcel.


    In fact I liked ConQuest so much that I'm considering using it to build a dicom archive, due to its simplicity, versatility and small footprint (but I think that's better to leave it for another thread).

Participate now!

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

Register Yourself Login