![\"https://i.ibb.co/Gs3zFH1/Selection-169.png\"](\"https://i.ibb.co/Gs3zFH1/Selection-169.png\")
TLDR:
\nApprox half the dicoms in the dataset contain jpeg2000 encoded images. There's a way to hack the bitstream and extract/save the jp2 images which can then be decoded on GPU using Nvidia DALI.
pydicom decode per image (parallel mode): 0.88 imgs/sec (32 imgs/36 sec)
\nDALI decode per image: 15.16 imgs/sec (32 imgs/2.03s)
\nSpeedup: 17.7x
Check out the notebook here which contains the minimal decode example. Still working on a way to extract the lossless jpeg bitstream for the other half of dicoms which will then make this technique much more useful in an end-to-end solution.
\nA little more:
\nWhile DALI doesn't support decoding dicom's directly, it does support jpeg2000 decode. So the trick is extracting the jpeg2000 bitstream from the dicom container so DALI can ingest it.
I'm still working on figuring out an analogous hack for the lossless jpeg format. Any inputs welcome.
", "messages": [ { "id": 2061084, "postDate": "2022-12-10T17:09:33.127Z", "content": "TLDR:
\nApprox half the dicoms in the dataset contain jpeg2000 encoded images. There's a way to hack the bitstream and extract/save the jp2 images which can then be decoded on GPU using Nvidia DALI.
pydicom decode per image (parallel mode): 0.88 imgs/sec (32 imgs/36 sec)
\nDALI decode per image: 15.16 imgs/sec (32 imgs/2.03s)
\nSpeedup: 17.7x
Check out the notebook here which contains the minimal decode example. Still working on a way to extract the lossless jpeg bitstream for the other half of dicoms which will then make this technique much more useful in an end-to-end solution.
\nA little more:
\nWhile DALI doesn't support decoding dicom's directly, it does support jpeg2000 decode. So the trick is extracting the jpeg2000 bitstream from the dicom container so DALI can ingest it.
I'm still working on figuring out an analogous hack for the lossless jpeg format. Any inputs welcome.
", "rawMarkdown": "**TLDR:**\nApprox half the dicoms in the dataset contain jpeg2000 encoded images. There's a way to hack the bitstream and extract/save the jp2 images which can then be decoded on GPU using [Nvidia DALI](https://docs.nvidia.com/deeplearning/dali/user-guide/docs/index.html).\n\npydicom decode per image (parallel mode): **0.88** imgs/sec (32 imgs/36 sec)\nDALI decode per image: **15.16** imgs/sec (32 imgs/2.03s)\nSpeedup: **17.7x**\n\nCheck out the [notebook](https://www.kaggle.com/code/tivfrvqhs5/decode-jpeg2000-dicom-with-dali?scriptVersionId=113466193) here which contains the minimal decode example. Still working on a way to extract the lossless jpeg bitstream for the other half of dicoms which will then make this technique much more useful in an end-to-end solution.\n\nA little more:\nWhile DALI doesn't support decoding dicom's directly, it does support jpeg2000 decode. So the trick is extracting the jpeg2000 bitstream from the dicom container so DALI can ingest it.\n\nI'm still working on figuring out an analogous hack for the lossless jpeg format. Any inputs welcome.\n\n\n\n\n\n", "votes": 85 }, { "id": 2063328, "postDate": "2022-12-12T20:06:12.180Z", "content": "Update: The byte string to properly extract lossless jpg images can be done using this offset with the same code as before.
\n\noffset = ds.PixelData.find(b\"\\xff\\xd8\\xff\\xe0\")\n
\nHowever, decode of lossless jpg is not currenly supported by nvjpeg on gpu. For now the best known solution is to combine dali on jpeg2k images with dicomsdl for lossless jpg. @hengck23 just posted a notebook here that combines the two methods beautifully.
The question isn't pydicom versus dicomsdl versus dali, but rather nvjpeg versus gdcm versus libjpeg-turbo versus..
", "rawMarkdown": "The question isn't pydicom versus dicomsdl versus dali, but rather nvjpeg versus gdcm versus libjpeg-turbo versus.." } ] }, { "id": 2064128, "postDate": "2022-12-13T14:36:45.360Z", "content": "
\ni make a mistake. i should be using nvJPEG2K instead
i think your pipeline can be simplified as:
\n#https://github.com/UsingNet/nvjpeg-python\nfrom nvjpeg import NvJpeg\nnj = NvJpeg()\n.....\n\n\n\n dicom = pydicom.dcmread(f)\n if dicom.file_meta.TransferSyntaxUID != '1.2.840.10008.1.2.4.90':\n raise NotImplementedError\n\n byte_stream = dicom.PixelData\n offset = byte_stream.find(b\"\\x00\\x00\\x00\\x0C\")\n jpeg_stream = np.asarray(bytearray(byte_stream[offset:]), dtype='uint8')\n\n #failed because out of memory ...\n m1 = nj.decode(jpeg_stream) \n\n #this works! meaning that i have get the correct jpeg byte string\n m0 = cv2.imdecode(jpeg_stream, cv2.IMREAD_ANYDEPTH)\n print(m0.shape)\n plt.imshow(m0)\nInteresting. Does this actually work? If so, it'd be great to benchmark it. Augmenting off GPU would be better I think. You're going to be quite constrained with the GPU if you're limited to dali augmentation.
", "rawMarkdown": "Interesting. Does this actually work? If so, it'd be great to benchmark it. Augmenting off GPU would be better I think. You're going to be quite constrained with the GPU if you're limited to dali augmentation." }, { "id": 2061312, "postDate": "2022-12-11T01:16:06.217Z", "content": "
\n
i make a mistake. i should be using nvJPEG2K instead
", "rawMarkdown": "~~maybe torch vision already support nvjpeg ???~~\n~~https://pytorch.org/vision/main/generated/torchvision.io.decode_jpeg.html~~\n\n~~\"If a cuda device is specified, the image will be decoded with nvjpeg.\"~~\n\n i make a mistake. i should be using nvJPEG2K instead" }, { "id": 2061313, "postDate": "2022-12-11T01:17:04.137Z", "content": "Dali also uses nvjpeg, nvjpeg2k
", "rawMarkdown": "Dali also uses nvjpeg, nvjpeg2k" }, { "id": 2061318, "postDate": "2022-12-11T01:26:48.660Z", "content": "\n\n
\n
i make a mistake. i should be using nvJPEG2K instead
\nhttps://docs.nvidia.com/cuda/nvjpeg2000/userguide.html
\nJPEG2000 Options:
\n Up to 16 bits per component
\n(nvjpeg is 8bits per component)
Someone should let them know, lol
", "rawMarkdown": "Someone should let them know, lol" }, { "id": 2061359, "postDate": "2022-12-11T03:51:08.073Z", "content": "Dali nightly whl supports 16bit, it uses nvjpeg2k under the hood
", "rawMarkdown": "Dali nightly whl supports 16bit, it uses nvjpeg2k under the hood" } ] }, { "id": 2062485, "postDate": "2022-12-12T06:37:08.850Z", "content": "to quickly identidy the type of jpeg encoding, one can use machine id:
\ntrain_df[['machine_id','TransferSyntaxUID','image_id']].groupby(['machine_id','TransferSyntaxUID']).count()\nOut[7]: \n image_id\nmachine_id TransferSyntaxUID \n21 1.2.840.10008.1.2.4.90 8221\n29 1.2.840.10008.1.2.4.90 8267\n48 1.2.840.10008.1.2.4.90 8699\n49 1.2.840.10008.1.2.4.70 23529\n93 1.2.840.10008.1.2.4.70 1915\n170 1.2.840.10008.1.2.4.70 923\n190 1.2.840.10008.1.2.4.70 145\n197 1.2.840.10008.1.2.4.70 29\n210 1.2.840.10008.1.2.4.70 1070\n216 1.2.840.10008.1.2.4.70 1908\nOr just site id :) Site_id 1 is .70, site_id 2 is .90 .. Need to check if it's the same on the leaderboard
", "rawMarkdown": "Or just site id :) Site_id 1 is .70, site_id 2 is .90 .. Need to check if it's the same on the leaderboard", "votes": 1 }, { "id": 2062834, "postDate": "2022-12-12T13:17:56.317Z", "content": "It makes sense that the dicom format produced would be consistent by machine_id
", "rawMarkdown": "It makes sense that the dicom format produced would be consistent by machine_id" } ] }, { "id": 2061226, "postDate": "2022-12-10T21:04:13.317Z", "content": "Wow. This is something great to know. Kudos.
", "rawMarkdown": "Wow. This is something great to know. Kudos.", "votes": 1 }, { "id": 2143523, "postDate": "2023-02-14T10:13:54.887Z", "content": "Wow! very fast decoding. It must be really useful
", "rawMarkdown": "Wow! very fast decoding. It must be really useful\n" }, { "id": 2139878, "postDate": "2023-02-11T08:53:52.587Z", "content": "hi , i get this error when use notebook ;
\ncan help me?
RuntimeError: Critical error in pipeline:
\nError when executing Mixed operator experimental__decoders__Image encountered:
\nError in thread 0: [/opt/dali/dali/imgcodec/image_decoder.cc:448] Cannot parse the image:
\nStacktrace (7 entries):
\n[frame 0]: /opt/conda/lib/python3.7/site-packages/nvidia/dali/libdali_imgcodec.so(+0x94bcb) [0x7f8ef22d6bcb]
\n[frame 1]: /opt/conda/lib/python3.7/site-packages/nvidia/dali/libdali_imgcodec.so(+0x6bb18) [0x7f8ef22adb18]
\n[frame 2]: /opt/conda/lib/python3.7/site-packages/nvidia/dali/libdali_operators.so(+0x26ce484) [0x7f8ef60aa484]
\n[frame 3]: /opt/conda/lib/python3.7/site-packages/nvidia/dali/libdali.so(dali::ThreadPool::ThreadMain(int, int, bool, std::string const&)+0x1e6) [0x7f8f23325896]
\n[frame 4]: /opt/conda/lib/python3.7/site-packages/nvidia/dali/libdali.so(+0x691150) [0x7f8f23824150]
\n[frame 5]: /lib/x86_64-linux-gnu/libpthread.so.0(+0x8609) [0x7f8f6a4fa609]
\n[frame 6]: /lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7f8f6a2b9133]
Current pipeline object is no longer valid.
", "rawMarkdown": "hi , i get this error when use notebook ;\ncan help me?\n\nRuntimeError: Critical error in pipeline:\nError when executing Mixed operator experimental__decoders__Image encountered:\nError in thread 0: [/opt/dali/dali/imgcodec/image_decoder.cc:448] Cannot parse the image: \nStacktrace (7 entries):\n[frame 0]: /opt/conda/lib/python3.7/site-packages/nvidia/dali/libdali_imgcodec.so(+0x94bcb) [0x7f8ef22d6bcb]\n[frame 1]: /opt/conda/lib/python3.7/site-packages/nvidia/dali/libdali_imgcodec.so(+0x6bb18) [0x7f8ef22adb18]\n[frame 2]: /opt/conda/lib/python3.7/site-packages/nvidia/dali/libdali_operators.so(+0x26ce484) [0x7f8ef60aa484]\n[frame 3]: /opt/conda/lib/python3.7/site-packages/nvidia/dali/libdali.so(dali::ThreadPool::ThreadMain(int, int, bool, std::string const&)+0x1e6) [0x7f8f23325896]\n[frame 4]: /opt/conda/lib/python3.7/site-packages/nvidia/dali/libdali.so(+0x691150) [0x7f8f23824150]\n[frame 5]: /lib/x86_64-linux-gnu/libpthread.so.0(+0x8609) [0x7f8f6a4fa609]\n[frame 6]: /lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7f8f6a2b9133]\n\nCurrent pipeline object is no longer valid." }, { "id": 2062299, "postDate": "2022-12-12T01:19:52.183Z", "content": "Some background on .70
\nhttps://crnl.readthedocs.io/jpeg_formats/index.html
\nCompressed lossless JPEG
\n\n", "rawMarkdown": "Some background on .70\n\nhttps://crnl.readthedocs.io/jpeg_formats/index.html\n\nCompressed lossless JPEG\n> Common in DICOM. Transfer syntaxes 1.2.840.10008.1.2.4.57 and 1.2.840.10008.1.2.4.70 refer to a lossless JPEG format that is exceptionally rare outside of the medical domain (and completely different from both the lossless JPEG-LS and lossless JPEG-2000 encoding formats). While this was fully described in the JPEG ISO/IEC 10918-1:1994 T.81 (09/92), it did not gain traction outside of medical imaging (where GIF and PNG became the most popular lossless formats). This legacy lossless JPEG is a simple format, and only uses the Huffman encoding without the typical discrete cosine transforms (DCT). However, the fact that these images are typically saved with 16-bit precision means it is not supported by most libraries, and they generate an error saying they can not decode “SOF type 0xc3”. I have written my own library to support this format, though other tools (e.g. dcmtk) use custom-patched variations of the IJG library. This is not a very efficient compression method, and personally I would strongly recommend users investigate file-based compression (.zip, or disk driver enabled compression) over this arcane format. This is the default output of dcmcjpeg, probably explaining its widespread popularity, for example the command “./dcmcjpeg in.dcm out.dcm” generates a DICOM image with format 1.2.840.10008.1.2.4.70, while the command “./dcmcjpeg +el in.dcm out.dcm” generates an image with syntax 1.2.840.10008.1.2.4.57. You can also create these files withgdcmconv (e.g. ‘gdcmconv -J in.dcm out.dcm’).\n", "replies": [ { "id": 2062324, "postDate": "2022-12-12T02:06:55.160Z", "content": "Common in DICOM. Transfer syntaxes 1.2.840.10008.1.2.4.57 and 1.2.840.10008.1.2.4.70 refer to a lossless JPEG format that is exceptionally rare outside of the medical domain (and completely different from both the lossless JPEG-LS and lossless JPEG-2000 encoding formats). While this was fully described in the JPEG ISO/IEC 10918-1:1994 T.81 (09/92), it did not gain traction outside of medical imaging (where GIF and PNG became the most popular lossless formats). This legacy lossless JPEG is a simple format, and only uses the Huffman encoding without the typical discrete cosine transforms (DCT). However, the fact that these images are typically saved with 16-bit precision means it is not supported by most libraries, and they generate an error saying they can not decode “SOF type 0xc3”. I have written my own library to support this format, though other tools (e.g. dcmtk) use custom-patched variations of the IJG library. This is not a very efficient compression method, and personally I would strongly recommend users investigate file-based compression (.zip, or disk driver enabled compression) over this arcane format. This is the default output of dcmcjpeg, probably explaining its widespread popularity, for example the command “./dcmcjpeg in.dcm out.dcm” generates a DICOM image with format 1.2.840.10008.1.2.4.70, while the command “./dcmcjpeg +el in.dcm out.dcm” generates an image with syntax 1.2.840.10008.1.2.4.57. You can also create these files withgdcmconv (e.g. ‘gdcmconv -J in.dcm out.dcm’).
\n
Thanks for sharing. I'm working with dcmcjpeg right now to generate .70 format images and compare them to the compressed jpeg-ls images, the difference should yield insights on how to hack the bytesio.
", "rawMarkdown": "Thanks for sharing. I'm working with dcmcjpeg right now to generate .70 format images and compare them to the compressed jpeg-ls images, the difference should yield insights on how to hack the bytesio." }, { "id": 2063456, "postDate": "2022-12-13T00:06:03.773Z", "content": "How does pydicom / gdcm extract the image for gdcm to decode it?
\nhttps://github.com/pydicom/pydicom/blob/master/pydicom/pixel_data_handlers/gdcm_handler.py
\nSUPPORTED_TRANSFER_SYNTAXES = [\n pydicom.uid.JPEGBaseline8Bit,\n pydicom.uid.JPEGExtended12Bit,\n pydicom.uid.JPEGLosslessP14,\n pydicom.uid.JPEGLosslessSV1,\n\n\nJPEGLosslessSV1 = UID() \n\n \n \n new = ds.group_dataset()\n new[] = ds[] \n new.file_meta = ds.file_meta\n NamedTemporaryFile(, delete=) t:\n new.save_as(t)\nI guess gdcm does some stuff
", "rawMarkdown": "How does pydicom / gdcm extract the image for gdcm to decode it?\n\n\nhttps://github.com/pydicom/pydicom/blob/master/pydicom/pixel_data_handlers/gdcm_handler.py\n\n```python\nSUPPORTED_TRANSFER_SYNTAXES = [\n pydicom.uid.JPEGBaseline8Bit,\n pydicom.uid.JPEGExtended12Bit,\n pydicom.uid.JPEGLosslessP14,\n pydicom.uid.JPEGLosslessSV1,\n\n\nJPEGLosslessSV1 = UID(\"1.2.840.10008.1.2.4.70\") # Old JPEGLossless\n```\n\n\n```python\n# Copy the relevant elements and write to a temporary file to avoid\n # having to deal with all the possible objects the dataset may\n # originate with\n new = ds.group_dataset(0x0028)\n new[\"PixelData\"] = ds[\"PixelData\"] # avoid ambiguous VR\n new.file_meta = ds.file_meta\n with NamedTemporaryFile('wb', delete=False) as t:\n new.save_as(t)\n```\n\nI guess gdcm does some stuff" } ] }, { "id": 2061096, "postDate": "2022-12-10T17:26:22.970Z", "content": "Nice! Great notebook and solution to learn new things. Looking inside notebook - thanks for contributing.
", "rawMarkdown": "Nice! Great notebook and solution to learn new things. Looking inside notebook - thanks for contributing." }, { "id": 2062285, "postDate": "2022-12-12T00:08:35.660Z", "rawMarkdown": "", "isDeleted": true } ], "comments": [ { "id": 2063328, "author_name": "David Austin", "author_url": "", "post_date": "2022-12-12T20:06:12.180000", "content": "Update: The byte string to properly extract lossless jpg images can be done using this offset with the same code as before.
\n\noffset = ds.PixelData.find(b\"\\xff\\xd8\\xff\\xe0\")\n
\nHowever, decode of lossless jpg is not currenly supported by nvjpeg on gpu. For now the best known solution is to combine dali on jpeg2k images with dicomsdl for lossless jpg. @hengck23 just posted a notebook here that combines the two methods beautifully.
The question isn't pydicom versus dicomsdl versus dali, but rather nvjpeg versus gdcm versus libjpeg-turbo versus..
", "votes": 0, "replies": [] } ] }, { "id": 2064128, "author_name": "hengck23", "author_url": "", "post_date": "2022-12-13T14:36:45.360000", "content": "
\ni make a mistake. i should be using nvJPEG2K instead
i think your pipeline can be simplified as:
\n#https://github.com/UsingNet/nvjpeg-python\nfrom nvjpeg import NvJpeg\nnj = NvJpeg()\n.....\n\n\n\n dicom = pydicom.dcmread(f)\n if dicom.file_meta.TransferSyntaxUID != '1.2.840.10008.1.2.4.90':\n raise NotImplementedError\n\n byte_stream = dicom.PixelData\n offset = byte_stream.find(b\"\\x00\\x00\\x00\\x0C\")\n jpeg_stream = np.asarray(bytearray(byte_stream[offset:]), dtype='uint8')\n\n #failed because out of memory ...\n m1 = nj.decode(jpeg_stream) \n\n #this works! meaning that i have get the correct jpeg byte string\n m0 = cv2.imdecode(jpeg_stream, cv2.IMREAD_ANYDEPTH)\n print(m0.shape)\n plt.imshow(m0)\nInteresting. Does this actually work? If so, it'd be great to benchmark it. Augmenting off GPU would be better I think. You're going to be quite constrained with the GPU if you're limited to dali augmentation.
", "votes": 0, "replies": [] }, { "id": 2061312, "author_name": "hengck23", "author_url": "", "post_date": "2022-12-11T01:16:06.217000", "content": "
\n
i make a mistake. i should be using nvJPEG2K instead
", "votes": 0, "replies": [] }, { "id": 2061313, "author_name": "hengck23", "author_url": "", "post_date": "2022-12-11T01:17:04.137000", "content": "Dali also uses nvjpeg, nvjpeg2k
", "votes": 0, "replies": [] }, { "id": 2061318, "author_name": "hengck23", "author_url": "", "post_date": "2022-12-11T01:26:48.660000", "content": "\n\n
\n
i make a mistake. i should be using nvJPEG2K instead
\nhttps://docs.nvidia.com/cuda/nvjpeg2000/userguide.html
\nJPEG2000 Options:
\n Up to 16 bits per component
\n(nvjpeg is 8bits per component)
Someone should let them know, lol
", "votes": 0, "replies": [] }, { "id": 2061359, "author_name": "David Austin", "author_url": "", "post_date": "2022-12-11T03:51:08.073000", "content": "Dali nightly whl supports 16bit, it uses nvjpeg2k under the hood
", "votes": 0, "replies": [] } ] }, { "id": 2062485, "author_name": "hengck23", "author_url": "", "post_date": "2022-12-12T06:37:08.850000", "content": "to quickly identidy the type of jpeg encoding, one can use machine id:
\ntrain_df[['machine_id','TransferSyntaxUID','image_id']].groupby(['machine_id','TransferSyntaxUID']).count()\nOut[7]: \n image_id\nmachine_id TransferSyntaxUID \n21 1.2.840.10008.1.2.4.90 8221\n29 1.2.840.10008.1.2.4.90 8267\n48 1.2.840.10008.1.2.4.90 8699\n49 1.2.840.10008.1.2.4.70 23529\n93 1.2.840.10008.1.2.4.70 1915\n170 1.2.840.10008.1.2.4.70 923\n190 1.2.840.10008.1.2.4.70 145\n197 1.2.840.10008.1.2.4.70 29\n210 1.2.840.10008.1.2.4.70 1070\n216 1.2.840.10008.1.2.4.70 1908\nOr just site id :) Site_id 1 is .70, site_id 2 is .90 .. Need to check if it's the same on the leaderboard
", "votes": 1, "replies": [] }, { "id": 2062834, "author_name": "David Austin", "author_url": "", "post_date": "2022-12-12T13:17:56.317000", "content": "It makes sense that the dicom format produced would be consistent by machine_id
", "votes": 0, "replies": [] } ] }, { "id": 2061226, "author_name": "Sandy", "author_url": "", "post_date": "2022-12-10T21:04:13.317000", "content": "Wow. This is something great to know. Kudos.
", "votes": 1, "replies": [] }, { "id": 2143523, "author_name": "junseonglee11", "author_url": "", "post_date": "2023-02-14T10:13:54.887000", "content": "Wow! very fast decoding. It must be really useful
", "votes": 0, "replies": [] }, { "id": 2139878, "author_name": "Fatemeh Shahsavari", "author_url": "", "post_date": "2023-02-11T08:53:52.587000", "content": "hi , i get this error when use notebook ;
\ncan help me?
RuntimeError: Critical error in pipeline:
\nError when executing Mixed operator experimental__decoders__Image encountered:
\nError in thread 0: [/opt/dali/dali/imgcodec/image_decoder.cc:448] Cannot parse the image:
\nStacktrace (7 entries):
\n[frame 0]: /opt/conda/lib/python3.7/site-packages/nvidia/dali/libdali_imgcodec.so(+0x94bcb) [0x7f8ef22d6bcb]
\n[frame 1]: /opt/conda/lib/python3.7/site-packages/nvidia/dali/libdali_imgcodec.so(+0x6bb18) [0x7f8ef22adb18]
\n[frame 2]: /opt/conda/lib/python3.7/site-packages/nvidia/dali/libdali_operators.so(+0x26ce484) [0x7f8ef60aa484]
\n[frame 3]: /opt/conda/lib/python3.7/site-packages/nvidia/dali/libdali.so(dali::ThreadPool::ThreadMain(int, int, bool, std::string const&)+0x1e6) [0x7f8f23325896]
\n[frame 4]: /opt/conda/lib/python3.7/site-packages/nvidia/dali/libdali.so(+0x691150) [0x7f8f23824150]
\n[frame 5]: /lib/x86_64-linux-gnu/libpthread.so.0(+0x8609) [0x7f8f6a4fa609]
\n[frame 6]: /lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7f8f6a2b9133]
Current pipeline object is no longer valid.
", "votes": 0, "replies": [] }, { "id": 2062299, "author_name": "@kaggleqrdl", "author_url": "", "post_date": "2022-12-12T01:19:52.183000", "content": "Some background on .70
\nhttps://crnl.readthedocs.io/jpeg_formats/index.html
\nCompressed lossless JPEG
\n\n", "votes": 0, "replies": [ { "id": 2062324, "author_name": "David Austin", "author_url": "", "post_date": "2022-12-12T02:06:55.160000", "content": "Common in DICOM. Transfer syntaxes 1.2.840.10008.1.2.4.57 and 1.2.840.10008.1.2.4.70 refer to a lossless JPEG format that is exceptionally rare outside of the medical domain (and completely different from both the lossless JPEG-LS and lossless JPEG-2000 encoding formats). While this was fully described in the JPEG ISO/IEC 10918-1:1994 T.81 (09/92), it did not gain traction outside of medical imaging (where GIF and PNG became the most popular lossless formats). This legacy lossless JPEG is a simple format, and only uses the Huffman encoding without the typical discrete cosine transforms (DCT). However, the fact that these images are typically saved with 16-bit precision means it is not supported by most libraries, and they generate an error saying they can not decode “SOF type 0xc3”. I have written my own library to support this format, though other tools (e.g. dcmtk) use custom-patched variations of the IJG library. This is not a very efficient compression method, and personally I would strongly recommend users investigate file-based compression (.zip, or disk driver enabled compression) over this arcane format. This is the default output of dcmcjpeg, probably explaining its widespread popularity, for example the command “./dcmcjpeg in.dcm out.dcm” generates a DICOM image with format 1.2.840.10008.1.2.4.70, while the command “./dcmcjpeg +el in.dcm out.dcm” generates an image with syntax 1.2.840.10008.1.2.4.57. You can also create these files withgdcmconv (e.g. ‘gdcmconv -J in.dcm out.dcm’).
\n
Thanks for sharing. I'm working with dcmcjpeg right now to generate .70 format images and compare them to the compressed jpeg-ls images, the difference should yield insights on how to hack the bytesio.
", "votes": 0, "replies": [] }, { "id": 2063456, "author_name": "@kaggleqrdl", "author_url": "", "post_date": "2022-12-13T00:06:03.773000", "content": "How does pydicom / gdcm extract the image for gdcm to decode it?
\nhttps://github.com/pydicom/pydicom/blob/master/pydicom/pixel_data_handlers/gdcm_handler.py
\nSUPPORTED_TRANSFER_SYNTAXES = [\n pydicom.uid.JPEGBaseline8Bit,\n pydicom.uid.JPEGExtended12Bit,\n pydicom.uid.JPEGLosslessP14,\n pydicom.uid.JPEGLosslessSV1,\n\n\nJPEGLosslessSV1 = UID() \n\n \n \n new = ds.group_dataset()\n new[] = ds[] \n new.file_meta = ds.file_meta\n NamedTemporaryFile(, delete=) t:\n new.save_as(t)\nI guess gdcm does some stuff
", "votes": 0, "replies": [] } ] }, { "id": 2061096, "author_name": "Remek Kinas", "author_url": "", "post_date": "2022-12-10T17:26:22.970000", "content": "Nice! Great notebook and solution to learn new things. Looking inside notebook - thanks for contributing.
", "votes": 0, "replies": [] }, { "id": 2062285, "author_name": "", "author_url": "", "post_date": "2022-12-12T00:08:35.660000", "content": "", "votes": 0, "replies": [] } ], "raw_markdown_by_id": { "2061084": "**TLDR:**\nApprox half the dicoms in the dataset contain jpeg2000 encoded images. There's a way to hack the bitstream and extract/save the jp2 images which can then be decoded on GPU using [Nvidia DALI](https://docs.nvidia.com/deeplearning/dali/user-guide/docs/index.html).\n\npydicom decode per image (parallel mode): **0.88** imgs/sec (32 imgs/36 sec)\nDALI decode per image: **15.16** imgs/sec (32 imgs/2.03s)\nSpeedup: **17.7x**\n\nCheck out the [notebook](https://www.kaggle.com/code/tivfrvqhs5/decode-jpeg2000-dicom-with-dali?scriptVersionId=113466193) here which contains the minimal decode example. Still working on a way to extract the lossless jpeg bitstream for the other half of dicoms which will then make this technique much more useful in an end-to-end solution.\n\nA little more:\nWhile DALI doesn't support decoding dicom's directly, it does support jpeg2000 decode. So the trick is extracting the jpeg2000 bitstream from the dicom container so DALI can ingest it.\n\nI'm still working on figuring out an analogous hack for the lossless jpeg format. Any inputs welcome.\n\n\n\n\n\n", "2063328": "Update: The byte string to properly extract lossless jpg images can be done using this offset with the same code as before.\n\n`\noffset = ds.PixelData.find(b\"\\xff\\xd8\\xff\\xe0\")\n`\nHowever, decode of lossless jpg is not currenly supported by nvjpeg on gpu. For now the best known solution is to combine dali on jpeg2k images with dicomsdl for lossless jpg. @hengck23 just posted a notebook [here](https://www.kaggle.com/code/hengck23/combine-dali-and-dicomsdl-for-reading-dicom-files) that combines the two methods beautifully.", "2064128": "", "2061228": "~~i have been trying to use nvjpeg directly, but failed.~~ \ni make a mistake. i should be using nvJPEG2K instead\n\ni think your pipeline can be simplified as:\n\n```\n#https://github.com/UsingNet/nvjpeg-python\nfrom nvjpeg import NvJpeg\nnj = NvJpeg()\n.....\n\n\n\n dicom = pydicom.dcmread(f)\n if dicom.file_meta.TransferSyntaxUID != '1.2.840.10008.1.2.4.90':\n raise NotImplementedError\n\n byte_stream = dicom.PixelData\n offset = byte_stream.find(b\"\\x00\\x00\\x00\\x0C\")\n jpeg_stream = np.asarray(bytearray(byte_stream[offset:]), dtype='uint8')\n\n #failed because out of memory ...\n m1 = nj.decode(jpeg_stream) \n\n #this works! meaning that i have get the correct jpeg byte string\n m0 = cv2.imdecode(jpeg_stream, cv2.IMREAD_ANYDEPTH)\n print(m0.shape)\n plt.imshow(m0)\n\n\n```\n\n\n", "2062485": "to quickly identidy the type of jpeg encoding, one can use machine id:\n\n```\ntrain_df[['machine_id','TransferSyntaxUID','image_id']].groupby(['machine_id','TransferSyntaxUID']).count()\nOut[7]: \n image_id\nmachine_id TransferSyntaxUID \n21 1.2.840.10008.1.2.4.90 8221\n29 1.2.840.10008.1.2.4.90 8267\n48 1.2.840.10008.1.2.4.90 8699\n49 1.2.840.10008.1.2.4.70 23529\n93 1.2.840.10008.1.2.4.70 1915\n170 1.2.840.10008.1.2.4.70 923\n190 1.2.840.10008.1.2.4.70 145\n197 1.2.840.10008.1.2.4.70 29\n210 1.2.840.10008.1.2.4.70 1070\n216 1.2.840.10008.1.2.4.70 1908\n\n\n```", "2061226": "Wow. This is something great to know. Kudos.", "2143523": "Wow! very fast decoding. It must be really useful\n", "2139878": "hi , i get this error when use notebook ;\ncan help me?\n\nRuntimeError: Critical error in pipeline:\nError when executing Mixed operator experimental__decoders__Image encountered:\nError in thread 0: [/opt/dali/dali/imgcodec/image_decoder.cc:448] Cannot parse the image: \nStacktrace (7 entries):\n[frame 0]: /opt/conda/lib/python3.7/site-packages/nvidia/dali/libdali_imgcodec.so(+0x94bcb) [0x7f8ef22d6bcb]\n[frame 1]: /opt/conda/lib/python3.7/site-packages/nvidia/dali/libdali_imgcodec.so(+0x6bb18) [0x7f8ef22adb18]\n[frame 2]: /opt/conda/lib/python3.7/site-packages/nvidia/dali/libdali_operators.so(+0x26ce484) [0x7f8ef60aa484]\n[frame 3]: /opt/conda/lib/python3.7/site-packages/nvidia/dali/libdali.so(dali::ThreadPool::ThreadMain(int, int, bool, std::string const&)+0x1e6) [0x7f8f23325896]\n[frame 4]: /opt/conda/lib/python3.7/site-packages/nvidia/dali/libdali.so(+0x691150) [0x7f8f23824150]\n[frame 5]: /lib/x86_64-linux-gnu/libpthread.so.0(+0x8609) [0x7f8f6a4fa609]\n[frame 6]: /lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7f8f6a2b9133]\n\nCurrent pipeline object is no longer valid.", "2062299": "Some background on .70\n\nhttps://crnl.readthedocs.io/jpeg_formats/index.html\n\nCompressed lossless JPEG\n> Common in DICOM. Transfer syntaxes 1.2.840.10008.1.2.4.57 and 1.2.840.10008.1.2.4.70 refer to a lossless JPEG format that is exceptionally rare outside of the medical domain (and completely different from both the lossless JPEG-LS and lossless JPEG-2000 encoding formats). While this was fully described in the JPEG ISO/IEC 10918-1:1994 T.81 (09/92), it did not gain traction outside of medical imaging (where GIF and PNG became the most popular lossless formats). This legacy lossless JPEG is a simple format, and only uses the Huffman encoding without the typical discrete cosine transforms (DCT). However, the fact that these images are typically saved with 16-bit precision means it is not supported by most libraries, and they generate an error saying they can not decode “SOF type 0xc3”. I have written my own library to support this format, though other tools (e.g. dcmtk) use custom-patched variations of the IJG library. This is not a very efficient compression method, and personally I would strongly recommend users investigate file-based compression (.zip, or disk driver enabled compression) over this arcane format. This is the default output of dcmcjpeg, probably explaining its widespread popularity, for example the command “./dcmcjpeg in.dcm out.dcm” generates a DICOM image with format 1.2.840.10008.1.2.4.70, while the command “./dcmcjpeg +el in.dcm out.dcm” generates an image with syntax 1.2.840.10008.1.2.4.57. You can also create these files withgdcmconv (e.g. ‘gdcmconv -J in.dcm out.dcm’).\n", "2061096": "Nice! Great notebook and solution to learn new things. Looking inside notebook - thanks for contributing.", "2062285": "" } }