How to retrieve pixel data

[TimOrme]

Apologies for the likely naive question, but is there a way to retrieve the PixelData from a DICOM, such that it could be opened with the image crate or something similar?

Thanks!

[Enet4]

Thank you for your interest! That is a planned feature. #31 (See also the roadmap) I hope to get around it within the next few months, it is up on my priority list along with lazy loading capabilities.

For the time being, one would need to fetch the image related data elements from the object and construct the multidimensional array manually.

[Enet4]

It is now possible to retrieve the pixel data as an ndarray or an image value via the API in the pixeldata crate. You may keep track of development around this crate in #125.

[desprit]

@Enet4

Hi, do you have any suggestion on how to add dicom-pixeldata to my project? It's not on the crates.io yet, I tried to add it as a git dependency:

dicom-pixel-data = {git = "https://github.com/pevers/dicom-pixel-data.git", branch = "main" }

but couldn't build it like that.

[pevers]

@Enet4

Hi, do you have any suggestion on how to add dicom-pixeldata to my project? It's not on the crates.io yet, I tried to add it as a git dependency:

dicom-pixel-data = {git = "https://github.com/pevers/dicom-pixel-data.git", branch = "main" }

but couldn't build it like that.

Hi @desprit , it is in the dicom-rs repo now in the main branch. So: git@github.com:Enet4/dicom-rs.git

[Enet4]

Sorry for the delay. Yes, according to the Cargo guide, this should work:

dicom-pixeldata = { git = "https://github.com/Enet4/dicom-rs" }

[desprit]

Thank you thank you, I will give it a try!

[desprit]

@Enet4

I was able to build with just cargo. But I'm using dicom-rs in a wasm project (using wasm-pack) and unfortunately it doesn't build:

error: failed to run custom build command for `gdcm-rs v0.2.0`

Caused by:
  process didn't exit successfully: `/home/projects/cornerstone-wasm/app/target/debug/build/gdcm-rs-c2e752327c55044d/build-script-build` (exit code: 101)
  --- stdout
  cargo:rerun-if-changed=build.rs
  cargo:rerun-if-changed=gdcm_wrapper.cc
  cargo:rerun-if-changed=wrapper.h
  running: "cmake" "/home/.cargo/registry/src/github.com-1ecc6299db9ec823/gdcm-rs-0.2.0/GDCM" "-DGDCM_BUILD_TESTING=OFF" "-DGDCM_DOCUMENTATION=OFF" "-DGDCM_BUILD_EXAMPLES=OFF" "-DGDCM_BUILD_DOCBOOK_MANPAGES=OFF" "-DCMAKE_INSTALL_PREFIX=/home/projects/cornerstone-wasm/app/target/wasm32-unknown-unknown/debug/build/gdcm-rs-b3d94a9a79e3f38c/out" "-DCMAKE_C_FLAGS= -fPIC -ffunction-sections -fdata-sections -fPIC --target=wasm32-unknown-unknown" "-DCMAKE_C_COMPILER=clang" "-DCMAKE_CXX_FLAGS= -std=c++11 -ffunction-sections -fdata-sections -fPIC --target=wasm32-unknown-unknown" "-DCMAKE_CXX_COMPILER=clang" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC --target=wasm32-unknown-unknown" "-DCMAKE_ASM_COMPILER=clang" "-DCMAKE_BUILD_TYPE=Debug"
  -- The CXX compiler identification is unknown
  -- The C compiler identification is unknown
  -- Configuring incomplete, errors occurred!
  See also "/home/projects/cornerstone-wasm/app/target/wasm32-unknown-unknown/debug/build/gdcm-rs-b3d94a9a79e3f38c/out/build/CMakeFiles/CMakeOutput.log".
  See also "/home/projects/cornerstone-wasm/app/target/wasm32-unknown-unknown/debug/build/gdcm-rs-b3d94a9a79e3f38c/out/build/CMakeFiles/CMakeError.log".

  --- stderr
  fatal: not a git repository (or any of the parent directories): .git
  CMake Error at CMakeLists.txt:19 (project):
    The CMAKE_CXX_COMPILER:

      clang

    is not a full path and was not found in the PATH.

    Tell CMake where to find the compiler by setting either the environment
    variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
    to the compiler, or to the compiler name if it is in the PATH.


  CMake Error at CMakeLists.txt:19 (project):
    The CMAKE_C_COMPILER:

      clang

    is not a full path and was not found in the PATH.

    Tell CMake where to find the compiler by setting either the environment
    variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
    the compiler, or to the compiler name if it is in the PATH.


  thread 'main' panicked at '
  command did not execute successfully, got: exit code: 1

  build script failed, must exit now', /home/.cargo/registry/src/github.com-1ecc6299db9ec823/cmake-0.1.45/src/lib.rs:894:5
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed
Error: Compiling your crate to WebAssembly failed
Caused by: failed to execute `cargo build`: exited with exit code: 101

Since it is only happening with wasm-pack I thought that maybe the issue is currently expected and the pixeldata plugin doesn't yet work with wasm?

p.s. to make it work with just cargo I installed cmake

[Enet4]

@desprit You are correct. Since the crate depends on native bindings in its current state, it cannot be used in a wasm environment (maybe possible but the process is very finicky). I have filed #121 which would allow users to build this part of the library without gdcm-rs, hopefully to be resolved before an actual release. A few other things may be necessary for the crate to build for WebAssembly, but this one should be the biggest obstacle.

[desprit]

@Enet4 I see... Thank you for the answer! Would be really good to have wasm-compatible version but I understand that the amount of work is likely quite huge. Our team is trying to integrate cornerstone frontend with dicom-rs as an image loader part. So far we were able to make it parse the dicom file and get some metadata out of it, the only thing missing is the actual pixeldata.

[Enet4]

Yes, I understand that working with pixel data is one of the long awaited features in DICOM-rs (so is lazy DICOM object loading, because this would make working with high-demand modalities feasible), and as such I am definitely interested in pushing progress on these fronts!

#121 should hopefully not be so complicated to resolve. At this stage, the plan is not to replace all image encodings supported by GDCM with Rust implementations, but to let users consume this API with a smaller subset of supported modalities, namely those which do not require that much conversion. Native MONOCHROME2 is already in, and MONOCHROME1 and RGB are highly desirable (#118 #119).