getting blanks of CT protocol page with 1.4.16h

  • Hi,


    I'm getting blanks page instead of the protocol page of CT scans (showing dosage and scan times etc) when using version 1.4.16h. Noticed that it is reproducible when the Jpeg 2000 support is enabled.
    It does not affect in 1.4.15c in both uncompressed and uncompressed states.


    Likewise observed that the file protocol page that was originally 113K bloats to 604k in version 1.4.16.


    compared headers some difference as follows


    1.4.15c
    header
    (0008,2111) ST [Lossless JPEG compression, selection value 1, point transform 0, compression ratio 15.966 [Lossless JPEG compression, selection value 1, point transform 0, compression ratio 15.966] ] # 182 DerivationDescription
    (0028,0101) US 12 # 2 BitsStored
    (0028,0102) US 11 # 2 HighBit






    1.4.16h
    header
    (0008,2111) ST [Lossless JPEG compression, selection value 1, point transform 0, compression ratio 15.966 ] # 90 DerivationDescription
    (0028,0101) US 16 # 2 BitsStored
    (0028,0102) US 15 # 2 HighBit


    both transaction is sop
    SCStorageSingleBitMF 1.2.840.10008.5.1.4.1.1.7.1


    returning back to 1.4.15c for now


    ajgg

  • Hi,


    This must be an issue in the new jpeg code that has been in there for while. To clarify:


    enable jpeg compression
    OFF UN is OK
    ON UN is wrong?


    Does the scanner send as jpeg as you can see from the log?


    Marcel

  • Hi,


    This must be an issue in the new jpeg code that has been in there for while. To clarify:


    enable jpeg compression
    OFF UN is OK
    ON UN is wrong?


    Does the scanner send as jpeg as you can see from the log?


    Marcel

  • Hi,


    Sorry for the delay in my replay. It was past 12 midnight.



    Correction: tried a different file and there was no change in size of the uncompressed image. No bloating occurred wioth 1.4.16h. But the corruption remains. The data is lost and replaced by a blank page.


    The error appears when Enable JPEG(2000) support is checked regardless of weather uncompressed or compression is used. When this is unchecked (Enable JPEG(2000) support) the image is fine. So it must be in the code?


    I hope this helps


    ajgg

  • Hi,


    this is are the log of receiving 1.4.16h server


    with jpeg2000 support on ( receiving a CT protocol file)


    Code
    [MRPACS2] Connected by address: 0100007f[MRPACS2] Testing transfer: '1.2.840.10008.1.2' against list #0 = '1.2.840.10008.1.2'[MRPACS2] [MRPACS2] UPACS THREAD 16: STARTED AT: Fri Nov 18 06:35:29 2011[MRPACS2] A-ASSOCIATE-RQ Packet Dump[MRPACS2] Calling Application Title : "LOCAL "[MRPACS2] Called Application Title : "MRPACS2 "[MRPACS2] Application Context : "1.2.840.10008.3.1.1.1", PDU length: 16384[MRPACS2] Number of Proposed Presentation Contexts: 1[MRPACS2] Presentation Context 0 "1.2.840.10008.5.1.4.1.1.7" 1[MRPACS2] Server Command := 0001[MRPACS2] Message ID := 0607[MRPACS2] Move Originator Message ID := 0005[MRPACS2] Move Originator AE := LOCAL [MRPACS2] 0000,0002 26 UI AffectedSOPClassUID "1.2.840.10008.5.1.4.1.1.7" [MRPACS2] 0000,0100 2 US CommandField 1 [MRPACS2] 0000,0110 2 US MessageID 1543 [MRPACS2] 0000,0700 2 US Priority 0 [MRPACS2] 0000,0800 2 US DataSetType 258 [MRPACS2] 0000,1000 56 UI AffectedSOPInstanceU "1.3.12.2.1107.5.1.4.54546.30000006040723363773400001824" [MRPACS2] 0000,1030 6 AE MoveOriginatorApplic "LOCAL " [MRPACS2] 0000,1031 2 US MoveOriginatorMessag 5 [MRPACS2] 0002,0010 17 UI TransferSyntaxUID "1.2.840.10008.1.2" [MRPACS2] Query Tables: DICOMImages[MRPACS2] Columns : ObjectFile, DeviceName[MRPACS2] Where : SOPInstanc = '1.3.12.2.1107.5.1.4.54546.30000006040723363773400001824' AND ImagePat = '8710006'[MRPACS2] Order : (null)[MRPACS2] Query Tables: DICOMImages[MRPACS2] Columns : SOPInstanc,SOPClassUI,ImageNumbe,ImageDate,ImageTime,EchoNumber,NumberOfFr,AcqDate,AcqTime,ReceivingC,AcqNumber,SliceLocat,SamplesPer,PhotoMetri,Rows,Colums,BitsStored,ImageType,ImageID,ImagePat,SeriesInst[MRPACS2] Where : SOPInstanc = '1.3.12.2.1107.5.1.4.54546.30000006040723363773400001824' AND ImagePat = '8710006'[MRPACS2] Order : (null)[MRPACS2] Update Table: DICOMImages[MRPACS2] Updates : SOPInstanc = '1.3.12.2.1107.5.1.4.54546.30000006040723363773400001824', SOPClassUI = '1.2.840.10008.5.1.4.1.1.7', ImageNumbe = '0', ImageDate = '20060408', ImageTime = '142201.281000', SamplesPer = '1', PhotoMetri = 'MONOCHROME2', Rows = '512', Colums = '512', BitsStored = '12', ImageType = 'DERIVED\SECONDARY\OTHER\CT_SOM5 PROT', ImagePat = '8710006', SeriesInst = '1.3.12.2.1107.5.1.4.54546.30000006040723363773400001823', AccessTime = 1321569312, ObjectFile = '8710006\1.3.12.2.1107.5.1.4.54546.30000006040723363773400001823_0501_000000_13215688640000.dcm', DeviceName = 'MAG0'[MRPACS2] Where : SOPInstanc = '1.3.12.2.1107.5.1.4.54546.30000006040723363773400001824' AND ImagePat = '8710006'[MRPACS2] Query Tables: DICOMSeries[MRPACS2] Columns : SeriesInst,SeriesNumb,SeriesDate,SeriesTime,SeriesDesc,Modality,PatientPos,ContrastBo,Manufactur,ModelName,BodyPartEx,ProtocolNa,StationNam,Institutio,FrameOfRef,SeriesPat,StudyInsta[MRPACS2] Where : SeriesInst = '1.3.12.2.1107.5.1.4.54546.30000006040723363773400001823' AND SeriesPat = '8710006'[MRPACS2] Order : (null)[MRPACS2] Update Table: DICOMSeries[MRPACS2] Updates : SeriesInst = '1.3.12.2.1107.5.1.4.54546.30000006040723363773400001823', SeriesNumb = '501', SeriesDate = '20060408', SeriesTime = '142201.234000', SeriesDesc = 'Patient Protocol', Modality = 'CT', Manufactur = 'SIEMENS', ModelName = 'Sensation Cardiac 64', Institutio = 'DAVAO DOCTORS HOSPITAL', SeriesPat = '8710006', StudyInsta = '1.3.12.2.1107.5.1.4.54546.30000006040800233210900000028', AccessTime = 1321569312[MRPACS2] Where : SeriesInst = '1.3.12.2.1107.5.1.4.54546.30000006040723363773400001823' AND SeriesPat = '8710006'[MRPACS2] Query Tables: DICOMStudies[MRPACS2] Columns : StudyInsta,StudyDate,StudyTime,StudyID,StudyDescr,AccessionN,ReferPhysi,PatientsAg,PatientsWe,StudyModal,PatientNam,PatientBir,PatientSex,PatientID[MRPACS2] Where : StudyInsta = '1.3.12.2.1107.5.1.4.54546.30000006040800233210900000028'[MRPACS2] Order : (null)[MRPACS2] Update Table: DICOMStudies[MRPACS2] Updates : StudyInsta = '1.3.12.2.1107.5.1.4.54546.30000006040800233210900000028', StudyDate = '20060408', StudyTime = '134933.609000', StudyID = '1', StudyDescr = 'Cardiac^1CoronaryCTA_DDH (Adult)', AccessionN = 'CS#2550976', ReferPhysi = 'Dr. Batalla', PatientsAg = '079Y', StudyModal = 'CT', PatientNam = 'LA.', PatientBir = '19260917', PatientSex = 'M', PatientID = '8710006', AccessTime = 1321569312[MRPACS2] Where : StudyInsta = '1.3.12.2.1107.5.1.4.54546.30000006040800233210900000028'[MRPACS2] Query Tables: DICOMPatients[MRPACS2] Columns : PatientID,PatientNam,PatientBir,PatientSex[MRPACS2] Where : PatientID = '8710006'[MRPACS2] Order : (null)[MRPACS2] Update Table: DICOMPatients[MRPACS2] Updates : PatientID = '8710006', PatientNam = 'LA.', PatientBir = '19260917', PatientSex = 'M', AccessTime = 1321569312[MRPACS2] Where : PatientID = '8710006'[MRPACS2] Rewritten file: E:\pacs_servers\dicomserver1416\data\8710006\1.3.12.2.1107.5.1.4.54546.30000006040723363773400001823_0501_000000_13215688640000.dcm[MRPACS2] UPACS THREAD 16: ENDED AT: Fri Nov 18 06:35:30 2011[MRPACS2] UPACS THREAD 16: TOTAL RUNNING TIME: 1 SECONDS


    with jpeg2000 support off ( receiving CT protocol file)



    ajgg

  • Hi,


    I do not understand what is going on, the only thing the jpeg support button does is modify dgatesop.lst, which typically affects how the CT would send things. However, I see no difference in the logs, so I would expect that the two sends have equal results. Can you send me the two images?


    Later we can add a small lua script to test where the BitsStored is changed.


    Thanks,


    Marcel

  • Hi,


    I got the images. What software are you using to display these images? The text is in an overlay. The k-pacs viewer puts this overlay above highBit, so if highbit is 11, the overlay value is 4096. If highbit is 15, there is no space to put it and it does not display.


    The question is who sets the highbit differently. The internal jpeg and jpeg2000 codecs might do this, but in this case they are not called. So I believe it is actually the CT scanner who sends this item value differently. For the rest, the images are identical.


    Marcel

  • hi,


    I observed that when I tried updating the files from jpeg 1 to jped 2000 to reduce file size in a new server. I was using kpacs to view results for verification. I will check with our Siemens CT viewer. The files are sent from a siemens scanner. I will check with the philip CT unit. I will get an uncompressed file from both scanners , and send you a copy . In our institution files from modalities are sent uncompressed. All compression is done by the pacs server.


    ajgg

  • Hi,


    Ive identified the problem


    if the jpeg 2000 compression is used and UseKpacsDecompression is set to 1, Kpacs viewer will show blank because it may not have support for jpeg 2000
    if set to UseKpacsDecompression = 0; then image is viewed properly. Its the kpacs viewer. Maybe selecting jpeg2000 should also set UseKpacsDecompression = 0
    unless an update of the kpacs code is done.


    ajgg

  • Hi,


    Confirmed that the problem affects K-pacs and IQ-view. It does not affect efilm and Siemens workstation. It appears when jpeg2000 is enabled but does not appear when using 1.4.15 (previous) compression. Saving back to uncompresssed and disabling the jpeg2000 selection does not undo the problem when the images has been passed through jpeg2000. Again it is unique to the k-pacs view and IQ-view. I will check with osirix.


    ajgg

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!