1. Forum
  2. Usenet
  3. COMP.PROTOCOLS.DICOM

  • ALPINION: Inverted Width / Height in JPEG bitstream

    From Mathieu Malaterre@21:1/5 to All on Wed Dec 15 06:41:15 2021
    I've just received a bug report that GDCM is actually doing what the standard mandates:

    * https://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_8.2.html#para_07617cc6-a4a9-4751-9435-7b496910168d

    [...]
    When decompressing, should the characteristics explicitly specified in the compressed data stream (e.g., spatial subsampling or number of components or planar configuration) be inconsistent with those specified in the DICOM Data Elements, those
    explicitly specified in the compressed data stream should be used to control the decompression.
    [...]

    Here is a test image from the "wild" :

    * https://sourceforge.net/p/gdcm/bugs/528/attachment/original.dcm

    References:
    * https://sourceforge.net/p/gdcm/bugs/528/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Gobbi@21:1/5 to All on Wed Dec 15 10:54:43 2021
    However, that same paragraph concludes with:

    The DICOM data elements, if inconsistent, can be regarded as suggestions as to the form in which an uncompressed Data Set might be encoded, subject to the general and IOD-specific rules for uncompressed Photometric Interpretation and Planar
    Configuration, which may require that decompressed data be converted to one of the permitted forms.

    So I disagree that the standard "mandates" that you keep the dimensions. What the standard actually says is that you must use the embedded JPEG dimensions for decompression, but afterwards you may apply additional conversions to make the image match the
    DICOM data elements according to the IOD. The real problem, as far as I'm concerned, is that the standard gives no details on "how" those additional conversions are to be done.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mathieu Malaterre@21:1/5 to david...@gmail.com on Thu Dec 16 00:43:51 2021
    On Wednesday, December 15, 2021 at 7:54:45 PM UTC+1, david...@gmail.com wrote:
    However, that same paragraph concludes with:

    The DICOM data elements, if inconsistent, can be regarded as suggestions as to the form in which an uncompressed Data Set might be encoded, subject to the general and IOD-specific rules for uncompressed Photometric Interpretation and Planar
    Configuration, which may require that decompressed data be converted to one of the permitted forms.

    So I disagree that the standard "mandates" that you keep the dimensions. What the standard actually says is that you must use the embedded JPEG dimensions for decompression, but afterwards you may apply additional conversions to make the image match
    the DICOM data elements according to the IOD. The real problem, as far as I'm concerned, is that the standard gives no details on "how" those additional conversions are to be done.

    This paragraph list only two possibilities "[...]Photometric Interpretation and Planar Configuration[...]". I read them as `Enumerated Values` (*), those cannot be extended by implementers.

    To give another example: Samples per Pixel & Bits Allocated cannot imply additional conversion steps. If JPEG SOF marker is inconsistent with those, one should use those and only those contained in the JPEG bitstream.

    Anyway, I'll do my homework and report the issue upstream. Online shaming has never been very effective ;)

    (*) https://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_6.3.html#sect_6.3

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