Posts by dimitris_skordias

Hello Marcel,

I have exactly the same setup in 5 installations and all work fine, except one were Postgres often crashes with log "FATAL: out of memory" error which is caused by a Windows Server (NT Level) exception 0xC000012D "Out of Virtual Memory"...

The Conquest version is 1.5.0 and runs on a Windows Server 2019 Virtual Machine with 4vCPUs, 12GBRAM, 100GB OS Drive, Postgres12 on top of a DELL / Vmware ESXi 6.7 host.

I have observe that quite often (almost daily) we get Warning Level events in Windows Event Viewer that dgate64 consumes significant Virtual Memory such as the one I copied below.

-------------------------------------------------------------------------------------------------

Log Name: System

Source: Microsoft-Windows-Resource-Exhaustion-Detector

Date: 17/03/2021 20:50:06

Event ID: 2004

Task Category: Resource Exhaustion Diagnosis Events

Level: Warning

Description: Windows successfully diagnosed a low virtual memory condition. The following programs consumed the most virtual memory: dgate64.exe (6808) consumed 20763033600 bytes, sqlservr.exe (4580) consumed 2050162688 bytes, and MsMpEng.exe (3028) consumed 272416768 bytes.

---------------------------------------------------------------------------------------------

I have tried to increase Virtual Memory space manually in Windows system advanced setup but in vain.... It eats all you give.

Any ideas of what is going wrong ? Is it hardware problem... RAM maybe ? disks ?....

I repeat that it happens only in 1 case out of 5 installations.

PS. The rest 2 virtual memory hungry tasks that appear in the above event are Windows Defender and MSSQL server

Best regards.

Hi Marcel,

Thanks for the reply...and sorry for late response as I was on holidays and returned recently !

I am thinking of creating a mechanisim using lua scripting and one of the available events eg. background....

Many thanks.

Hi Marcel,

Can you give an example of how and when the 'clienterror' lua script is called and executed... I noticed that it is added as a scripting option in 1.4.19 and looks interesting... same also for 'association' and 'endassociation' lua scripting options.

I tried but didn't make it...

By the way I am interested in setting up a mechanism to flag failed forwards of studies... Ideas are welcome in helping doing so.

Kind regards,

Dimitris.

I will do so and get back with input.... However is it possible to enable/disable Xfer syntaxes in the configuration (ie SOP File ?)

Many thanks.

Hi Marcel,

Could you please explain which Xfer Syntax is used by Conquest by default when responding to CFIND Modality Workist requests? Is it possible to restrict to either Implicit Little Endian or Explicit Little Endian in the configuration ?

Reason for asking is that we failed to diplay query results in a new release SIEMENS CT and the vendor suggested that it is a mismatch in Transfer Syntaxes and asked to force reply in Expl Little Endian, while Conquest seems to reply in Implicit. (We are using 1.4.16 Version of Conquest....)

Thanks a lot.

Hi Marcel,

May I ask which LUA Version is embedded in Conquest ? Does support bitwise operators (....if earlier than 5.3 does not...) ?

What are the plans of upgrading to current LUA release ie 5.3.4 ?

Many Thanks.

Marcel hi,

Sometimes when forwarding MRI exams (>1000 images) from a 1.4.17d server to a remote 1.4.17.d over an ADSL link, I got the following error on the remote server log and some MRI sequences are missing. For your info, I use export converters and the association level is set to study (default is series) while the timeout timers are set to default values.

***Client Error: command ffff failed **
[AZPAXMM1] 20150924 10:08:06 ***Connection Terminated

Can you please explain what the error means and possible causes ?

Many thanks,

Dimitris.

Hi Marcel,

I look at the DICOM standards documents and i found that this specific tag ReqProcID is in the sequence "Request Attributes Sequence" 0040,0275. This sequence appears optionally (3) at the Series Level.

Does this mean that I should make necessary changes at the Series Table attributes in Dicom.SQL instead of the Image table attributes ?

Can you elaborate more on how I should code the sequence in DICOM.SQL ?

Thanks.

Hi Marcel,

Some DICOM Image Files contain the Requested Procedure ID TAG (0040,1001)...at least this is what I observed when I opened them in a DICOM viewer.

My question is if it is possible to add this tag as a column in the DICOM Image Table in Conquest because I need to use this ID in my applicaion.

To do so I have added the following line in DICOM.SQL file in image table, rebuild the database, but although the column was created no content was there.
{ 0x0040, 0x1001, "ReqProcID", 16, SQL_C_CHAR, DT_STR }

Thanks for your help.

Dimitris Skordias.

Hi Marcel,

Is it possible to configure conquest 1.4.16 to run its 32bit version on a 64bit Win7 OS ? The reason is that we use MS-access 2010 32-bit version so there is not available a 64 bit version of the MSaccess ODBC driver to setup the conquest database in MSaccess (conquest database generation fails...)

Regards,

Dimitris.

PS we do not intend to migrate to SQL server in this case...as a workaround.

Marcel hi again,

Let me mention that the conquest dicom printer in the CT modality is configured as a codonics horizon printer with 8-bit depth ...If we increase it to 12 bit do you think that this would work better ?

Thanks.

Hi Marcel,

1. I think I lost it....what files should i compare ?

2. Is there a way to enable auto level/window for 8 bit data

3. How and where is set that the data would be 8 or 16 bit ? In the SCU ?

Thanks.

Hi Marcel,

below you may find the dicom data of a print file.

Thanks

--------------------------------------

Dicom-File-Format

# Dicom-Meta-Information-Header
# Used TransferSyntax: Little Endian Explicit
(0002,0000) UL 102 # 4, 1 FileMetaInformationGroupLength
(0002,0001) OB 00\01 # 2, 1 FileMetaInformationVersion
(0002,0010) UI =LittleEndianImplicit # 18, 1 TransferSyntaxUID
(0002,0012) UI [1.2.826.0.1.3680043.2.135.1066.101] # 34, 1 ImplementationClassUID
(0002,0013) SH [1.4.16/WIN32] # 12, 1 ImplementationVersionName

# Dicom-Data-Set
# Used TransferSyntax: Little Endian Implicit
(0008,0018) UI (no value available) # 0, 0 SOPInstanceUID
(0008,0020) DA (no value available) # 0, 0 StudyDate
(0008,0060) CS (no value available) # 0, 0 Modality
(0008,1030) LO (no value available) # 0, 0 StudyDescription
(0008,103e) LO (no value available) # 0, 0 SeriesDescription
(0020,0011) IS (no value available) # 0, 0 SeriesNumber
(0020,0013) IS (no value available) # 0, 0 InstanceNumber
(0028,0000) UL 102 # 4, 1 GenericGroupLength
(0028,0002) US 1 # 2, 1 SamplesPerPixel
(0028,0004) CS [MONOCHROME2] # 12, 1 PhotometricInterpretation
(0028,0010) US 5025 # 2, 1 Rows
(0028,0011) US 4320 # 2, 1 Columns
(0028,0034) IS [1\1] # 4, 2 PixelAspectRatio
(0028,0100) US 8 # 2, 1 BitsAllocated
(0028,0101) US 8 # 2, 1 BitsStored
(0028,0102) US 7 # 2, 1 HighBit
(0028,0103) US 0 # 2, 1 PixelRepresentation
(7fe0,0000) UL 21708008 # 4, 1 ACR_NEMA_2C_VariablePixelDataGroupLength
(7fe0,0010) OW (no value available) # 0, 1 PixelData

<PropertySet>
<Property id='ContentDate' upperBound='' lowerBound='' default='' isModified='0'></Property>
<Property id='ContentDateTime' upperBound='' lowerBound='' default='' isModified='0'></Property>
<Property id='ContentTime' upperBound='' lowerBound='' default='' isModified='0'></Property>
<Property id='DocumentColorSpace' upperBound='' lowerBound='' default='Grayscale' isModified='0'>Grayscale</Property>
<Property id='DocumentHeight' upperBound='' lowerBound='' default='5025' isModified='0'>5025</Property>
<Property id='DocumentNumber' upperBound='0' lowerBound='0' default='0' isModified='0'>0</Property>
<Property id='DocumentTree' upperBound='' lowerBound='' default='patient_unique_id%2f....%2fdicom_study_id%2f1.3.6.1.4.1.24930.1346697517.26500.4%2fdicom_series_id%2f1.3.6.1.4.1.24930.1346697517.19169.5%2fdicom_sop_id%2f1.3.6.1.4.1.24930.1346697517.15724.6' isModified='1'>patient_unique_id%2f....%2fdicom_study_id%2f1.3.6.1.4.1.24930.1346697517.26500.4%2fdicom_series_id%2f1.3.6.1.4.1.24930.1346697517.19169.5%2fsequence_id%2f0%2fdicom_sop_id%2f1.3.6.1.4.1.24930.1346697517.15724.6</Property>
<Property id='DocumentWidth' upperBound='' lowerBound='' default='4320' isModified='0'>4320</Property>
<Property id='FileName' upperBound='' lowerBound='' default='1.2.826.0.1.3680043.2.135.734653.43121060.6.1346430.0.1.1.0.dcm' isModified='0'>1.2.826.0.1.3680043.2.135.734653.43121060.6.1346430.0.1.1.0.dcm</Property>
<Property id='FilePath' upperBound='' lowerBound='' default='C%3a%5cUsers%5cDimitris%5cDesktop%5c1.2.826.0.1.3680043.2.135.734653.43121060.6.1346430.0.1.1.0.dcm' isModified='0'>C%3a%5cUsers%5cDimitris%5cDesktop%5c1.2.826.0.1.3680043.2.135.734653.43121060.6.1346430.0.1.1.0.dcm</Property>
<Property id='FirstName' upperBound='' lowerBound='' default='' isModified='0'></Property>
<Property id='LastName' upperBound='' lowerBound='' default='' isModified='0'></Property>
<Property id='Modality' upperBound='' lowerBound='' default='' isModified='0'></Property>
<Property id='PatientID' upperBound='' lowerBound='' default='' isModified='0'></Property>
<Property id='PatientUniqueID' upperBound='' lowerBound='' default='....' isModified='0'>....</Property>
<Property id='PatientsBirthDate' upperBound='' lowerBound='' default='' isModified='0'></Property>
<Property id='PatientsName' upperBound='' lowerBound='' default='' isModified='0'></Property>
<Property id='PatientsSex' upperBound='' lowerBound='' default='' isModified='0'></Property>
<Property id='ReferringPhysiciansName' upperBound='' lowerBound='' default='' isModified='0'></Property>
<Property id='SOPInstanceUID' upperBound='' lowerBound='' default='1.3.6.1.4.1.24930.1346697517.15724.6' isModified='0'>1.3.6.1.4.1.24930.1346697517.15724.6</Property>
<Property id='SequenceID' upperBound='' lowerBound='' default='0' isModified='0'>0</Property>
<Property id='SeriesDescription' upperBound='' lowerBound='' default='' isModified='0'></Property>
<Property id='SeriesInstanceUID' upperBound='' lowerBound='' default='1.3.6.1.4.1.24930.1346697517.19169.5' isModified='0'>1.3.6.1.4.1.24930.1346697517.19169.5</Property>
<Property id='SortKey' upperBound='' lowerBound='' default='DocumentNumber' isModified='0'>DocumentNumber</Property>
<Property id='StudyDate' upperBound='' lowerBound='' default='' isModified='0'></Property>
<Property id='StudyDescription' upperBound='' lowerBound='' default='' isModified='0'></Property>
<Property id='StudyInstanceUID' upperBound='' lowerBound='' default='1.3.6.1.4.1.24930.1346697517.26500.4' isModified='0'>1.3.6.1.4.1.24930.1346697517.26500.4</Property>
<Property id='StudyTime' upperBound='' lowerBound='' default='' isModified='0'></Property>
<Property id='TransferSyntaxUID' upperBound='' lowerBound='' default='1.2.840.10008.1.2' isModified='0'>1.2.840.10008.1.2</Property>
</PropertySet>

Hi

I think it is 8 bits...I will try to attach a file

Thanks

Hi Marcel,

The default values in all stored dicom print files are L=128, W=256.

Who sets these values SCP or SCU ? (I guess it is the SCP conquest as it is identical for all modalities ...I got a print request from a US and it is the same as with the CT ones)

Thanks.

Marcel hi again...

As i mentioned in my previous reply the problem with the text and the resolution was fixed thanks to your suggestion !

However I would appreciate your help on another issue that arised on dicom print again with the Siemens Somatom CT. Actually the end users complain that the contrast and the brightness level of the printouts vary depending the exam type ie in brain exams they are acceptable while in other exams such as spine are not.

Do you think that this is related with the conquest side (SCP) or it relies entirely on the (SCU) side ie the CT image processing and filming software (called syngo). If the CT operator would adjust the window/level of the images in the filmbox prior to sending them for printing would this improve the quality ?

In the literature i noticed about presentation LUT...is this relevant in our case ?

Regards,

Dimitris.

Marcel hi,

As you suggested I made the changes with the hex editor and glad to say that the printouts were of excellent quality...

Thank you very much for the great support !!!

Regards,

Dimitris.

Marcel thanks a lot !

Do you think that this fix may be included in the next release ? Any estimate for the release date ?

Kind regards,

Dimitris.

Hi Marcel and thanks for the reply !

I did the test you mentioned...actually I used a Dicom print file with layout of 4x5 and resolution of 4320x5025 (this was the original film box produced by the Siemens CT) and convert it to bmp with the dgate command using 1600 size as an option. The result was a BMP file with resolution of 1080x1256 and 24bit depth and filesize of 3,88MB. The image quality was degradated (quite pixelized) because of the downsizing and of course the Image text was totally unreadable.

When I increased the size in the dgate command to about 8-9K then the image quality was similar to that of the original dicom image.

Any ideas how to improve the situation ? Is there a way to change the default 1600 size in conquest configuration ?

By the way what are the w/l/f options of the dgate convert_to_bmp command ?

Kind regards,

Dimitris.

Hello,

I use conquest as a dicom print scp with a logic7 US and a Siemens Somatom CT and works fine. However with the Siemens CT I face the following problem.

In the printouts (usually using 3x4 and 5x4 layout on A3 sized paper) the image texts are distorted (they are somehow pixelized and not smooth) and therefore not readable. It looks like when the dicom print image is transformed to BMP the interpolation is off so the image gets a little bit distorted when the size is adjusted to fit the default printer paper size.

The configuration we use is the following:

1. Xerox 7525 printer with 1200dpi and A3 as default settings
2. The Siemens Somatom Duo CT scanner is configured to "see" the Conquest Dicom Print SCP as a Condonics Horizon printer (it was the only availble with paper as an option in CT Scanner configuration menu) and sends the print jobs using 8x10 film size in order to reduce image resolution to about 2300x2000 pixels image in order to be small enough to cope with Xerox's resolution. (if we set the film size to 11x14 the Dicom print image size resolution is about 5000x4300 so perhaps exceeds printer PPI)

I did the following test succesfully to verify that the printer can deal with the image size. 1) I stopped the conquest user interface so all print jobs were qeued in the print_data folder 2. I opened a DICOM print file with a Dicom Viewer and copy paste the image (1to1 scale) in a Word file (A3 sized) 3. I printed the word file to the default printer and the image as well as the image text was of great quality. So that makes me guess that something goes wrong during the processing within the conquest user interface, propably the transformation of image from DICOM to BMP, such as absence of interpolation and smoothing.

Thanking you in advance for your help.

Dimitris Skordias