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.
If it works for the end-user that's a win.
It sounded like your database had the right information and the filesystem was wrong. I was recommending updating the filesystem.
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.
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.
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.
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.
Some filesystems also have issues with the total length of the file path. That's a very long path and looking critically, it's just 0-9 repeated 12 times. What's the purpose of building a path like that?
Look into to using filesystem links if you can't fix your path. You should be able to work around this without needing a CQ change.
I swore I tried that, but I'll give it another attempt.
/edit- apparently I didn't try hard enough
Could the launching switch be an option in the future? it would definitely make this cleaner. I tried to hack it into dgate for the last several minutes but haven't had any success.
Looks like putparam updates the file but the in-memory AEtitle remains what was in dicom.ini at the time of launch.
if I throw a --read_ini: at the instance, it does not adopt the new MyACRNema value. I'm guessing the dgate instance has to be respawned when that changes. It would be excellent if I were able to invoke dgate with myacrnema in the launch string.
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!
The test I did was with 1419d which was built on that box and also 1419b which was built on another box and was functioning properly. Wouldn't the cloned install have the proper parameters?
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.
We only want to generate a new SeriesUID.
I'm going to keep cracking at this and see if I can discover the reason for failure. Will report back.
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?
Yeah an Echo would do the trick.
As for Luas - I've got limited scripting/development experience but do my best. I can't seem to make a good Lua delivery script with retries though I probably should give it another shot.
Forgot to post resolution about this. This was resolved by removing a trailing & from the stats script.
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\""
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:Code--If called "CQUS" and SOPClassUID equals the SOPClass for US Cines, then Obtain the last 7 characters from the SOP Instance UID(SOPSubs) and remove 10 characters from SeriesInstanceUID.--If new SeriesInstanceUID ends in a period, remove 11 characters from the original SeriesInstanceUID.--Concatenates the values from the new SeriesInstanceUID and new SOPSubs to make a unique US Cine SeriesInstanceUID.print('ic-cqus.lua UPACS THREAD ' .. Association.Thread .. ': received an US Cine on AETitle CQUS and has modified SeriesInstanceUID to ', Data.SeriesInstanceUID, 'and updated the SeriesDescription to', Data.SeriesDescription)print('ic-cqus.lua UPACS THREAD ' .. Association.Thread .. ': has destroyed SR object ' .. Data.SOPInstanceUID)