Hi,
is it possible the empty filenames were stored in the database before somehow? Conquest will reuse earlier generates filenames unless instructed not to do so with:
RenameOnRewrite = 1
Marcel
Hi,
is it possible the empty filenames were stored in the database before somehow? Conquest will reuse earlier generates filenames unless instructed not to do so with:
RenameOnRewrite = 1
Marcel
Hi,
dgate --movestudies initiates a regular C-MOVE. It appears that the image that is transferred there is corrupted somehow, all its dicom tags are empty - and the filename generated reflects that. Can you see/share what it stores? What OS and database are you using?
Marcel
yes,
there are a load of examples in the manual - can you start there?
Marcel
Hi Max,
add something like this to dicom.ini:
ExportConverters=1
ExportConverter0=forward to DICOMNODE
where DICOMNODE is the AE of your node.
Marcel
This is some sample code from lua/anonymiser. The anonymisation happens on reception if enabled.
It should be easy to adjust to your situation.
Use zerobrane studio to control and run it.
Marcel
Hi, is the source a set of folders or a DICOM archive; are you going into or out of conquest?
You can definitively script either.
Marcel
Hi,
You can delete a few but e.g the web viewer may stop working. Are you sure the columns define the database use. Many will be mostly empty and take little space.
I think you can delete these:
[EchoNumber] [varchar](64) NULL,
[NumberOfFr] [varchar](12) NULL, (maybe)
[AcqDate] [char](8) NULL,
[AcqTime] [varchar](16) NULL,
[ReceivingC] [varchar](16) NULL,
[AcqNumber] [varchar](12) NULL,
[SliceLocat] [varchar](16) NULL, (maybe)
[SamplesPer] [varchar](5) NULL,
[PhotoMetri] [varchar](16) NULL,
[Rows] [varchar](5) NULL,
[Colums] [varchar](5) NULL,
[BitsStored] [varchar](5) NULL,
[ImageType] [varchar](128) NULL, (maybe)
[ImageID] [varchar](16) NULL, (maybe)
[qSpare] [varchar](64) NULL,
But I cannot guarantee it does not break certain functionality.
Marcel
Hm,
please try to populate the StudyInstanceUID field in the worklist database.
Marcel
Indeed.
which is the second study that is sent of the pair of conflicting studies.
Marcel
Hi,
really you have to find the root problem which is not Conquest at all. You are trying to force two different patients into the same database row, which conquest rightfully refuses.
But conquest can change anything in the data.
For instance before (re)uploading the conflicting data (e.g. using drag and drop) try to add something like this in dicom.ini:
[lua]
RejectedImageConverter0=Data.PatientID=Data.PatientID..'fixed';script('newuids');retry()
Here script('newuids') replaces all UIDs (like in anonymisation).
Marcel
Hi,
you can script any change that you want. The important question is what you want. The safest option is to change all UIDs, but you then need to know for sure there are only two studies that clash. If you change the study UID you can in principle split every image into a new study and I am sure that you do not want that.
What caused the clash in the first place?
Marcel
Ah, thanks that is an error.
The echo is done by the server to the modality
Marcel
Hm,
can you show a debug log of one transfer?
I nowadays see that virus scanners may cause slow down as well.
Marcel
Ok,
Much better. It now fails on the copy line.
system('copy '..temp..' C:\DICOM_IMAGES\copied')
I think my system() calls expects an executable. For now try:
os.execute('copy '..temp..' C:\DICOM_IMAGES\copied')
Marcel
Which version are you running?
this error occurs when reading a corrupted file on older versions.
Marcel
Hm,
my fault - try:
ImportConverter0 = process study after 5 by test.lua %VStudyInstanceUID
Marcel
Does the script start? The print statement should show in the log. If you use e.g. process study after 5 it will start right away.
Marcel
yes that looks correct.
Marcel
The copy line misses one space before C:\.
Marcel
This looks good.
Is toremote.lua stored in the server folder?
Marcel