• 16 bits per sample Secondary Capture

    From Koua Yang@21:1/5 to All on Mon Mar 15 17:18:38 2021
    Hi,
    I was hoping to get some guidance. I'm trying to encode a 16 bit per channel color image (PNM) into the Secondary Capture IOD. I think I'm setting the important tags correctly:

    Samples Per Pixel (0028,0002) : 3
    Photometric Interpretation (0028,0004): RGB
    Bits Allocated (0028,0100): 16
    Bits Stored (0028,0101): 16
    High Bit (0028,0102): 15
    Pixel Representation (0028,0103): 0

    But when I try view my secondary capture in a dicom viewer, the resolution and image is correct but the colors are completely wrong. When I use a 8 bit image (3 samples per pixel, 8 bits allocated, RGB) with my code, the viewer displays it correctly. I
    started looking around the internet for 16 bits per sample Secondary Captures and there do not seem to be any around. Or even any IODs that has RGB, 3 samples per pixel, 16 bit allocated images. Am I missing some here? Or are the tools I am using just
    don't support displaying 16-bit images? I will admit I am not an image processing expert so my terminology may be off.

    For reference here's my DICOM dump:
    0: [0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ 132: (0002,0000) UL #4 [192] FileMetaInformationGroupLength
    144: (0002,0001) OB #2 [0\1] FileMetaInformationVersion
    158: (0002,0002) UI #26 [1.2.840.10008.5.1.4.1.1.7] MediaStorageSOPClassUID 192: (0002,0003) UI #46 [1.2.826.0.1.3680043.9.3574.1.1.21151904.1.1.1] MediaS 246: (0002,0010) UI #18 [1.2.840.10008.1.2] TransferSyntaxUID
    272: (0002,0012) UI #16 [1.2.40.0.13.1.1] ImplementationClassUID
    296: (0002,0013) SH #14 [dcm4che-3.3.7] ImplementationVersionName
    318: (0002,0016) SH #10 [IMAGEMOVER] SourceApplicationEntityTitle
    336: (0008,0005) CS #10 [ISO_IR 100] SpecificCharacterSet
    354: (0008,0008) CS #16 [ORIGINAL\PRIMARY] ImageType
    378: (0008,0012) DA #8 [20210315] InstanceCreationDate
    394: (0008,0013) TM #10 [190424.184] InstanceCreationTime
    412: (0008,0016) UI #26 [1.2.840.10008.5.1.4.1.1.7] SOPClassUID
    446: (0008,0018) UI #46 [1.2.826.0.1.3680043.9.3574.1.1.21151904.1.1.1] SOPIns 500: (0008,0020) DA #8 [20210315] StudyDate
    516: (0008,0021) DA #8 [20210315] SeriesDate
    532: (0008,0022) DA #8 [20190125] AcquisitionDate
    548: (0008,0023) DA #8 [20190125] ContentDate
    564: (0008,0030) TM #10 [190421.336] StudyTime
    582: (0008,0031) TM #10 [190421.336] SeriesTime
    600: (0008,0032) TM #10 [045839.000] AcquisitionTime
    618: (0008,0033) TM #10 [045839.000] ContentTime
    636: (0008,0050) SH #16 [009001000000011] AccessionNumber
    660: (0008,0060) CS #2 [VL] Modality
    670: (0008,0064) CS #4 [WSD] ConversionType
    682: (0008,0070) LO #12 [XXXX] Manufacturer
    702: (0008,0080) LO #10 [Hospital A] InstitutionName
    720: (0008,0090) PN #0 [] ReferringPhysicianName
    728: (0008,1010) SH #0 [] StationName
    736: (0008,1030) LO #24 [PATHOLOGY VIDEO Abdomen] StudyDescription
    768: (0008,103E) LO #8 [Abdomen] SeriesDescription
    784: (0008,1040) LO #0 [] InstitutionalDepartmentName
    792: (0008,1048) PN #0 [] PhysiciansOfRecord
    800: (0008,1050) PN #0 [] PerformingPhysicianName
    808: (0008,1052) SQ #-1 PerformingPhysicianIdentificationSequence
    816: (FFFE,E000) #-1 Item #1
    824: >(0040,1101) SQ #-1 PersonIdentificationCodeSequence
    832: >(FFFE,E000) #-1 Item #1
    840: >>(0008,0080) LO #10 [Hospital A] InstitutionName
    858: >>(0008,0100) SH #0 [] CodeValue
    866: >>(0008,0102) SH #4 [NPI] CodingSchemeDesignator
    878: >>(0008,0104) LO #12 [Provider ID] CodeMeaning
    898: >(FFFE,E00D) #0 ItemDelimitationItem
    906: >(FFFE,E0DD) #0 SequenceDelimitationItem
    914: (FFFE,E00D) #0 ItemDelimitationItem
    922: (FFFE,E0DD) #0 SequenceDelimitationItem
    930: (0008,1060) PN #0 [] NameOfPhysiciansReadingStudy
    938: (0008,1070) PN #0 [] OperatorsName
    946: (0008,1090) LO #10 [XXXX] ManufacturerModelName
    964: (0010,0010) PN #10 [XXXX] PatientName
    982: (0010,0020) LO #8 [6789abc] PatientID
    998: (0010,0021) LO #0 [] IssuerOfPatientID
    1006: (0010,0030) DA #8 [19610929] PatientBirthDate
    1022: (0010,0040) CS #2 [M] PatientSex
    1032: (0018,0015) CS #8 [ABDOMEN] BodyPartExamined
    1048: (0018,1020) LO #0 [] SoftwareVersions
    1056: (0020,000D) UI #40 [1.2.826.0.1.3680043.9.3574.1.1.21151904] StudyInstan 1104: (0020,000E) UI #44 [1.2.826.0.1.3680043.9.3574.1.1.21151904.1.1] SeriesI 1156: (0020,0010) SH #2 [1] StudyID
    1166: (0020,0011) IS #4 [300] SeriesNumber
    1178: (0020,0013) IS #2 [1] InstanceNumber
    1188: (0020,0020) CS #0 [] PatientOrientation
    1196: (0020,0060) CS #0 [] Laterality
    1204: (0028,0002) US #2 [3] SamplesPerPixel
    1214: (0028,0004) CS #4 [RGB] PhotometricInterpretation
    1226: (0028,0006) US #2 [0] PlanarConfiguration
    1236: (0028,0008) IS #2 [1] NumberOfFrames
    1246: (0028,0010) US #2 [1048] Rows
    1256: (0028,0011) US #2 [1572] Columns
    1266: (0028,0100) US #2 [16] BitsAllocated
    1276: (0028,0101) US #2 [16] BitsStored
    1286: (0028,0102) US #2 [15] HighBit
    1296: (0028,0103) US #2 [0] PixelRepresentation
    1306: (0028,0301) CS #2 [NO] BurnedInAnnotation
    1316: (0032,1032) PN #0 [] RequestingPhysician
    1324: (0038,0400) LO #10 [Outpatient] PatientInstitutionResidence
    1342: (7FE0,0010) OW #9884736 [-13753\-22955\32619\-1712\14432\-6539\26448\649

    I appreciate any help. Thanks.

    Koua

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jason Klotzer@21:1/5 to ko...@witsmd.com on Mon Mar 15 21:09:13 2021
    On Monday, March 15, 2021 at 7:18:40 PM UTC-5, ko...@witsmd.com wrote:
    Hi,
    I was hoping to get some guidance. I'm trying to encode a 16 bit per channel color image (PNM) into the Secondary Capture IOD. I think I'm setting the important tags correctly:

    Samples Per Pixel (0028,0002) : 3
    Photometric Interpretation (0028,0004): RGB
    Bits Allocated (0028,0100): 16
    Bits Stored (0028,0101): 16
    High Bit (0028,0102): 15
    Pixel Representation (0028,0103): 0

    But when I try view my secondary capture in a dicom viewer, the resolution and image is correct but the colors are completely wrong. When I use a 8 bit image (3 samples per pixel, 8 bits allocated, RGB) with my code, the viewer displays it correctly. I
    started looking around the internet for 16 bits per sample Secondary Captures and there do not seem to be any around. Or even any IODs that has RGB, 3 samples per pixel, 16 bit allocated images. Am I missing some here? Or are the tools I am using just
    don't support displaying 16-bit images? I will admit I am not an image processing expert so my terminology may be off.

    For reference here's my DICOM dump:
    0: [0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
    132: (0002,0000) UL #4 [192] FileMetaInformationGroupLength
    144: (0002,0001) OB #2 [0\1] FileMetaInformationVersion
    158: (0002,0002) UI #26 [1.2.840.10008.5.1.4.1.1.7] MediaStorageSOPClassUID 192: (0002,0003) UI #46 [1.2.826.0.1.3680043.9.3574.1.1.21151904.1.1.1] MediaS
    246: (0002,0010) UI #18 [1.2.840.10008.1.2] TransferSyntaxUID
    272: (0002,0012) UI #16 [1.2.40.0.13.1.1] ImplementationClassUID
    296: (0002,0013) SH #14 [dcm4che-3.3.7] ImplementationVersionName
    318: (0002,0016) SH #10 [IMAGEMOVER] SourceApplicationEntityTitle
    336: (0008,0005) CS #10 [ISO_IR 100] SpecificCharacterSet
    354: (0008,0008) CS #16 [ORIGINAL\PRIMARY] ImageType
    378: (0008,0012) DA #8 [20210315] InstanceCreationDate
    394: (0008,0013) TM #10 [190424.184] InstanceCreationTime
    412: (0008,0016) UI #26 [1.2.840.10008.5.1.4.1.1.7] SOPClassUID
    446: (0008,0018) UI #46 [1.2.826.0.1.3680043.9.3574.1.1.21151904.1.1.1] SOPIns
    500: (0008,0020) DA #8 [20210315] StudyDate
    516: (0008,0021) DA #8 [20210315] SeriesDate
    532: (0008,0022) DA #8 [20190125] AcquisitionDate
    548: (0008,0023) DA #8 [20190125] ContentDate
    564: (0008,0030) TM #10 [190421.336] StudyTime
    582: (0008,0031) TM #10 [190421.336] SeriesTime
    600: (0008,0032) TM #10 [045839.000] AcquisitionTime
    618: (0008,0033) TM #10 [045839.000] ContentTime
    636: (0008,0050) SH #16 [009001000000011] AccessionNumber
    660: (0008,0060) CS #2 [VL] Modality
    670: (0008,0064) CS #4 [WSD] ConversionType
    682: (0008,0070) LO #12 [XXXX] Manufacturer
    702: (0008,0080) LO #10 [Hospital A] InstitutionName
    720: (0008,0090) PN #0 [] ReferringPhysicianName
    728: (0008,1010) SH #0 [] StationName
    736: (0008,1030) LO #24 [PATHOLOGY VIDEO Abdomen] StudyDescription
    768: (0008,103E) LO #8 [Abdomen] SeriesDescription
    784: (0008,1040) LO #0 [] InstitutionalDepartmentName
    792: (0008,1048) PN #0 [] PhysiciansOfRecord
    800: (0008,1050) PN #0 [] PerformingPhysicianName
    808: (0008,1052) SQ #-1 PerformingPhysicianIdentificationSequence
    816: (FFFE,E000) #-1 Item #1
    824: >(0040,1101) SQ #-1 PersonIdentificationCodeSequence
    832: >(FFFE,E000) #-1 Item #1
    840: >>(0008,0080) LO #10 [Hospital A] InstitutionName
    858: >>(0008,0100) SH #0 [] CodeValue
    866: >>(0008,0102) SH #4 [NPI] CodingSchemeDesignator
    878: >>(0008,0104) LO #12 [Provider ID] CodeMeaning
    898: >(FFFE,E00D) #0 ItemDelimitationItem
    906: >(FFFE,E0DD) #0 SequenceDelimitationItem
    914: (FFFE,E00D) #0 ItemDelimitationItem
    922: (FFFE,E0DD) #0 SequenceDelimitationItem
    930: (0008,1060) PN #0 [] NameOfPhysiciansReadingStudy
    938: (0008,1070) PN #0 [] OperatorsName
    946: (0008,1090) LO #10 [XXXX] ManufacturerModelName
    964: (0010,0010) PN #10 [XXXX] PatientName
    982: (0010,0020) LO #8 [6789abc] PatientID
    998: (0010,0021) LO #0 [] IssuerOfPatientID
    1006: (0010,0030) DA #8 [19610929] PatientBirthDate
    1022: (0010,0040) CS #2 [M] PatientSex
    1032: (0018,0015) CS #8 [ABDOMEN] BodyPartExamined
    1048: (0018,1020) LO #0 [] SoftwareVersions
    1056: (0020,000D) UI #40 [1.2.826.0.1.3680043.9.3574.1.1.21151904] StudyInstan
    1104: (0020,000E) UI #44 [1.2.826.0.1.3680043.9.3574.1.1.21151904.1.1] SeriesI
    1156: (0020,0010) SH #2 [1] StudyID
    1166: (0020,0011) IS #4 [300] SeriesNumber
    1178: (0020,0013) IS #2 [1] InstanceNumber
    1188: (0020,0020) CS #0 [] PatientOrientation
    1196: (0020,0060) CS #0 [] Laterality
    1204: (0028,0002) US #2 [3] SamplesPerPixel
    1214: (0028,0004) CS #4 [RGB] PhotometricInterpretation
    1226: (0028,0006) US #2 [0] PlanarConfiguration
    1236: (0028,0008) IS #2 [1] NumberOfFrames
    1246: (0028,0010) US #2 [1048] Rows
    1256: (0028,0011) US #2 [1572] Columns
    1266: (0028,0100) US #2 [16] BitsAllocated
    1276: (0028,0101) US #2 [16] BitsStored
    1286: (0028,0102) US #2 [15] HighBit
    1296: (0028,0103) US #2 [0] PixelRepresentation
    1306: (0028,0301) CS #2 [NO] BurnedInAnnotation
    1316: (0032,1032) PN #0 [] RequestingPhysician
    1324: (0038,0400) LO #10 [Outpatient] PatientInstitutionResidence
    1342: (7FE0,0010) OW #9884736 [-13753\-22955\32619\-1712\14432\-6539\26448\649

    I appreciate any help. Thanks.

    Koua

    Bits allocated for a true color secondary capture should be 8. I believe that is the max per channel with a color SC. Please see http://dicom.nema.org/dicom/2013/output/chtml/part03/sect_A.8.html, specifically 8.5.4.

    Also, the viewer you're using probably doesn't support 16-bit per color channel.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Koua Yang@21:1/5 to jklo...@google.com on Mon Mar 15 21:48:52 2021
    On Monday, March 15, 2021 at 11:09:15 PM UTC-5, jklo...@google.com wrote:
    On Monday, March 15, 2021 at 7:18:40 PM UTC-5, ko...@witsmd.com wrote:
    Hi,
    I was hoping to get some guidance. I'm trying to encode a 16 bit per channel color image (PNM) into the Secondary Capture IOD. I think I'm setting the important tags correctly:

    Samples Per Pixel (0028,0002) : 3
    Photometric Interpretation (0028,0004): RGB
    Bits Allocated (0028,0100): 16
    Bits Stored (0028,0101): 16
    High Bit (0028,0102): 15
    Pixel Representation (0028,0103): 0

    But when I try view my secondary capture in a dicom viewer, the resolution and image is correct but the colors are completely wrong. When I use a 8 bit image (3 samples per pixel, 8 bits allocated, RGB) with my code, the viewer displays it correctly.
    I started looking around the internet for 16 bits per sample Secondary Captures and there do not seem to be any around. Or even any IODs that has RGB, 3 samples per pixel, 16 bit allocated images. Am I missing some here? Or are the tools I am using just
    don't support displaying 16-bit images? I will admit I am not an image processing expert so my terminology may be off.

    For reference here's my DICOM dump:
    0: [0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
    132: (0002,0000) UL #4 [192] FileMetaInformationGroupLength
    144: (0002,0001) OB #2 [0\1] FileMetaInformationVersion
    158: (0002,0002) UI #26 [1.2.840.10008.5.1.4.1.1.7] MediaStorageSOPClassUID
    192: (0002,0003) UI #46 [1.2.826.0.1.3680043.9.3574.1.1.21151904.1.1.1] MediaS
    246: (0002,0010) UI #18 [1.2.840.10008.1.2] TransferSyntaxUID
    272: (0002,0012) UI #16 [1.2.40.0.13.1.1] ImplementationClassUID
    296: (0002,0013) SH #14 [dcm4che-3.3.7] ImplementationVersionName
    318: (0002,0016) SH #10 [IMAGEMOVER] SourceApplicationEntityTitle
    336: (0008,0005) CS #10 [ISO_IR 100] SpecificCharacterSet
    354: (0008,0008) CS #16 [ORIGINAL\PRIMARY] ImageType
    378: (0008,0012) DA #8 [20210315] InstanceCreationDate
    394: (0008,0013) TM #10 [190424.184] InstanceCreationTime
    412: (0008,0016) UI #26 [1.2.840.10008.5.1.4.1.1.7] SOPClassUID
    446: (0008,0018) UI #46 [1.2.826.0.1.3680043.9.3574.1.1.21151904.1.1.1] SOPIns
    500: (0008,0020) DA #8 [20210315] StudyDate
    516: (0008,0021) DA #8 [20210315] SeriesDate
    532: (0008,0022) DA #8 [20190125] AcquisitionDate
    548: (0008,0023) DA #8 [20190125] ContentDate
    564: (0008,0030) TM #10 [190421.336] StudyTime
    582: (0008,0031) TM #10 [190421.336] SeriesTime
    600: (0008,0032) TM #10 [045839.000] AcquisitionTime
    618: (0008,0033) TM #10 [045839.000] ContentTime
    636: (0008,0050) SH #16 [009001000000011] AccessionNumber
    660: (0008,0060) CS #2 [VL] Modality
    670: (0008,0064) CS #4 [WSD] ConversionType
    682: (0008,0070) LO #12 [XXXX] Manufacturer
    702: (0008,0080) LO #10 [Hospital A] InstitutionName
    720: (0008,0090) PN #0 [] ReferringPhysicianName
    728: (0008,1010) SH #0 [] StationName
    736: (0008,1030) LO #24 [PATHOLOGY VIDEO Abdomen] StudyDescription
    768: (0008,103E) LO #8 [Abdomen] SeriesDescription
    784: (0008,1040) LO #0 [] InstitutionalDepartmentName
    792: (0008,1048) PN #0 [] PhysiciansOfRecord
    800: (0008,1050) PN #0 [] PerformingPhysicianName
    808: (0008,1052) SQ #-1 PerformingPhysicianIdentificationSequence
    816: (FFFE,E000) #-1 Item #1
    824: >(0040,1101) SQ #-1 PersonIdentificationCodeSequence
    832: >(FFFE,E000) #-1 Item #1
    840: >>(0008,0080) LO #10 [Hospital A] InstitutionName
    858: >>(0008,0100) SH #0 [] CodeValue
    866: >>(0008,0102) SH #4 [NPI] CodingSchemeDesignator
    878: >>(0008,0104) LO #12 [Provider ID] CodeMeaning
    898: >(FFFE,E00D) #0 ItemDelimitationItem
    906: >(FFFE,E0DD) #0 SequenceDelimitationItem
    914: (FFFE,E00D) #0 ItemDelimitationItem
    922: (FFFE,E0DD) #0 SequenceDelimitationItem
    930: (0008,1060) PN #0 [] NameOfPhysiciansReadingStudy
    938: (0008,1070) PN #0 [] OperatorsName
    946: (0008,1090) LO #10 [XXXX] ManufacturerModelName
    964: (0010,0010) PN #10 [XXXX] PatientName
    982: (0010,0020) LO #8 [6789abc] PatientID
    998: (0010,0021) LO #0 [] IssuerOfPatientID
    1006: (0010,0030) DA #8 [19610929] PatientBirthDate
    1022: (0010,0040) CS #2 [M] PatientSex
    1032: (0018,0015) CS #8 [ABDOMEN] BodyPartExamined
    1048: (0018,1020) LO #0 [] SoftwareVersions
    1056: (0020,000D) UI #40 [1.2.826.0.1.3680043.9.3574.1.1.21151904] StudyInstan
    1104: (0020,000E) UI #44 [1.2.826.0.1.3680043.9.3574.1.1.21151904.1.1] SeriesI
    1156: (0020,0010) SH #2 [1] StudyID
    1166: (0020,0011) IS #4 [300] SeriesNumber
    1178: (0020,0013) IS #2 [1] InstanceNumber
    1188: (0020,0020) CS #0 [] PatientOrientation
    1196: (0020,0060) CS #0 [] Laterality
    1204: (0028,0002) US #2 [3] SamplesPerPixel
    1214: (0028,0004) CS #4 [RGB] PhotometricInterpretation
    1226: (0028,0006) US #2 [0] PlanarConfiguration
    1236: (0028,0008) IS #2 [1] NumberOfFrames
    1246: (0028,0010) US #2 [1048] Rows
    1256: (0028,0011) US #2 [1572] Columns
    1266: (0028,0100) US #2 [16] BitsAllocated
    1276: (0028,0101) US #2 [16] BitsStored
    1286: (0028,0102) US #2 [15] HighBit
    1296: (0028,0103) US #2 [0] PixelRepresentation
    1306: (0028,0301) CS #2 [NO] BurnedInAnnotation
    1316: (0032,1032) PN #0 [] RequestingPhysician
    1324: (0038,0400) LO #10 [Outpatient] PatientInstitutionResidence
    1342: (7FE0,0010) OW #9884736 [-13753\-22955\32619\-1712\14432\-6539\26448\649

    I appreciate any help. Thanks.

    Koua
    Bits allocated for a true color secondary capture should be 8. I believe that is the max per channel with a color SC. Please see http://dicom.nema.org/dicom/2013/output/chtml/part03/sect_A.8.html, specifically 8.5.4.

    Also, the viewer you're using probably doesn't support 16-bit per color channel.

    Hi,
    Thanks for the response. So a few follow up questions for my understanding:
    1. I do see that the true color secondary capture iod specifies 8 bits per channel (sample). I did come across supplement 57, which introduced true color secondary capture but I didn't see any reasoning as to why it was capped at 8 bits per channel.
    Would you happen to know the reasoning behind limiting true color to 8 bits per sample?
    2. So in theory, if there was a DICOM viewer that supported 16 bits per channel, would what I have above be valid?
    3. So are we saying the recommendation for 16 bits per channel images be to convert the image to 8 bits per channel images because the true color secondary capture iod limits us to 8 bits?

    Again, I appreciate the help.

    Koua

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mathieu Malaterre@21:1/5 to jklo...@google.com on Tue Mar 16 00:04:08 2021
    On Tuesday, March 16, 2021 at 5:09:15 AM UTC+1, jklo...@google.com wrote:
    On Monday, March 15, 2021 at 7:18:40 PM UTC-5, ko...@witsmd.com wrote:
    Hi,
    I was hoping to get some guidance. I'm trying to encode a 16 bit per channel color image (PNM) into the Secondary Capture IOD. I think I'm setting the important tags correctly:

    Samples Per Pixel (0028,0002) : 3
    Photometric Interpretation (0028,0004): RGB
    Bits Allocated (0028,0100): 16
    Bits Stored (0028,0101): 16
    High Bit (0028,0102): 15
    Pixel Representation (0028,0103): 0

    But when I try view my secondary capture in a dicom viewer, the resolution and image is correct but the colors are completely wrong. When I use a 8 bit image (3 samples per pixel, 8 bits allocated, RGB) with my code, the viewer displays it correctly.
    I started looking around the internet for 16 bits per sample Secondary Captures and there do not seem to be any around. Or even any IODs that has RGB, 3 samples per pixel, 16 bit allocated images. Am I missing some here? Or are the tools I am using just
    don't support displaying 16-bit images? I will admit I am not an image processing expert so my terminology may be off.

    For reference here's my DICOM dump:
    0: [0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
    132: (0002,0000) UL #4 [192] FileMetaInformationGroupLength
    144: (0002,0001) OB #2 [0\1] FileMetaInformationVersion
    158: (0002,0002) UI #26 [1.2.840.10008.5.1.4.1.1.7] MediaStorageSOPClassUID
    192: (0002,0003) UI #46 [1.2.826.0.1.3680043.9.3574.1.1.21151904.1.1.1] MediaS
    246: (0002,0010) UI #18 [1.2.840.10008.1.2] TransferSyntaxUID
    272: (0002,0012) UI #16 [1.2.40.0.13.1.1] ImplementationClassUID
    296: (0002,0013) SH #14 [dcm4che-3.3.7] ImplementationVersionName
    318: (0002,0016) SH #10 [IMAGEMOVER] SourceApplicationEntityTitle
    336: (0008,0005) CS #10 [ISO_IR 100] SpecificCharacterSet
    354: (0008,0008) CS #16 [ORIGINAL\PRIMARY] ImageType
    378: (0008,0012) DA #8 [20210315] InstanceCreationDate
    394: (0008,0013) TM #10 [190424.184] InstanceCreationTime
    412: (0008,0016) UI #26 [1.2.840.10008.5.1.4.1.1.7] SOPClassUID
    446: (0008,0018) UI #46 [1.2.826.0.1.3680043.9.3574.1.1.21151904.1.1.1] SOPIns
    500: (0008,0020) DA #8 [20210315] StudyDate
    516: (0008,0021) DA #8 [20210315] SeriesDate
    532: (0008,0022) DA #8 [20190125] AcquisitionDate
    548: (0008,0023) DA #8 [20190125] ContentDate
    564: (0008,0030) TM #10 [190421.336] StudyTime
    582: (0008,0031) TM #10 [190421.336] SeriesTime
    600: (0008,0032) TM #10 [045839.000] AcquisitionTime
    618: (0008,0033) TM #10 [045839.000] ContentTime
    636: (0008,0050) SH #16 [009001000000011] AccessionNumber
    660: (0008,0060) CS #2 [VL] Modality
    670: (0008,0064) CS #4 [WSD] ConversionType
    682: (0008,0070) LO #12 [XXXX] Manufacturer
    702: (0008,0080) LO #10 [Hospital A] InstitutionName
    720: (0008,0090) PN #0 [] ReferringPhysicianName
    728: (0008,1010) SH #0 [] StationName
    736: (0008,1030) LO #24 [PATHOLOGY VIDEO Abdomen] StudyDescription
    768: (0008,103E) LO #8 [Abdomen] SeriesDescription
    784: (0008,1040) LO #0 [] InstitutionalDepartmentName
    792: (0008,1048) PN #0 [] PhysiciansOfRecord
    800: (0008,1050) PN #0 [] PerformingPhysicianName
    808: (0008,1052) SQ #-1 PerformingPhysicianIdentificationSequence
    816: (FFFE,E000) #-1 Item #1
    824: >(0040,1101) SQ #-1 PersonIdentificationCodeSequence
    832: >(FFFE,E000) #-1 Item #1
    840: >>(0008,0080) LO #10 [Hospital A] InstitutionName
    858: >>(0008,0100) SH #0 [] CodeValue
    866: >>(0008,0102) SH #4 [NPI] CodingSchemeDesignator
    878: >>(0008,0104) LO #12 [Provider ID] CodeMeaning
    898: >(FFFE,E00D) #0 ItemDelimitationItem
    906: >(FFFE,E0DD) #0 SequenceDelimitationItem
    914: (FFFE,E00D) #0 ItemDelimitationItem
    922: (FFFE,E0DD) #0 SequenceDelimitationItem
    930: (0008,1060) PN #0 [] NameOfPhysiciansReadingStudy
    938: (0008,1070) PN #0 [] OperatorsName
    946: (0008,1090) LO #10 [XXXX] ManufacturerModelName
    964: (0010,0010) PN #10 [XXXX] PatientName
    982: (0010,0020) LO #8 [6789abc] PatientID
    998: (0010,0021) LO #0 [] IssuerOfPatientID
    1006: (0010,0030) DA #8 [19610929] PatientBirthDate
    1022: (0010,0040) CS #2 [M] PatientSex
    1032: (0018,0015) CS #8 [ABDOMEN] BodyPartExamined
    1048: (0018,1020) LO #0 [] SoftwareVersions
    1056: (0020,000D) UI #40 [1.2.826.0.1.3680043.9.3574.1.1.21151904] StudyInstan
    1104: (0020,000E) UI #44 [1.2.826.0.1.3680043.9.3574.1.1.21151904.1.1] SeriesI
    1156: (0020,0010) SH #2 [1] StudyID
    1166: (0020,0011) IS #4 [300] SeriesNumber
    1178: (0020,0013) IS #2 [1] InstanceNumber
    1188: (0020,0020) CS #0 [] PatientOrientation
    1196: (0020,0060) CS #0 [] Laterality
    1204: (0028,0002) US #2 [3] SamplesPerPixel
    1214: (0028,0004) CS #4 [RGB] PhotometricInterpretation
    1226: (0028,0006) US #2 [0] PlanarConfiguration
    1236: (0028,0008) IS #2 [1] NumberOfFrames
    1246: (0028,0010) US #2 [1048] Rows
    1256: (0028,0011) US #2 [1572] Columns
    1266: (0028,0100) US #2 [16] BitsAllocated
    1276: (0028,0101) US #2 [16] BitsStored
    1286: (0028,0102) US #2 [15] HighBit
    1296: (0028,0103) US #2 [0] PixelRepresentation
    1306: (0028,0301) CS #2 [NO] BurnedInAnnotation
    1316: (0032,1032) PN #0 [] RequestingPhysician
    1324: (0038,0400) LO #10 [Outpatient] PatientInstitutionResidence
    1342: (7FE0,0010) OW #9884736 [-13753\-22955\32619\-1712\14432\-6539\26448\649

    I appreciate any help. Thanks.

    Koua
    Bits allocated for a true color secondary capture should be 8. I believe that is the max per channel with a color SC. Please see http://dicom.nema.org/dicom/2013/output/chtml/part03/sect_A.8.html, specifically 8.5.4.

    The standard states:

    "The Secondary Capture Image IOD specifies single-frame images that are converted from a non-DICOM format to a modality independent DICOM format, without any constraints on pixel data format."

    ref: http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_A.8.html#sect_A.8.1.1

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Markus Sabin@21:1/5 to All on Tue Mar 16 02:05:53 2021
    The standard states:

    "The Secondary Capture Image IOD specifies single-frame images that are converted from a non-DICOM format to a modality independent DICOM format, without any constraints on pixel data format."

    ref: http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_A.8.html#sect_A.8.1.1

    Yes, but at the same time it states: "The use of this IOD is deprecated, and other more specific SC Image IODs should be used.". And indeed, the new Multi-Frame True Color SC is limited to 8 bits per channel.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?J=C3=B6rg_Riesmeier?=@21:1/5 to All on Tue Mar 16 02:03:50 2021
    So in theory, if there was a DICOM viewer that supported 16 bits per channel, would what I have above be valid?

    You could check this with dcm2pnm from the DCMTK: https://support.dcmtk.org/docs/dcm2pnm.html
    This command line tool should be able to render a 16-bit per channel RGB Secondary Capture Image SOP Instance.

    Regards,
    Jörg

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Koua Yang@21:1/5 to All on Tue Mar 16 07:12:45 2021
    On Tuesday, March 16, 2021 at 4:03:52 AM UTC-5, Jörg Riesmeier wrote:
    So in theory, if there was a DICOM viewer that supported 16 bits per channel, would what I have above be valid?
    You could check this with dcm2pnm from the DCMTK: https://support.dcmtk.org/docs/dcm2pnm.html
    This command line tool should be able to render a 16-bit per channel RGB Secondary Capture Image SOP Instance.

    Regards,
    Jörg
    Hi Jörg,
    I did try dcm2pnm and it gave me a similar picture as the other viewers. The colors were wrong and it convert (at least tried to) the image into a 8-bit image. I tried different options with dcm2pnm but still couldn't a 16-bit image. I did dump the
    pixel data from the DICOM file and manually added a PNM header to the pixel data file. When I did this I was able to open it in an image viewer as 16 bit and everything looked correct. I appreciate the help.

    Koua

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Koua Yang@21:1/5 to marku...@gmail.com on Tue Mar 16 07:25:09 2021
    On Tuesday, March 16, 2021 at 4:05:55 AM UTC-5, marku...@gmail.com wrote:
    The standard states:

    "The Secondary Capture Image IOD specifies single-frame images that are converted from a non-DICOM format to a modality independent DICOM format, without any constraints on pixel data format."

    ref: http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_A.8.html#sect_A.8.1.1
    Yes, but at the same time it states: "The use of this IOD is deprecated, and other more specific SC Image IODs should be used.". And indeed, the new Multi-Frame True Color SC is limited to 8 bits per channel.

    Hi,
    It does seem like most DICOM viewers that I've come across only support 8 bit per channel DICOM images for true color. Which does make sense if DICOM has limited Multi-Frame True Color SC to 8 bits per channel. It's starting to sound like if I want to
    be compatible with most viewers, I'll have to convert my 16 bit image into 8 bit image. I appreciate the help.

    Koua

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jason Klotzer@21:1/5 to ko...@witsmd.com on Tue Mar 16 08:51:42 2021
    On Tuesday, March 16, 2021 at 9:25:13 AM UTC-5, ko...@witsmd.com wrote:
    On Tuesday, March 16, 2021 at 4:05:55 AM UTC-5, marku...@gmail.com wrote:
    The standard states:

    "The Secondary Capture Image IOD specifies single-frame images that are converted from a non-DICOM format to a modality independent DICOM format, without any constraints on pixel data format."

    ref: http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_A.8.html#sect_A.8.1.1
    Yes, but at the same time it states: "The use of this IOD is deprecated, and other more specific SC Image IODs should be used.". And indeed, the new Multi-Frame True Color SC is limited to 8 bits per channel.
    Hi,
    It does seem like most DICOM viewers that I've come across only support 8 bit per channel DICOM images for true color. Which does make sense if DICOM has limited Multi-Frame True Color SC to 8 bits per channel. It's starting to sound like if I want to
    be compatible with most viewers, I'll have to convert my 16 bit image into 8 bit image. I appreciate the help.

    Koua

    Yes, 8-bit per channel RGB is probably the most supported display configuration out there. Nowadays there are a bunch of devices/cameras that output deep color, but display of these images at full depth requires specialized support across the whole
    stack (graphics lib/software, GPU, and monitor).

    The same conversations are often had regarding 10-16 bit per sample Grayscale imaging, where there is the Grayscale Standard Display Function to map the acquisition values to display.

    It looks like there are similar conversations for color, proposing a Color Standard Display Function (CSDF):
    https://aapm.onlinelibrary.wiley.com/doi/full/10.1118/1.4959544

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?J=C3=B6rg_Riesmeier?=@21:1/5 to All on Wed Mar 17 01:24:46 2021
    Hi Koua,

    I did try dcm2pnm and it gave me a similar picture as the other viewers. The colors were wrong and it convert (at least tried to) the image into a 8-bit image. I tried different options with dcm2pnm but still couldn't a 16-bit image. I did dump the
    pixel data from the DICOM file and manually added a PNM header to the pixel data file. When I did this I was able to open it in an image viewer as 16 bit and everything looked correct. I appreciate the help.

    could you make the DICOM image file available for download? dcm2pnm also supports the output of 16 bits per pixel (e.g. PNM and PNG format) if you use the appropriate --write-xxx option: https://support.dcmtk.org/docs/dcm2pnm.html#dcm2pnm_output_options

    Regards,
    Jörg

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mathieu Malaterre@21:1/5 to ko...@witsmd.com on Wed Mar 17 02:25:44 2021
    On Tuesday, March 16, 2021 at 3:25:13 PM UTC+1, ko...@witsmd.com wrote:
    On Tuesday, March 16, 2021 at 4:05:55 AM UTC-5, marku...@gmail.com wrote:
    The standard states:

    "The Secondary Capture Image IOD specifies single-frame images that are converted from a non-DICOM format to a modality independent DICOM format, without any constraints on pixel data format."

    ref: http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_A.8.html#sect_A.8.1.1
    Yes, but at the same time it states: "The use of this IOD is deprecated, and other more specific SC Image IODs should be used.". And indeed, the new Multi-Frame True Color SC is limited to 8 bits per channel.
    Hi,
    It does seem like most DICOM viewers that I've come across only support 8 bit per channel DICOM images for true color. Which does make sense if DICOM has limited Multi-Frame True Color SC to 8 bits per channel. It's starting to sound like if I want to
    be compatible with most viewers, I'll have to convert my 16 bit image into 8 bit image. I appreciate the help.

    Pick a working 16bits / grayscale DICOM image, copy this PixelData buffer in R, G and B channel. Here you go you have a 16bits RGB file. You can then easily confirm whether or not your viewer support 16bits or not.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Koua Yang@21:1/5 to All on Wed Mar 17 11:46:50 2021
    On Wednesday, March 17, 2021 at 3:24:47 AM UTC-5, Jörg Riesmeier wrote:
    Hi Koua,
    I did try dcm2pnm and it gave me a similar picture as the other viewers. The colors were wrong and it convert (at least tried to) the image into a 8-bit image. I tried different options with dcm2pnm but still couldn't a 16-bit image. I did dump the
    pixel data from the DICOM file and manually added a PNM header to the pixel data file. When I did this I was able to open it in an image viewer as 16 bit and everything looked correct. I appreciate the help.
    could you make the DICOM image file available for download? dcm2pnm also supports the output of 16 bits per pixel (e.g. PNM and PNG format) if you use the appropriate --write-xxx option: https://support.dcmtk.org/docs/dcm2pnm.html#dcm2pnm_output_
    options

    Regards,
    Jörg

    Hi Jorg,
    I uploaded the DICOM file (16bitSC.dcm) and the original pnm file (cutter.pnm) here: https://ufile.io/f/lum4v
    To clarify, using dcm2pnm with no options, it creates a 8-bit pnm file which I can open with my image viewer. So it does look like dcm2pnm understands my image is a 16 bits per sample image and converts it to 8 bits per sample. I couldn't get a 16 bit
    image with the other options. But regardless, it sounds like if I want to be compatible with most viewers, I would have to create an 8 bit image, unless you see something wrong with my Secondary Capture which is causing the DICOM viewers not to display
    it correctly. Thanks for the help.

    Koua

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Koua Yang@21:1/5 to All on Wed Mar 17 12:37:55 2021
    On Wednesday, March 17, 2021 at 2:18:59 PM UTC-5, Jörg Riesmeier wrote:
    Hi Kuon,
    I uploaded the DICOM file (16bitSC.dcm) and the original pnm file (cutter.pnm) here: https://ufile.io/f/lum4v
    To clarify, using dcm2pnm with no options, it creates a 8-bit pnm file which I can open with my image viewer. So it does look like dcm2pnm understands my image is a 16 bits per sample image and converts it to 8 bits per sample. I couldn't get a 16
    bit image with the other options.
    I've successfully converted the DICOM file "16bitSC.dcm" with dcm2pnm to 16 bits/sample PNM (option +opw) and to 16 bits/sample PNG (+on2) format. For example, GIMP is able to open these images and displays them correctly.
    But regardless, it sounds like if I want to be compatible with most viewers, I would have to create an 8 bit image, unless you see something wrong with my Secondary Capture which is causing the DICOM viewers not to display it correctly. Thanks for
    the help.
    There are a number of issues with your DICOM file (see validation result of David Clunie's dciodvfy [1]) but none of them is related to the proper rendering of the image. That means the reason for the incorrect display of colors is related to the
    viewers you've used. As others have already noted, many DICOM viewers seem to have problems with this valid but at least for color images unusual bit depth.

    By the way, what is the use case for storing 16 bits per channel for an RGB image?

    Regards,
    Jörg

    [1] https://www.dclunie.com/dicom3tools/dciodvfy.html

    Hi Jorg,
    Thanks for looking into this. I'll try those options you provided.

    By the way, what is the use case for storing 16 bits per channel for an RGB image?

    I hate to answer a question with a question but why would you not want to encode the DICOM SC in the same color depth as the original image? I figure if the customer sent a 16-bits per channel image, I would encode it as 16-bits per channel secondary
    capture. Is this the wrong thinking for secondary capture?

    Koua

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?J=C3=B6rg_Riesmeier?=@21:1/5 to All on Wed Mar 17 12:18:58 2021
    Hi Kuon,

    I uploaded the DICOM file (16bitSC.dcm) and the original pnm file (cutter.pnm) here: https://ufile.io/f/lum4v
    To clarify, using dcm2pnm with no options, it creates a 8-bit pnm file which I can open with my image viewer. So it does look like dcm2pnm understands my image is a 16 bits per sample image and converts it to 8 bits per sample. I couldn't get a 16 bit
    image with the other options.

    I've successfully converted the DICOM file "16bitSC.dcm" with dcm2pnm to 16 bits/sample PNM (option +opw) and to 16 bits/sample PNG (+on2) format. For example, GIMP is able to open these images and displays them correctly.

    But regardless, it sounds like if I want to be compatible with most viewers, I would have to create an 8 bit image, unless you see something wrong with my Secondary Capture which is causing the DICOM viewers not to display it correctly. Thanks for the
    help.

    There are a number of issues with your DICOM file (see validation result of David Clunie's dciodvfy [1]) but none of them is related to the proper rendering of the image. That means the reason for the incorrect display of colors is related to the viewers
    you've used. As others have already noted, many DICOM viewers seem to have problems with this valid but at least for color images unusual bit depth.

    By the way, what is the use case for storing 16 bits per channel for an RGB image?

    Regards,
    Jörg

    [1] https://www.dclunie.com/dicom3tools/dciodvfy.html

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?J=C3=B6rg_Riesmeier?=@21:1/5 to All on Wed Mar 17 13:25:57 2021
    Hi Koua,

    By the way, what is the use case for storing 16 bits per channel for an RGB image?

    I hate to answer a question with a question but why would you not want to encode the DICOM SC in the same color depth as the original image? I figure if the customer sent a 16-bits per channel image, I would encode it as 16-bits per channel secondary
    capture. Is this the wrong thinking for secondary capture?

    it is not wrong thinking but if there would be a "good reason" for storing 16 instead of 8 bits per sample for an RGB image, one could think about defining a new Multi-frame 16 Bit RGB Secondary Captured Image IOD. That's why I was asking for your use
    case. But if there is no real advantage for storing twice as much bits per pixels, I don't think that it would make much sense to submit a work item request to the DICOM committee.

    Of course, you could still use the "old" Secondary Capture Image IOD but many viewers don't seem to fully support it.

    Regards,
    Jörg

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Koua Yang@21:1/5 to All on Wed Mar 17 15:10:24 2021
    On Wednesday, March 17, 2021 at 3:25:58 PM UTC-5, Jörg Riesmeier wrote:
    Hi Koua,
    By the way, what is the use case for storing 16 bits per channel for an RGB image?

    I hate to answer a question with a question but why would you not want to encode the DICOM SC in the same color depth as the original image? I figure if the customer sent a 16-bits per channel image, I would encode it as 16-bits per channel secondary
    capture. Is this the wrong thinking for secondary capture?
    it is not wrong thinking but if there would be a "good reason" for storing 16 instead of 8 bits per sample for an RGB image, one could think about defining a new Multi-frame 16 Bit RGB Secondary Captured Image IOD. That's why I was asking for your use
    case. But if there is no real advantage for storing twice as much bits per pixels, I don't think that it would make much sense to submit a work item request to the DICOM committee.

    Of course, you could still use the "old" Secondary Capture Image IOD but many viewers don't seem to fully support it.

    Regards,
    Jörg

    Hi Jorg,
    That's fair. Our software allows our customers to turn images into secondary capture so it can be viewed on the PACS. I'm not a clinical person but one use case is in dermatology where they would use a camera to take a photo of the area of interest and
    then upload it to the PACS with our software. We take care of associating the secondary capture with the correct patient. But I don't understand the reason why they are now using 16-bps images vs 8-bps images. I just get the customer question : "Why
    can't I upload this photo?" and when I look into it is because our software only support 8-bps images and they are sending us 16-bps images. So I thought the easy fix would be to have our Secondary Capture support 16-bps images. Which is how I ended up
    here. I appreciate the help and guidance. Take care.

    Koua

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Gobbi@21:1/5 to All on Thu Mar 18 12:52:18 2021
    Our software allows our customers to turn images into secondary capture so it can be viewed on the PACS. I'm not a clinical person but one use case is in dermatology where they would use a camera to take a photo of the area of interest and then upload
    it to the PACS with our software.

    Is the file they upload a .pnm file? I haven't heard of PNM being used by cameras. For high bit-depth, it's usually TIFF or DNG or proprietary RAW formats.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Koua Yang@21:1/5 to david...@gmail.com on Thu Mar 18 15:14:42 2021
    On Thursday, March 18, 2021 at 2:52:20 PM UTC-5, david...@gmail.com wrote:
    Our software allows our customers to turn images into secondary capture so it can be viewed on the PACS. I'm not a clinical person but one use case is in dermatology where they would use a camera to take a photo of the area of interest and then
    upload it to the PACS with our software.
    Is the file they upload a .pnm file? I haven't heard of PNM being used by cameras. For high bit-depth, it's usually TIFF or DNG or proprietary RAW formats.

    Hi David,
    You are correct. The customer is using 16-bit TIFF images but we convert it into PNM before encoding into our Secondary Capture. Again, I will fully admit I only know enough about image formats to get by and I don't know the reason why we do this.

    Koua

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Gobbi@21:1/5 to All on Thu Mar 18 15:36:59 2021
    The customer is using 16-bit TIFF images but we convert it into PNM before encoding into our Secondary Capture.

    When the TIFF is converted to PNM, all the camera metadata is lost. This includes important calibration information like the ICC profile, which should ideally be copied over to the DICOM metadata if known:
    http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.11.15.html

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)