Hi Hi Marcel
The Wado viewer of conquest version 1.5.0e displaces a black image for MRI studies when using the present window level provided by the dicom metadata.
Hi Hi Marcel
The Wado viewer of conquest version 1.5.0e displaces a black image for MRI studies when using the present window level provided by the dicom metadata.
Thanks for giving the community a great application.
A feature request for the server would the ability to select if a file already exiting in the Database can be replaced or not. This will save computer resources by not having to overwrite data that are duplicates.
HI,
I would just like to comment that though J1 and J2 are the same, not all commercial and freeware software are able to
import J2 implementation of jpeg lossless. J1=UID 70 and j2= UID 57 should be compatible
and interchangeable, but unfortunately UID 70 seems to be more universally accepted jpeg lossless transfer syntax implementation.
I would have wished jpeg J1 was the version you choose to retain. So that Kpacs and efilm ver 1x to 2x can import them directly.
see comment of David Clunie.
https://groups.google.com/foru…otocols.dicom/jLCdCsrhi7s
ajgg
HI,
I would just like to comment that though J1 and J2 are the same, not all commercial and freeware software are able to
import J2 implementation of jpeg lossless. J1=UID 70 and j2= UID 57 should be compatible
and interchangeable, but unfortunately UID 70 seems to be more universally accepted jpeg lossless transfer syntax implementation.
I would have wished jpeg J1 was the version you choose to retain. So that Kpacs and efilm ver 1x to 2x can import them directly.
see comment of David Clunie.
https://groups.google.com/foru…otocols.dicom/jLCdCsrhi7s
ajgg
hi,
Thanks for pointing me the direction. Will hope to learn and write a good script
ajgg
Hi,
Im trying to create a special filename syntax but run into difficullies, not being a programmer
I wanted to save radiograph images by the name,sex,age,and birthday of the patients
With the family name in UPPER CASE, first name in lower case, Middle initial in UPPER case and removing the caret used as space between
in these the dicom.
These will require lua programming? the name and age are the ones the seem to require those?
Thanks for any help
ajgg
Hi,
Ive been trying to reproduce the error, but cannot seem to make it reappear.
Im only getting correct UID syntax transfer for Jpeg2000 and old dcmcjpeg inserted J1 header all in same image.
(0002,0010) UI [1.2.840.10008.1.2.4.90] # 22 TransferSyntaxUID
(0008,1140) SQ (empty) # 0 ReferencedImageSequence
(0008,0000) UL 98 # 4 IdentifyingGroupLength
(0008,1150) UI [1.2.840.10008.5.1.4.1.1.2] # 26 ReferencedSOPClassUID
(0008,1155) UI [1.3.12.2.1107.5.1.4.54546.30000006092106470181200000911] # 56 ReferencedSOPInstanceUID
(0008,2111) ST [Lossless JPEG compression, selection value 1, point transform 0, compression ratio 2.5303 ] # 90 DerivationDescription
(0008,2112) SQ (empty) # 0 SourceImageSequence
ajgg
Hi,
I been partially moving previously stored dicom data in J1 compression to Jpeg2000 lossless to further reduce file size.
Review of saved files show that dicom header UID tranfer syntax is Jpeg2000 lossless however the previously inserted J1 header remains intact. Is this a proper behaviour or should have the J1 header been appended or removed?
sample header
(0002,0000) UL 200 # 4 MetaElementGroupLength
(0002,0001) OB \00\01 # 2 FileMetaInformationVersion
(0002,0002) UI [1.2.840.10008.5.1.4.1.1.2] # 26 MediaStorageSOPClassUID
(0002,0003) UI [1.3.12.2.1107.5.1.4.54546.30000006042500365681200000178] # 56 MediaStorageSOPInstanceUID
(0002,0010) UI [1.2.840.10008.1.2.4.90] # 22 TransferSyntaxUID
(0002,0012) UI [1.2.826.0.1.3680043.2.135.1066.101] # 34 ImplementationClassUID
(0002,0013) SH [1.4.16/WIN32] # 12 ImplementationVersionName
(0008,0000) UL 1246 # 4 IdentifyingGroupLength
(0008,0005) CS [ISO_IR 100] # 10 SpecificCharacterSet
(0008,0008) CS [DERIVED\\SECONDARY\\AXIAL\\CT_SOM5 RTD ] # 36 ImageType
.
. header data inserted from dcmtk tools in 1.4.15x
(0008,2111) ST [Lossless JPEG compression, selection value 1, point transform 0, compression ratio 2.2878 [Lossless JPEG compression, selection value 1, point transform 0, compression ratio 1.7158] ] # 182 DerivationDescription
(0008,2112) SQ (empty) # 0 SourceImageSequence
(0008,0000) UL 92 # 4 IdentifyingGroupLength
(0008,1150) UI [1.3.12.2.1107.5.9.1] # 20 ReferencedSOPClassUID
(0008,1155) UI [1.3.12.2.1107.5.1.4.54546.30000006042500365681200000176] # 56 ReferencedSOPInstanceUID
(0008,9215) UN (empty) # 0 ?
(0008,0000) UL 90 # 4 IdentifyingGroupLength
(0008,0100) SH [121327] # 6 CodeValue
(0008,0102) SH [DCM ] # 4 CodingSchemeDesignator
(0008,0104) LO [Full fidelity image, uncompressed or lossless compressed] # 56 CodeMeaning
(0009,0000) UL 28 # 4 GroupLength
ajgg
Hi,
Downloaded link and got ConquestUpdate1416j
the gui says latest built april-4-2012 but version (j)??
[CONQUESTSRV2] DGATE (1.4.16j, build Wed Apr 04 08:05:30 2012, bits 64) is running as threaded server
Tested with results on jpeg bug.
1. 2 LossyImageCompression is still not set to "01" with jk2000 (jl). works and sets its to "01" with jpeg lossy (j6)
result sample of (jl)
(0002,0010) UI [1.2.840.10008.1.2.4.91] # 22 TransferSyntaxUID
(0028,2110) CS [00] # 2 LossyImageCompression
Both jpeg lossless and lossy use [1.2.840.10008.1.2.4.91] # 22 TransferSyntaxUID. I undestand that this is accepted. Would using 1.2.840.10008.1.2.4.90 help distinguish lossless in the header.
2. LossyQuality in dicom.ini not working. Image size the same regarless of value both j6 and Jl
3. TransferSyntaxUID in dgatesop.lst remains hashed despite enabling jp3000 lossless or lossy after saving configuration in gui.
#JPEG2000LosslessOnly 1.2.840.10008.1.2.4.90 transfer LittleEndianExplicit
#JPEG2000 1.2.840.10008.1.2.4.91 transfer LittleEndianExplicit
hope the observation helps
ajgg
ConquestUpdate1416j
Hi,
Has the 1.4.16(k) release been upload to the server? Can't find the file.
ajgg
Hi,
You were right some config settings were wrongly configured. thanks. Will be more diligent next time.
ajgg
Hi,
Doing tests to compare compression settings after trying to compress an original CR image to below 500K size for document transfer.
1. The size output of built-in lossy compression( dicom.ini set LossyQuality = 50) does not result in any difference in file size from the default setting of LossyQuality = 95.
A. dicom.ini settings settings
DecompressNon16BitsJpeg = 1
UseBuiltInJPEG = 1
settings and the resulting file size
================================
uncompressed = 38.424 K
LossyQuality set at 95 = 7,462 k
LossyQuality set at 50 = 7,462 k
B. Using external program for compression (dcmcjpeg) dicom.ini settings
UseBuiltInJPEG = 0
using importconverter process with dcmcjpeg.exe -v +eb +g +q 50 parameters
settiings and the resulting file size
================================
set at 50 = 547 k
The test was does using a clean default server setup of 1.4.16i
C: I also obsserved that the image header of the compressed images do not indicate that a lossy compression was made sfter using jpeglossy of jpeg2000 lossy compression settings.
Header (0028,2110) CS [00] # 2 LossyImageCompression remains set to "0". I think k-pacs and iq-view uses this parameter because I get warnings when viewing images compressed from older conquest versions that were using dcmcjpeg.
saw this related post http://forum.dcmtk.org/viewtop…a9810bf07c18217d6e796f02c
I hope the observations can helps
ajgg
Ok
I will modify config and see result of transfer. thanks
ajgg
Hi,
It seems to be on start up of server from restart?
3/26/2012 2:55:13 PM [CT_SRV1] DGATE (1.4.16i, build Tue Feb 21 22:15:10 2012, bits 32) is running as threaded server
3/26/2012 2:55:13 PM [CT_SRV1] Database type: native MySQL connection
3/26/2012 2:55:13 PM [CT_SRV1] Started 3 export queue thread(s)
3/26/2012 2:55:13 PM [CT_SRV1] User interface test: local server is running!
3/26/2012 2:55:13 PM [CT_SRV1] --->2597 small (120632); 58 medium (42028) 9 large (47528890) OK - end of heap
3/26/2012 2:56:32 PM [CT_SRV1] DGATE (1.4.16i, build Tue Feb 21 22:15:10 2012, bits 32) is running as threaded server
3/26/2012 2:56:32 PM [CT_SRV1] Database type: native MySQL connection
3/26/2012 2:56:32 PM [CT_SRV1] Started 3 export queue thread(s)
3/26/2012 2:56:32 PM [CT_SRV1] User interface test: local server is running!
3/26/2012 2:56:32 PM [CT_SRV1] --->2596 small (120608); 58 medium (42028) 9 large (47528890) OK - end of heap
20120326 14:56:37 DGATE (1.4.16i, build Tue Feb 21 22:15:10 2012, bits 32) is running as threaded server
20120326 14:56:37 Started zip and cleanup thread
20120326 14:56:37 Database type: native MySQL connection
20120326 14:56:37 Started 3 export queue thread(s)
3/26/2012 2:56:40 PM [CT_SRV1] Stopped zip and cleanup thread
3/26/2012 2:56:40 PM [CT_SRV1] --->2586 small (120207); 58 medium (42028) 9 large (47528890) OK - end of heap
3/26/2012 2:56:40 PM [CT_SRV1] User interface test: local server is running!
3/26/2012 2:56:40 PM [CT_SRV1] --->2586 small (120255); 58 medium (42028) 9 large (47528890) OK - end of heap
3/26/2012 2:56:46 PM [CT_SRV1]
3/26/2012 2:56:46 PM [CT_SRV1] UPACS THREAD 2: STARTED AT: Mon Mar 26 14:56:46 2012
3/26/2012 2:56:46 PM [CT_SRV1] Calling Application Title : "CTPACS "
3/26/2012 2:56:46 PM [CT_SRV1] Called Application Title : "CT_SRV1 "
3/26/2012 2:56:46 PM [CT_SRV1] Application Context : "1.2.840.10008.3.1.1.1", PDU length: 116794
3/26/2012 2:56:46 PM [CT_SRV1] Presentation Context 0 "1.2.840.10008.5.1.4.1.1.2" 1
3/26/2012 2:56:57 PM [CT_SRV1] Written file: L:\main_fs\ct\20120326\1.3.12.2.1107.5.1.4.54546.30000012032605593326500000031\1.3.12.2.1107.5.1.4.54546.30000012032605593326500000032\1.3.12.2.1107.5.1.4.54546.30000012032605494921800001251.dcm
3/26/2012 2:56:57 PM [CT_SRV1] --->2589 small (120293); 58 medium (42028) 10 large (47537532) OK - end of heap
3/26/2012 2:56:57 PM [CT_SRV1] UPACS THREAD 2: ENDED AT: Mon Mar 26 14:56:57 2012
3/26/2012 2:56:57 PM [CT_SRV1] UPACS THREAD 2: TOTAL RUNNING TIME: 11 SECONDS
3/26/2012 2:57:30 PM [CT_SRV1] --->2587 small (120225); 58 medium (42028) 9 large (47528890) OK - end of heap
I will mail my config.
added this extra lines
# Configuration of forwarding and/or converter programs to export DICOM slices
ForwardAssociationLevel = GLOBAL
ForwardAssociationCloseDelay = 600
ForwardAssociationRefreshDelay = 3600
ForwardAssociationRelease = 1
ExportConverters = 3
ExportCallingAE0 = AN_LEO06806
ExportConverter0 = ifnumgreater "%V0020,0011", "500";forward series to CTPACS
# Configuration of rules to modify, log or reject incoming DICOM slices
ForwardCollectDelay = 30
MaximumExportRetries = 0
MaximumDelayedFetchForwardRetries = 0
QueryConverter0 = ifnotequal "%v0008,0052","STUDY";stop;ifnotempty "%V0010,0020";stop;delete 0020,1206;delete 0020,1208
[lua]
endassociation = print('--->' .. heapinfo())
ajgg
Hi,
One of the characteristics of conquest is that it will rewrite a file already in the pacs even exact duplicates. .
A wishlist would be a feature to allow or disregard files rewritten when a duplicate of a study is sent.
. it could be a dicom.ini parameter. The server would check the sopuid then compare name, patient, id, age, sex, accession number, birthdate and possibly other parameters of the incoming file. if those are the same with stored file, the the incoming file is ignored leaving the original intact. A log is also written of the duplicate file. A more complex alternative is a duplicate file is save in a separate folder. Otherwise if the parameter is not set the old file is overwritten. The dicom.ini could state something like overwriteduplicate=1, allowing files to be rewritten, which is the present default. It may increase cpu usage but a lot faster than rewriting a whole study I guess.
One reason for this request is we get ntfs errors on chkdsk.
Deleting corrupt attribute record (186, $I30)
This is a known ntfs "bug" deficiency.
http://support.microsoft.com/kb/169404
thanks
ajgg
Hi,
started the transfer using --movestudies from a sending server.
ajgg
Hi,
The serverlog does not show error messages, however, after a long series of save images this appears
3/25/2012 1:09:53 PM [CONQUESTSRV3] Written file: D:\FS\Primary\0110863\1.3.12.2.1107.5.1.4.54546.30000006060523324701500009201_0002_000005_13326521930056.dcm
3/25/2012 1:09:53 PM [CONQUESTSRV3] --->4424 small (160400); 222 medium (165692) 8 large (660450) OK - end of heap
3/25/2012 1:09:53 PM [CONQUESTSRV3] Written file: D:\FS\Primary\0110863\1.3.12.2.1107.5.1.4.54546.30000006060523324701500009201_0002_000005_13326521930056.dcm
3/25/2012 1:09:53 PM [CONQUESTSRV3] --->4424 small (160400); 222 medium (165692) 8 large (660450) OK - end of heap
3/25/2012 1:09:53 PM [CONQUESTSRV3] [recompress]: recompressed with mode = jk (strip=0)
3/25/2012 1:10:53 PM [CONQUESTSRV3] Written file: D:\FS\Primary\0108049\1.3.12.2.1107.5.1.4.54546.30000006040400381457800008227_0006_000288_13326522530252.dcm
3/25/2012 1:10:53 PM [CONQUESTSRV3] --->5140 small (184270); 696 medium (666416) 59 large (3208954) OK - end of heap
3/25/2012 1:10:53 PM [CONQUESTSRV3] [recompress]: recompressed with mode = jk (strip=0)
3/25/2012 1:11:53 PM [CONQUESTSRV3] Written file: D:\FS\Primary\0108049\1.3.12.2.1107.5.1.4.54546.30000006040400381457800008926_0009_000106_13326523130451.dcm
3/25/2012 1:11:53 PM [CONQUESTSRV3] --->8947 small (404364); 3112 medium (2482284) 1144 large (30790264) OK - end of heap
3/25/2012 1:11:53 PM [CONQUESTSRV3] [recompress]: recompressed with mode = jk (strip=0)
viewed the image file in the gui and it looks okay.
I will send the log file in the email
ajgg
Hi,
Sorry but don,t know what to look for. Need some guidance. I will run transfer with debug set to 1. I can email the server log in compressed format it that will be ok?
this will take a couple of hours
ajgg
Hi
This is thelast lines of the log after 3hrs tranfer with slowdowm
aI interupted the transfer
memory 79,128 k
virtual mem size 103,04 k
recieving files in uncompressed format saving to jk2 lossless format.
CT_SRV1] --->3001 small (129835); 112 medium (58564) 12 large (47942698) OK - end of heap
[CT_SRV1] UPACS THREAD 7: ENDED AT: Sat Mar 24 15:17:26 2012
[CT_SRV1] UPACS THREAD 7: TOTAL RUNNING TIME: 18052 SECONDS
[CT_SRV1] --->2682 small (121170); 58 medium (42028) 11 large (47938490) OK - end of heap
ajgg
hi
okay il will do this today and run the transfer again. what do you need from the logs?
ajgg