Posts by markpearson

Hi Marcel,
I have been looking at how imagelister handles AETITLE and was wondering if my logic is correct.
./dgate --imagelister:"local|0009703828|1.3.46.670589.5.2.10.2156913941.892665339.860724||"
produces
./data/HEAD_EXP_00097038/0001_002000_892665661.v2*./data/HEAD_EXP_00097038/0001_003000_892665662.v2
but
./dgate --imagelister:"CONQUESTSRV1|0009703828|1.3.46.670589.5.2.10.2156913941.892665339.860724||"
produces
./data/*./data/
with this message in the logs
Locating file:
***Located file on wrong device:MAG0 instead of
Locating file:
***Located file on wrong device:MAG0 instead of

The reason local works is that --imagelister calls ImageFileLister which calls QueryOnImag. The filename and device strings are then returned in the private tags 0x9999, 0x0800 and 0x9999, 0x0801.

The reason CONQUESTSRV1 does not work is that --imagelister calls ImageFileLister which calls VirtualQuery. VirtualQuery calls QueryOnImag which returns the same values, but then calls VerifyIsInDBE which removes fields that are not defined in the image database thereby removing both device and filename and causing the failure further on in ImageFileLister when FindPhysicalDevice is called.

If this is correct do you think it is possible to not filter out the private dgate tags or would this cause other problems?

My understanding is that re-initialize only rebuilds the database. To have the exportconverters run you either have to drag and drop the files or setup a second instance of conquest with the same MAG device and copy all images from one server to the other.

For the second question, which database are you using?
I tried adding { 0xFFFE, 0x00DD, "MyTagItem", 32, SQL_C_CHAR, DT_STR } to dicom.sql using mysql as the database and did a dgate -i and the column was created correctly:

mysql> desc DICOMStudies;
+------------+-------------+------+-----+---------+-------+
| Field      | Type        | Null | Key | Default | Extra |
+------------+-------------+------+-----+---------+-------+
| StudyInsta | varchar(64) | NO   | PRI | NULL    |       |
| StudyDate  | char(8)     | YES  |     | NULL    |       |
| StudyTime  | varchar(16) | YES  |     | NULL    |       |
| StudyID    | varchar(16) | YES  |     | NULL    |       |
| StudyDescr | varchar(64) | YES  |     | NULL    |       |
| AccessionN | varchar(16) | YES  |     | NULL    |       |
| ReferPhysi | varchar(64) | YES  |     | NULL    |       |
| PatientsAg | varchar(16) | YES  |     | NULL    |       |
| PatientsWe | varchar(16) | YES  |     | NULL    |       |
| StudyModal | varchar(64) | YES  |     | NULL    |       |
| StationNam | varchar(16) | YES  |     | NULL    |       |
| Institutio | varchar(64) | YES  |     | NULL    |       |
| PatientNam | varchar(64) | YES  |     | NULL    |       |
| PatientBir | char(8)     | YES  |     | NULL    |       |
| PatientSex | varchar(16) | YES  |     | NULL    |       |
| MyTagItem  | varchar(32) | YES  |     | NULL    |       |
| PatientID  | varchar(64) | YES  | MUL | NULL    |       |
| AccessTime | int(11)     | YES  |     | NULL    |       |
| qTimeStamp | int(11)     | YES  |     | NULL    |       |
| qFlags     | int(11)     | YES  |     | NULL    |       |
| qSpare     | varchar(64) | YES  |     | NULL    |       |
+------------+-------------+------+-----+---------+-------+
21 rows in set (0.01 sec)

I cannot find any mention of --modifyimage in the source code of 1.4.14 so I think think it might be something that Marcel is working on for the next version.

Hi Marcel and group,

My tests confirm that both cfind and dicom print now work on linux with both LittleEndianImplicit and LittleEndianExplicit enabled. This will simplify my setup as I won't have to use separate storage and print servers.

Thanks.

I have used both postgresql and mysql for our nuclear medicine images for a couple of years. Volumes are not large - about 7000 patients and about 250GB storage. Both databases have been quite stable and speed seems OK. I can't compare it to the windows version as I only use it for occasional testing.

I have recently come across an error in one of our nuclear medicine acquisition systems that causes it to occasionally create a duplicate SOPInstanceUID for some files. I only discovered the problem because of an error message like this

Fri Aug 29 14:38:54 2008 ***Error saving to SQL: 1024854/1.2.840.113704.1.111.3996.1201730796.5/1.2.840.113704.1.111.4380.1200880593.13/1.2.840.113704.1.111.2172.1200880624.226.dcm
Fri Aug 29 14:38:54 2008 ***[AddImageFile] Error entering object into server: /pacs/tmp/20080430/NAME_20080828_090331341/NM.1.3.46.670589.28.1.2.2.1972579041.3.2672.0.1209512630

I think the SQL insert failed because it would have created a duplicate index entry on SOPInstanc in DICOMImages as another image with UID 1.2.840.113704.1.111.2172.1200880624.226 already exists.
I can fix this by generating a new SOP with dcmtk, but I was wondering what the correct action of the pacs should be.

You don't need a separate script to make the directories. mkdir with the switch --parents will make necessary parent directories so this should do what you want

ExportConverters = 2
ExportConverter0 = mkdir --parents "/home/dicom/jpeg/%V0010,0010/%V0008,0020"
ExportConverter1 = dcmj2pnm +oj +Wm +Sxv 1024 %f "/home/dicom/jpeg/%V0010,0010/%V0008,0020/%b.jpg"

Check if all the libraries are found with ldd ./dgate it should produce something like this:
libpthread.so.1 => /lib/libpthread.so.1
libsocket.so.1 => /lib/libsocket.so.1
libnsl.so.1 => /lib/libnsl.so.1
librt.so.1 => /lib/librt.so.1
libstdc++.so.6 => /usr/sfw/lib/libstdc++.so.6
libm.so.2 => /lib/libm.so.2
libgcc_s.so.1 => /usr/sfw/lib/libgcc_s.so.1
libc.so.1 => /lib/libc.so.1
libmp.so.2 => /lib/libmp.so.2
libmd.so.1 => /lib/libmd.so.1
libscf.so.1 => /lib/libscf.so.1
libaio.so.1 => /lib/libaio.so.1
libdoor.so.1 => /lib/libdoor.so.1
libuutil.so.1 => /lib/libuutil.so.1
libgen.so.1 => /lib/libgen.so.1

You may need to set the envronment variable LD_CONFIG_PATH first if /libstdc++.so.5 is in /usr/local/lib.

Thanks Marcel,
I have an export filter in the form
ExportFilter0 = StudyDate >= 20080815
where a script updates the date every day which was OK up until postgres 8.3.
I tried this setup on another machine and could not reproduce the problem, and have since changed to mysql on my production machine so I'll have to investigate further.

One thing I did notice was that if the setting in postgresql.conf of standard_conforming_strings is set to off you get the following types of warnings from conquest
WARNING: nonstandard use of \\ in a string literal
LINE 1: ...3234.00', '1', 'MONOCHROME2', '128', '128', '16', 'DERIVED\\...
HINT: Use the escape string syntax for backslashes, e.g., E'\\'.

If you set standard_conforming_strings to on which the release notes say will be standard in the future, then the warning goes away but modality strings like NM\CT are not handled correctly until the DoubleBackSlashToDB is changed to 0.

No file attachment unfortunately. You can expect a lot of warnings, but there should not be any errors.
I will try to download and install solaris 10 so I can compile conquest myself and give you the binary.

For testing, you can ignore the the makefile so you won't have to ask for root access.
The assumptions are that you have gnu make and gnu compiler. Gnu make is not as strict as the sun version and will work with spaces or tabs in the makefile.

First compile dgate. If you don't have the gnu compiler installed you will have to replace g++ with the sun equivalent, probably c++

g++ -DUNIX -DNATIVE_ENDIAN=1 -DNOINTJPEG total.cxx -o dgate -lpthread

This will create a binary using dbase as the database.
Assuming it compiles OK you can then run

./dgate -i
./dgate -vr

The default is to use port 5678 and aetitle CONQUESTSRV1

If you don't need the built-in web interface then the program can be run from any directory. The files you need are:
dgate
dicom.ini
dgatesop.lst
dicom.sql
dgate.dic
acrnema.map

For future reference the reason the name query failed is that the patient name in the database does not contain an underscore so it should be "HEAD EXP2", not "HEAD_EXP2".

Can you specify the problems you have with the linux version? As far as I know it should compile on any posix compatible system. If you post the compiler output someone here may be able to help.

After a quick look at the code, it seems to access the database directly, not via conquest. I think it will only work if you use Mysql as the database.

Check if there are any spaces at the end of parameters in dicom.ini and remove them.
I once had a problem with a space after sscscp that caused the same failed to listen error.

Try initialising the database first and then regen
./dgate -i
./dgate -v -r

If that fails check that the dgate user has write permission for both the database and mag directories.

This is for anyone wanting to use postgersql with conquest. After setting up a new installation with Ubuntu Hardy and intending to use postgresql as the database I came accross the following problem. The most recent postgresql available (8.3) has a number of default behaviour changes that includes casting of non-character types.

Adding images to conquest now produces the message:
***Filter: Unable to query for image record
and the postgresql log has the message:
2008-07-16 09:55:05 EST ERROR: operator does not exist: character >= integer at character 107
2008-07-16 09:55:05 EST HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts.
2008-07-16 09:55:05 EST STATEMENT: SELECT DICOMImages.ObjectFile FROM DICOMImages, DICOMSeries, DICOMStudies, DICOMPatients WHERE (StudyDate >= 20080623) and DICOMImages.SopInstanc = '1.2.840.113704.1.111.2192.1208497733.2553' and DICOMStudies.PatientID = DICOMPatients.PatientID and DICOMImages.SeriesInst = DICOMSeries.SeriesInst and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta AND DICOMImages.ImagePat = '1042021'

The release notes for 8.3 inludes the following section

Quote

Non-character data types are no longer automatically cast to TEXT (Peter, Tom)

Previously, if a non-character value was supplied to an operator or function that requires text input, it was automatically cast to text, for most (though not all) built-in data types. This no longer happens: an explicit cast to text is now required for all non-character-string types. For example, these expressions formerly worked:

substr(current_date, 1, 4)
23 LIKE '2%'

but will now draw "function does not exist" and "operator does not exist" errors respectively. Use an explicit cast instead:

substr(current_date::text, 1, 4)
23::text LIKE '2%'

(Of course, you can use the more verbose CAST() syntax too.) The reason for the change is that these automatic casts too often caused surprising behavior. An example is that in previous releases, this expression was accepted but did not do what was expected:

current_date < 2017-11-17

This is actually comparing a date to an integer, which should be (and now is) rejected — but in the presence of automatic casts both sides were cast to text and a textual comparison was done, because the text < text operator was able to match the expression when no other < operator could.

Types char(n) and varchar(n) still cast to text automatically. Also, automatic casting to text still works for inputs to the concatenation (||) operator, so long as least one input is a character-string type.

Display More

So in this case StudyDate needs to be explicitly cast as an integer, and I suspect there are many other places where it will fail.
My old installation using postgresql 8.1 is still working OK.

It is relativly simple.

Copy the contents of the Conquest directory and put it in a new directory.
Edit dicom.ini and change the following variables:
To avoid network or data clashes: MyACRNema, TCPPort, PACSName, MAGDevice0
Make sure you create a new instance of the database by changing SQLServer
Although not critical, you should also choose a new value for UIDPrefix

Make sure LittleEndianExplicit is disabled in dgatesop.lst. The workstation will not be able to query conquest if it is enabled. On the Jetstream it will even cause the workstation to crash.
If it is disabled you may have to post some of the logfiles for further diagnosis.

Does the ADAC transfer studies as DICOM? The nuclear medicine department where I work has Philips cameras with Jetstream workstations and stores studies in .img format, but converts them to DICOM for import/export.

As far as I am aware Conquest does not have a polling mechanism to automatically check for new studies. If the hospital's ADAC workstation can be setup as a DICOM node then you could either search by date or use "find local missing patients" in combination with forwarding to transfer studies.

A more difficult method is to write a program using findscu and movescu from the dcmtk toolkit to find new studies on the workstation and transfer them. This is the method I use to copy studies from 2 Philips and 1 GE workstation every night.