[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Aeskulap-users] aeskulap dicom issues
|
From: |
pipelka |
|
Subject: |
Re: [Aeskulap-users] aeskulap dicom issues |
|
Date: |
Thu, 12 Apr 2007 16:18:49 +0200 |
Mitchell,
Trust me, I'm quite familiar with the DICOM protocol (it's my business for a
couple of years now). I just need a testing environment for debugging. I just
wanted to avoid the full setup of the CTN environment.
You think it's wrong to form a query without a fixed PatientID. But i think
it's allowed.
The DICOM Standard (Base 2007) about Query/Retrieve (PS 3.4 2007):
C.2.2.1.1 Unique Keys
...
C-FIND, C-MOVE, and C-GET SCPs shall support existence and matching of all
Unique Keys defined by a Query/Retrieve Information Model. All entities managed
by C-FIND, C-MOVE, and C-GET SCPs shall have a specific non-zero length Unique
Key value.
C.2.2.2 Attribute Matching
The following types of matching may be performed on Key Attributes in the
Query/Retrieve Service Class:
— Single Value Matching
— List of UID Matching
— Universal Matching
— Wild Card Matching
— Range Matching
— Sequence Matching
Matching requires special characters ( i.e. “*”,”?”,”-”, and “\”) which need
not be part of the character repertoire for the VR of the Key Attributes.
C.2.2.2.3 Universal Matching
If the value specified for a Key Attribute in a request is zero length, then
all entities shall match this Attribute. An Attribute which contains a
Universal Match specification in a C-FIND request provides a mechanism to
request the selected Attribute value be returned in corresponding C-FIND
responses.
---
PatientID is a Unique Key, so it's a Key Attribute and universal matching is
allowed. I didn't find anything in the Standard about fixed only unique keys.
It would be much easier for me if I would know that the 'simple_storage' server
is performing the right conformance checks.
BTW, which version of the ctn are you using ?
Alex (some kind of confused)
---- Mitchell Laks <address@hidden> schrieb:
> Dear Alex,
>
> Look at the error message I sent you:
>
> STUDY level query, Patient Root model is missing Patient ID (0010 0020) or
> has extra PATIENT level attributes
> Find callback
>
>
> You are making a study level query in the Patient Root Model with NO FIXED
> PATIENT ID. This is illegal dicom query.
> You can only descend to study level query with patient root model with fixed
> patient id.
> then you cannot send patient name at that level ( i think).
> If you dont belive me look at the comp.protocols.dicom and dcmtk forum. ask
> other people. Ask david clunie or
> the dcmtk people.
>
> You have to have differently composed queries (correspond to complex -P -S -k
> options in findscu)
> depending upon what you are sending and expecting. To see the complexity of
> this work,
> Look at the confusion that engenders by googling at google groups for Q/R
> findscu options and see
> how many times people get it wrong by setting up wrong query. You set up a
> bad query. It is expected
> until you get it right :).
>
> I don't know what you setup with simple server.
>
> Ok the proper testing environment is to set up
> a full CTN server.
> Thus you want to populate the mysql databases
> CTNControl and LTA_IDB, each of which has a lot of tables
> and start the archive_server and archive_image processes
>
> (it has been a long time since i used the mysql version ... I use
> postgreql version in my work, and have private scripts that set up all
> of the proper tables)
>
> The best way for you to do it, is to look at CDMEDIC pacsweb by Pablo sau (he
> is very interested
> in your project by the way). He does all the full mysql based set up for you
> with web based scripts.
>
> Unfortunately, I did the same test you did and got same error as before.
>
> You are simply doing a ill formed dicom query.
> The nature of the beast is that you have to change the list of attributes you
> are
> querying depending upon what you want to get back, and what you are offering.
>
> You need to have a lot of branching statements i suspect.
>
> Look at all the questions about the dicom query retrieve confusion on
> comp.protocol.dicom. and the forum.dcmtk.de
> and you can see you are walking in a minefield until you get a working
> acceptable query.
>
> If you are working with a "tolerant" archive which supports INVALID queries,
> you won't know until
> you test against something like Wustl CTN which is designed to reject
> _everything_ unless it is precisely correct.
> Thats why the medical manufacturere have connect-ithons every few months in
> chicago to check this kind of thing out.
>
>
> here is the output from "both sides" with the query you just described with
> no name.
>
> Notice the error message on both sides:
>
> (0000,0902) LO [Query was formatted improperly. Check required keys] # 52,
> 1 ErrorComment
> T::Drop()
>
>
> STUDY level query, Patient Root model is missing Patient ID (0010 0020) or
> has extra PATIENT level attributes
> Find callback
>
>
> You are making a study level query in teh Patient Root Model with NO FIXED
> PATIENT ID. This is illegal dicom.
>
> MItchell
>
>
> aeskulap output:
>
> datadir: /usr/local/share
> trying to load '/usr/local/share/aeskulap/images/grid-1.png'
> trying to load '/usr/local/share/aeskulap/images/grid-2h.png'
> trying to load '/usr/local/share/aeskulap/images/grid-2v.png'
> trying to load '/usr/local/share/aeskulap/images/grid-4.png'
> trying to load '/usr/local/share/aeskulap/images/grid-16.png'
> trying to load '/usr/local/share/aeskulap/images/stock-tool-scale-22.png'
> trying to load '/usr/local/share/aeskulap/images/stock-layers-24.png'
> trying to load '/usr/local/share/aeskulap/images/series-1x1.png'
> trying to load '/usr/local/share/aeskulap/images/series-2x1.png'
> trying to load '/usr/local/share/aeskulap/images/series-2x2.png'
> trying to load '/usr/local/share/aeskulap/images/series-3x2.png'
> trying to load '/usr/local/share/aeskulap/images/series-3x3.png'
> trying to load '/usr/local/share/aeskulap/images/series-4x4.png'
> trying to load '/usr/local/share/aeskulap/images/stock-tool-eraser-22.png'
> trying to load '/usr/local/share/aeskulap/images/cursor_pan.png'
> trying to load '/usr/local/share/aeskulap/images/stock-tool-measure-22.png'
> trying to load '/usr/local/share/aeskulap/images/aeskulap.png'
> prescan: 0
> on_windowlevels_modality_changed() - indexint: 0
> StudyManager::on_filter_search()
> turning cursor busy
> NEW QUERY:
>
> # Dicom-Data-Set
> # Used TransferSyntax: UnknownTransferSyntax
> (0008,0005) CS [ISO_IR 100] # 10, 1
> SpecificCharacterSet
> (0008,0020) DA (no value available) # 0, 0 StudyDate
> (0008,0030) TM (no value available) # 0, 0 StudyTime
> (0008,0052) CS [STUDY] # 6, 1
> QueryRetrieveLevel
> (0008,0061) CS (no value available) # 0, 0
> ModalitiesInStudy
> (0008,1010) SH (no value available) # 0, 0 StationName
> (0008,1030) LO (no value available) # 0, 0
> StudyDescription
> (0010,0010) PN [*] # 2, 1 PatientsName
> (0010,0020) LO (no value available) # 0, 0 PatientID
> (0010,0030) DA (no value available) # 0, 0
> PatientsBirthDate
> (0010,0040) CS (no value available) # 0, 0 PatientsSex
> (0020,000d) UI (no value available) # 0, 0
> StudyInstanceUID
> (0020,0010) SH (no value available) # 0, 0 StudyID
> QueryServerGroup()
> T::SendObject()
> Status Detail:
>
> # Dicom-Data-Set
> # Used TransferSyntax: LittleEndianImplicit
> (0000,0902) LO [Query was formatted improperly. Check required keys] # 52,
> 1 ErrorComment
> T::Drop()
> T::Destroy()
> cursor busy off
> no results !!!
> StudyManager::on_filter_search()
> turning cursor busy
> NEW QUERY:
>
> # Dicom-Data-Set
> # Used TransferSyntax: UnknownTransferSyntax
> (0008,0005) CS [ISO_IR 100] # 10, 1
> SpecificCharacterSet
> (0008,0020) DA (no value available) # 0, 0 StudyDate
> (0008,0030) TM (no value available) # 0, 0 StudyTime
> (0008,0052) CS [STUDY] # 6, 1
> QueryRetrieveLevel
> (0008,0061) CS (no value available) # 0, 0
> ModalitiesInStudy
> (0008,1010) SH (no value available) # 0, 0 StationName
> (0008,1030) LO (no value available) # 0, 0
> StudyDescription
> (0010,0010) PN [*] # 2, 1 PatientsName
> (0010,0020) LO (no value available) # 0, 0 PatientID
> (0010,0030) DA (no value available) # 0, 0
> PatientsBirthDate
> (0010,0040) CS (no value available) # 0, 0 PatientsSex
> (0020,000d) UI (no value available) # 0, 0
> StudyInstanceUID
> (0020,0010) SH (no value available) # 0, 0 StudyID
> QueryServerGroup()
> T::SendObject()
> Status Detail:
>
> # Dicom-Data-Set
> # Used TransferSyntax: LittleEndianImplicit
> (0000,0902) LO [Query was formatted improperly. Check required keys] # 52,
> 1 ErrorComment
> T::Drop()
> T::Destroy()
> cursor busy off
> no results !!!
> StudyManager::on_filter_search()
> turning cursor busy
> NEW QUERY:
>
> # Dicom-Data-Set
> # Used TransferSyntax: UnknownTransferSyntax
> (0008,0005) CS [ISO_IR 100] # 10, 1
> SpecificCharacterSet
> (0008,0020) DA (no value available) # 0, 0 StudyDate
> (0008,0030) TM (no value available) # 0, 0 StudyTime
> (0008,0052) CS [STUDY] # 6, 1
> QueryRetrieveLevel
> (0008,0061) CS (no value available) # 0, 0
> ModalitiesInStudy
> (0008,1010) SH (no value available) # 0, 0 StationName
> (0008,1030) LO (no value available) # 0, 0
> StudyDescription
> (0010,0010) PN [*] # 2, 1 PatientsName
> (0010,0020) LO (no value available) # 0, 0 PatientID
> (0010,0030) DA (no value available) # 0, 0
> PatientsBirthDate
> (0010,0040) CS (no value available) # 0, 0 PatientsSex
> (0020,000d) UI (no value available) # 0, 0
> StudyInstanceUID
> (0020,0010) SH (no value available) # 0, 0 StudyID
> QueryServerGroup()
> T::SendObject()
> Status Detail:
>
> # Dicom-Data-Set
> # Used TransferSyntax: LittleEndianImplicit
> (0000,0902) LO [Query was formatted improperly. Check required keys] # 52,
> 1 ErrorComment
> T::Drop()
> T::Destroy()
> cursor busy off
> no results !!!
>
>
>
>
> ctn output:
>
> upported classes: 1
> Forked child
> ACCEPTED (AES localhost meshulums fun) (Rashi ) 20070412 090207.000000 5570
> Parent
> CFind Request
> Message ID: 1
> Data Set Type: 0001
> Priority: 0002
> Class UID: 1.2.840.10008.5.1.4.1.2.1.1
> Find callback
> SOP Class: 1.2.840.10008.5.1.4.1.2.1.1
> Query Level: STUDY
> Response Count: 1
>
> DCM Dump Elements
> Object type: ELEMENT LIST
> Object size: 122
> Group: 0008, Length: 72
> 0008 0005 10 // ID Specific Character Set//ISO_IR 100
> 0008 0020 0 // ID Study Date//
> 0008 0030 0 // ID Study Time//
> 0008 0052 5 // ID Query Level//STUDY
> 0008 0061 0 // ID Modalities in Study//
> 0008 1010 0 // ID Station Name//
> 0008 1030 0 // ID Study Description//
> Group: 0010, Length: 34
> 0010 0010 1 // PAT Patient Name//*
> 0010 0020 0 // PAT Patient ID//
> 0010 0030 0 // PAT Patient Birthdate//
> 0010 0040 0 // PAT Patient Sex//
> Group: 0020, Length: 16
> 0020 000d 0 // REL Study Instance UID//
> 0020 0010 0 // REL Study ID//
> DCM Dump Elements Complete
>
> STUDY level query, Patient Root model is missing Patient ID (0010 0020) or
> has extra PATIENT level attributes
> Find callback
> SOP Class: 1.2.840.10008.5.1.4.1.2.1.1
> Query Level: STUDY
> Response Count: 2
> Writing to network: Connection reset by peer
> f0012 TCP I/O Error (Illegal seek) occurr
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 08:07 Thu 12 Apr , Alexander Pipelka wrote:
> > Ok. I was a bit surprised about the SCP behaviour and installed the
> > 'ctn' debian package (this should be the wustl ctn you're using). It's
> > version 3.0.6.
> >
> > I started the simple_storage server and did a default query (no query
> > params).
> > Everything worked. Here's the output:
> >
> > address@hidden:~$ simple_storage -c CTN 8001
> > CFind Request
> > Message ID: 1
> > Data Set Type: 0001
> > Priority: 0002
> > Class UID: 1.2.840.10008.5.1.4.1.2.1.1
> > Find callback
> > SOP Class: 1.2.840.10008.5.1.4.1.2.1.1
> > Query Level: STUDY
> > Response Count: 1
> >
> > DCM Dump Elements
> > Object type: ELEMENT LIST
> > Object size: 122
> > Group: 0008, Length: 72
> > 0008 0005 10 // ID Specific Character Set//ISO_IR 100
> > 0008 0020 0 // ID Study Date//
> > 0008 0030 0 // ID Study Time//
> > 0008 0052 5 // ID Query Level//STUDY
> > 0008 0061 0 // ID Modalities in Study//
> > 0008 1010 0 // ID Station Name//
> > 0008 1030 0 // ID Study Description//
> > Group: 0010, Length: 34
> > 0010 0010 1 // PAT Patient Name//*
> > 0010 0020 0 // PAT Patient ID//
> > 0010 0030 0 // PAT Patient Birthdate//
> > 0010 0040 0 // PAT Patient Sex//
> > Group: 0020, Length: 16
> > 0020 000d 0 // REL Study Instance UID//
> > 0020 0010 0 // REL Study ID//
> > DCM Dump Elements Complete
> >
> > Find callback
> > SOP Class: 1.2.840.10008.5.1.4.1.2.1.1
> > Query Level: STUDY
> > Response Count: 2
> > Find callback
> > SOP Class: 1.2.840.10008.5.1.4.1.2.1.1
> > Query Level: STUDY
> > Response Count: 3
> > Find callback
> > SOP Class: 1.2.840.10008.5.1.4.1.2.1.1
> > Query Level: STUDY
> > Response Count: 4
> > Find callback
> > SOP Class: 1.2.840.10008.5.1.4.1.2.1.1
> > Query Level: STUDY
> > Response Count: 5
> >
> > Maybe 'simple_storage' is the wrong choice. I'm not familiar with the
> > ctn package.
> > Is this a valid testing evironment or do i have to use some special
> > options ?
> >
> > Alex
> >
> >
> > Mitchell Laks schrieb:
> > > Alex,
> > > you need to review the definition of the
> > > Patient root model
> > >
> > >
> > > *********************
> > > more importantly look at the FAQ #38 on dcmtk forum
> > >
> > > FAQ #38: How can I use findscu for a query with the query/retrieve
> > > service?
> > >
> > >
> > >
> > >
> > > Joined: 02 Nov 2004
> > > Posts: 117
> > > Location: Oldenburg, Germany
> > >
> > > PostPosted: Wed, 2005-01-19, 13:31 Post subject: FAQ #38: How can I
> > > use findscu for a query with the query/retrieve service? Reply with
> > > quote
> > > Question How can I use findscu for a query with the query/retrieve
> > > service?
> > >
> > > Exclamation Here is an example: using findscu to query an image from a
> > > query/retrieve SCP using the patient root information model:
> > >
> > > Code:
> > > findscu -v -P -k 0008,0052="IMAGE" -k 0010,0020="300019" -k
> > > 0020,000D="1.2.3.1" -k 0020,000E="1.2.3.2" -k 0008,0018="1.2.3.3"
> > > localhost 104
> > >
> > > Explanation:
> > >
> > > * -v runs the application in verbose mode
> > > * -P specifies to use the patient root information model
> > > * -k 0008,0052="IMAGE" tells the application that you are querying on
> > > image level (i.e. for an image)
> > > * -k 0010,0020="300019" is the patient ID of the patient in question
> > > (unique key on patient level)
> > > * -k 0020,000D="1.2.3.1" is the study instance uid of the study in
> > > question (unique key on study level)
> > > * -k 0020,000E="1.2.3.2" is the series instance uid of the series in
> > > question (unique key on series level)
> > > * -k 0008,0018="1.2.3.3" is the sop instance uid of the image in
> > > question (unique key on image level)
> > > * localhost is the machine the query/retrieve SCP is running on
> > > * 104 is the port the query/retrieve SCP is listening to.
> > >
> > > Note that when you are querying on a certain query level (attribute
> > > 0008,0052 set to either PATIENT, STUDY, SERIES or IMAGE), you have to
> > > specify all unique keys of levels which are above this level; e.g. on
> > > image level, you have to specify a patient id, a study instance uid and a
> > > series instance uid to denote the patient/study/series you are referring
> > > to, and of course you have to finally provide a sop instance uid to
> > > specify the image you are looking for.
> > >
> > >
> > > *******************8
> > >
> > > thus you do NOT have a valid dicom query because you do NOT have a
> > >
> > > * unique key on patient level
> > >
> > > which must be the PATIENTID which we do not know.
> > >
> > > I also tried to use only the patient ID and no name attribute:
> > >
> > > here is the aeskulap output:
> > >
> > > ******************
> > > address@hidden:~$ aeskulap
> > > datadir: /usr/local/share
> > > trying to load '/usr/local/share/aeskulap/images/grid-1.png'
> > > trying to load '/usr/local/share/aeskulap/images/grid-2h.png'
> > > trying to load '/usr/local/share/aeskulap/images/grid-2v.png'
> > > trying to load '/usr/local/share/aeskulap/images/grid-4.png'
> > > trying to load '/usr/local/share/aeskulap/images/grid-16.png'
> > > trying to load '/usr/local/share/aeskulap/images/stock-tool-scale-22.png'
> > > trying to load '/usr/local/share/aeskulap/images/stock-layers-24.png'
> > > trying to load '/usr/local/share/aeskulap/images/series-1x1.png'
> > > trying to load '/usr/local/share/aeskulap/images/series-2x1.png'
> > > trying to load '/usr/local/share/aeskulap/images/series-2x2.png'
> > > trying to load '/usr/local/share/aeskulap/images/series-3x2.png'
> > > trying to load '/usr/local/share/aeskulap/images/series-3x3.png'
> > > trying to load '/usr/local/share/aeskulap/images/series-4x4.png'
> > > trying to load '/usr/local/share/aeskulap/images/stock-tool-eraser-22.png'
> > > trying to load '/usr/local/share/aeskulap/images/cursor_pan.png'
> > > trying to load
> > > '/usr/local/share/aeskulap/images/stock-tool-measure-22.png'
> > > trying to load '/usr/local/share/aeskulap/images/aeskulap.png'
> > > prescan: 0
> > > on_windowlevels_modality_changed() - indexint: 0
> > > StudyManager::on_filter_search()
> > > turning cursor busy
> > > NEW QUERY:
> > >
> > > # Dicom-Data-Set
> > > # Used TransferSyntax: UnknownTransferSyntax
> > > (0008,0005) CS [ISO_IR 100] # 10, 1
> > > SpecificCharacterSet
> > > (0008,0020) DA (no value available) # 0, 0 StudyDate
> > > (0008,0030) TM (no value available) # 0, 0 StudyTime
> > > (0008,0052) CS [STUDY] # 6, 1
> > > QueryRetrieveLevel
> > > (0008,0061) CS (no value available) # 0, 0
> > > ModalitiesInStudy
> > > (0008,1010) SH (no value available) # 0, 0
> > > StationName
> > > (0008,1030) LO (no value available) # 0, 0
> > > StudyDescription
> > > (0010,0010) PN [*] # 2, 1
> > > PatientsName
> > > (0010,0020) LO [3273016] # 8, 1 PatientID
> > > (0010,0030) DA (no value available) # 0, 0
> > > PatientsBirthDate
> > > (0010,0040) CS (no value available) # 0, 0
> > > PatientsSex
> > > (0020,000d) UI (no value available) # 0, 0
> > > StudyInstanceUID
> > > (0020,0010) SH (no value available) # 0, 0 StudyID
> > > QueryServerGroup()
> > > T::SendObject()
> > > Status Detail:
> > >
> > > # Dicom-Data-Set
> > > # Used TransferSyntax: LittleEndianImplicit
> > > (0000,0902) LO [Query was formatted improperly. Check required keys] #
> > > 52, 1 ErrorComment
> > > T::Drop()
> > > T::Destroy()
> > > cursor busy off
> > > no results !!!
> > >
> > > **************
> > > while this is the ctn output:
> > >
> > >
> > >
> > > Supported classes: 1
> > > 23282 Rashi
> > > Forked child
> > > ACCEPTED (AES localhost meshulums fun) (Rashi ) 20070411 232058.000000
> > > 23461
> > > Parent
> > > CFind Request
> > > Message ID: 1
> > > Data Set Type: 0001
> > > Priority: 0002
> > > Class UID: 1.2.840.10008.5.1.4.1.2.1.1
> > > Find callback
> > > SOP Class: 1.2.840.10008.5.1.4.1.2.1.1
> > > Query Level: STUDY
> > > Response Count: 1
> > >
> > > DCM Dump Elements
> > > Object type: ELEMENT LIST
> > > Object size: 130
> > > Group: 0008, Length: 72
> > > 0008 0005 10 // ID Specific Character Set//ISO_IR 100
> > > 0008 0020 0 // ID Study Date//
> > > 0008 0030 0 // ID Study Time//
> > > 0008 0052 5 // ID Query Level//STUDY
> > > 0008 0061 0 // ID Modalities in Study//
> > > 0008 1010 0 // ID Station Name//
> > > 0008 1030 0 // ID Study Description//
> > > Group: 0010, Length: 42
> > > 0010 0010 1 // PAT Patient Name//*
> > > 0010 0020 7 // PAT Patient ID//3273016
> > > 0010 0030 0 // PAT Patient Birthdate//
> > > 0010 0040 0 // PAT Patient Sex//
> > > Group: 0020, Length: 16
> > > 0020 000d 0 // REL Study Instance UID//
> > > 0020 0010 0 // REL Study ID//
> > > DCM Dump Elements Complete
> > >
> > > STUDY level query, Patient Root model is missing Patient ID (0010 0020)
> > > or has extra PATIENT level attributes
> > > Find callback
> > > SOP Class: 1.2.840.10008.5.1.4.1.2.1.1
> > > Query Level: STUDY
> > > Response Count: 2
> > > Writing to network: Connection reset by peer
> > > f0012 TCP I/O Error (Illegal seek) occurred in routine:
> > > sendReleaseRPTCP
> > > Exiting
> > > Supported classes: 1
> > > 23461 Rashi
> > > Forked child
> > > ACCEPTED (AES localhost meshulums fun) (Rashi ) 20070411 232408.000000
> > > 23484
> > > Parent
> > > CFind Request
> > > Message ID: 1
> > > Data Set Type: 0001
> > > Priority: 0002
> > > Class UID: 1.2.840.10008.5.1.4.1.2.1.1
> > > Find callback
> > > SOP Class: 1.2.840.10008.5.1.4.1.2.1.1
> > > Query Level: STUDY
> > > Response Count: 1
> > >
> > > DCM Dump Elements
> > > Object type: ELEMENT LIST
> > > Object size: 130
> > > Group: 0008, Length: 72
> > > 0008 0005 10 // ID Specific Character Set//ISO_IR 100
> > > 0008 0020 0 // ID Study Date//
> > > 0008 0030 0 // ID Study Time//
> > > 0008 0052 5 // ID Query Level//STUDY
> > > 0008 0061 0 // ID Modalities in Study//
> > > 0008 1010 0 // ID Station Name//
> > > 0008 1030 0 // ID Study Description//
> > > Group: 0010, Length: 42
> > > 0010 0010 1 // PAT Patient Name//*
> > > 0010 0020 7 // PAT Patient ID//3273016
> > > 0010 0030 0 // PAT Patient Birthdate//
> > > 0010 0040 0 // PAT Patient Sex//
> > > Group: 0020, Length: 16
> > > 0020 000d 0 // REL Study Instance UID//
> > > 0020 0010 0 // REL Study ID//
> > > DCM Dump Elements Complete
> > >
> > > STUDY level query, Patient Root model is missing Patient ID (0010 0020)
> > > or has extra PATIENT level attributes
> > > Find callback
> > > SOP Class: 1.2.840.10008.5.1.4.1.2.1.1
> > > Query Level: STUDY
> > > Response Count: 2
> > > Writing to network: Connection reset by peer
> > > f0012 TCP I/O Error (Illegal seek) occurred in routine:
> > > sendReleaseRPTCP
> > > Exiting
> > >
> > > ************
> > > thus you need to review the definitions of the query levels carefully:
> > >
> > > I should point out that i also corrected the people at osirix about this
> > > sort of thing
> > > using the same test bed. :)
> > >
> > > they made similar errors initially too.
> > >
> > > I stil think you should focus on display and comparison though.
> > >
> > > Mitchell
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Aeskulap-users mailing list
> > > address@hidden
> > > http://lists.nongnu.org/mailman/listinfo/aeskulap-users
> > >
> > >
> >
> >
> >
> > _______________________________________________
> > Aeskulap-users mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/aeskulap-users
>
>
> _______________________________________________
> Aeskulap-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/aeskulap-users
- Re: [Aeskulap-users] aeskulap dicom issues,
pipelka <=