and important question:
what dgate.exe do first, when IMG incoming (when we use Import Converter and use 'set TAG to')?
1. parsing TAGS, WRITE Fields in DB, Change TAG in IMG files
2. parsing TAGS, Change TAG, Write Fields in DB
Posts by kochan
-
-
Now we use a some Hack trick ))
but still search normal way to transfer IMG
when IMG incoming and TAGs parsing in database filds,
we change Private Fuji TAGs directly in DB ( 0002,0002 to 1.2.840.10008.5.1.4.1.1.1; 0008,0016 to 1.2.840.10008.5.1.4.1.1.1)after this manipulation - IMG transfered to viewer ok
-
we can modify DICOM Tags when receive or transfer images?
this correct syntax - we change private FujiPrivateCRStorage (1.2.392.200036.9125.1.1.2 ) to "Default CR Storage" ?
ExportConverter0 = set 0002,0002 to 1.2.840.10008.5.1.4.1.1.1; -
add some info...
dump DICOM handshaik (WIREDSHARK):
normal Association and transfer file to DICOM-viewer
Association and terminate connection
-
Quote from marcelvanherkDisplay More
Hi,
to me this suggests the viewer does not accept the images (I assume this happens when you click to view the image in e.g. efilm and it initiates a move. They were loaded in conquest alright I suppose?
I do not believe there is a script/method to override the sopclass/modality of outgoing images in conquest (it is part of the association negotiation). The best would therefore be to see if you can get the viewer to accept the images.
Marcel
Yes, all images on PACS server (Conquest)... but now situation more interesting:
CR images from old archive (2014y) - all ok,
new CR images from devices - problem.
at the same time on production PACS FUJI (we use Conquest as backup system) - new CR and old CR and all images - ok - download and view
we use only two dicom-viewers - RadiANT and efilm (in tests IQview) and switch between two PACS SYSTEM
-
Hi all!
we have a some problem with transfering CR images between PACS server and DICOM-Viewers (use eFilm and Radiant)
Conquest logs have records :
20151223 16:40:17 ***No valid presentation contexts/transfer syntax found in 0 candidates
20151223 16:40:17 ***In 0 presentation contexts
20151223 16:40:17 ***#Possible transfer syntaxes: 1
20151223 16:40:17 *** multiplex: connection terminatedother images transfering ok (CT,DX, MR, US\SR and etc)
-
Quote from marcelvanherkDisplay More
Hi,
please read post "Why not to change patientID of a dicom image". It relates to a conflict of UIDs that conquest cannot resolve.
regards,
Marcel
OK, i understand! ))
thank for quick answer Marcel
-
Hi all!
sometimes when we send studies (changed studies) from MRI to PACS and have errors in log:
20.11.2015 14:56:11 [DICOMSTORE] ***Error: 2627: 23000: [Microsoft][ODBC SQL Server Driver][SQL Server]Нарушено "PK__DICOMIma__64587BE62331993A" Violation of PRIMARY KEY constraint . Cannot insert duplicate key in object "dbo.DICOMImages". Value: (1.3.46.670589.11.32179.5.0.4596.2015112009235493980).
20.11.2015 14:56:11 [DICOMSTORE] ***Unable to DB.Add()'Conquest' not update fields in table if they exist?
-
Quote from marcelvanherk
Hi,
it should be very stable on the latest release (use the 1.4.17e update). I would use windows as the setup is easier. It makes no difference in speed.
Marcel
Thanks for the quick response!
-
Hi all!
We have a plan to use Conquest for routing dicom between different PACS system.Most interesting variant for us - is dicom routing without database, and we have some question about this:
1. How stable this option in release 1.4.17d for high load
in manual we have : "Before version 1.4.17b, this form of DICOM routing crashed the server under high load."
in 1.4.17d - OK ?
2. What preferred Operating System and system requirements (CPU\RAM) for this configuration :
Linux (Ubuntu, Centos and etc) or Windows ?Planning average load on this dicom-router :
Modalities CT\CR\US\DX\MR\XA
Number of studies per day 300
Storage for DICOM data in GB per day 40\\\PS
sorry about my eng
