Posts by marcelvanherk

Hi,

you can use servertask.exe or dgate with -q and -p options to do this remote.

See Conquest-DICOM-Server\webserver\node_qido_wado\api\api\routes\dicomRoutes.js

for some example code

Marcel

Hi,

you can move data to an archival device, and as it is moved change the compression (this is ArchiveCompression in dicom.ini; default 'as' is no change; but j2 compresses only slightly better than n2). Moving is always done actively using:

dgate -as

dgate -am

E.g.

dgate -v -as1000000,0

dgate -v -amMAG0.Archiving,MAG10

Moves 1GB (1000000 kB) of data from MAG0 to MAG10

The GUI option "nightly move data" uses these two calls.

There is no method to forbid conquest writing directly on MAG10, if MAG0..MAG9 are full it will write to MAG10.

Marcel

Hi,

I guess any MAG can be considered an ARCHIVAL MAG, you should just stop writing there. While moving between devices you can change the compression. Conquest also has an old mechanism to archive to a DVD jukebox but that is probably not very helpful.

Marcel

Hi,

Queues are kept in memory and in binary files indeed; this has not changed.

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

local TrialID = TrialID or 'trial1'
local PACS = 'CONQUESTSRV1'

require('csv')

subjects = readCSV('keytables/'..TrialID..'.csv')
for k, v in ipairs(subjects) do
  q = DicomObject:new()
  q.PatientID = v.PatientID
  dicommove(PACS, 'ANONYMIZER', q)
end

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