Posts by garlicknots

    I'm starting to see some very very large ultrasound cine clips and have begin running into issues with 32bit memory spaces. While the vendor of the imaging device is looking to resolve this at the source, I'm hoping to come up with a tactic to split the multiframe into single frames. Curious if anyone here has already weaved this into a lua script or other exportconverter.

    Hi,


    NEVER use V2 with modern images. Your only salvage would be to look in the images, and make sure that all sequences in there are known in dgate.dic.


    Marcel

    What do you recommend Marcel? We're beginning to handle very large ultrasound content and I'm running into compression bottlenecks. Our cluster is 4 hosts for HA and throughput but they are only 3cpu/3gigs of mem so we are going to need to bump that up. We prefer jp2k generally and have not yet moved to 1.5 though I'm trying to make some progress on that today.

    hammad I've had a similar challenge in the past and was never quite able to come to the right workable solution. Marcel has a stickied post on the forum about not changing patient IDs in this manner. I didn't like the UID regeneration so I never actually went through with it.


    Why not to change patientID of a dicom image


    Adding to the complexity depending on your use-case, you end up also with the object in memory with metadata different than the object on disk.

    I really would like the ability to control the data like you, but cq's architecture doesn't support it.


    You could update the Lua (or call another) and have it rename the folders as it updates the objects.


    I've not tried it and the idea only came to me while writing this, but you may be able to have the ImportConverter do something a bit tricky.


    pseudo

    ImportConverter0 = Update Patient ID, Delete stored study(not destroy!), forward study-level to ImportConverter1

    ImportConverter1 = Whatever your normal importconverter rule would be



    As for modifying your saved data, I've got no experience there so I'd be hacking it together probably with an OS-hosted script.

    We run a cluster of 4 nodes and would like to enable query/retrieve through them. Currently, they each go by the same AEtitle as we have replicated the dicom.ini to each server. We continue to enforce config versioning through a git-managed stream. All servers in the cluster pull their dicom.ini from a single git project. This way we have to change only 1 location and we have proper replication, with historic versioning, available for rollback.



    The problem is that MyACRNema is the same for all app servers. While Query works, Retrieve most often results in the move-through store being load balanced to the wrong node.


    Can we launch dgate from the command line with parameters including MyACRNema? Does this parameter dynamically update and would putparam be a viable option?

    Somewhat common with our instances of dgate as well. For our service start and service restart, we put in something like 100 tries before it fails. If you do a netstat -aln you will see there are still living sockets on 5678.


    I've found smaller instances with less work more reliably terminate dgate rapidly.

    Built on an Ubuntu 18.04 and 16.04 box and did not have the same problem. Guessing it's something to do with the glibc libraries that are standard in different distributions. We're probably going to migrate the cluster to Ubuntu based on this.


    /edit: for fun I changed the pdu parameter to 256k without the if/else. Builds still work even with that!

    I've built a new environment for a new project. It's running CentOS7 as that is our standard flavor given the scoping towards Enterprise roles.


    I've now run 1419d and 1419b (copied from a known-functional host) on this new box and am seeing the same odd image interleaving I've never seen CQ do before. When I retrieve these images from any number of different viewers, this problem remains. I'm about to blow up the VM and take a clone of a previous environment. I was hoping to start fresh and create some new standards for our implementations moving forward. Any thoughts Marcel?


    This occurred today. I was able to use the webserver to move the object to the destination successfully. It's got something to do with the object in memory in the ExportConverter.


    I wonder if this could be resolved by adding some sort of a time buffer on the ImportConverter so that cine clips aren't released to export converters for X number of seconds.

    We have 4 nodes in a balanced cluster each with their own DB. Would the changeUID function result in differing UIDs on each environment if repeated sends were balanced to other nodes?


    We haven't really considered using shared storage or a shared db for these systems, but doing so could possibly help with tasks like this.

    Hi Marcel


    We have this method in place because we wanted to ensure the UID generation was unique per exam and not per send. With newuids, someone could send the same dataset repeatedly and duplicate it, couldn't they?


    When you mention inconsistent dataset, where would the inconsistency be? The filesystem / the database?


    The edit occurs on a single object, creating a new series. I am not clear on how an inconsistency with the UIDs can exist. This runs on an ImportConverter, so it should all be pre-filesystem & db, right?

    Forgot to post resolution about this. This was resolved by removing a trailing & from the stats script.


    export reporter:

    curl -i -XPOST 'http://0.0.0.0:8086/write?db=conquest_stats' --data-binary "conquest_exports,hostname=`hostname -s`,destinationae=$1,modality=$2,calledae=$3,state=$4 callingae=\"$5\",sopuid=\"$6\",mrn=\"$7\",accession=\"$8\""


    import reporter
    curl -i -XPOST 'http://0.0.0.0:8086/write?db=conquest_stats' --data-binary "conquest_imports,hostname=`hostname -s`,modality=$1,calledae=$2 callingae=\"$3\",sopuid=\"$4\",mrn=\"$5\",accession=\"$6\""

    We have an issue with our diagnostic viewer which causes cine clips to sometimes to blend in the stack of stills when we'd like to have them easily identifiable as cine clips.


    To split these clips, we built a lua which generates a new (and consistent) series instanceuid and changes the series description to CINE. This fires properly, but at times it writes an object which will not successfully export. This is not consistent. I do not know how to make it fail and I do not have access to a study which will cause this issue. We see it several times a month.


    I noticed yesterday that when this file is written, it's a DCM file instead of a v2.

    We use FileNameSyntax=3 so I'd expect to see a v2 object.


    Here is the lua: