Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Nov 26 12:44
    Enet4 labeled #204
  • Nov 26 12:44
    Enet4 labeled #204
  • Nov 26 12:44
    Enet4 labeled #204
  • Nov 26 12:44
    Enet4 opened #204
  • Nov 23 17:30
    Enet4 synchronize #202
  • Nov 23 17:30

    Enet4 on snafu-v0.7

    [pixeldata] migrate gdcm module… (compare)

  • Nov 19 18:10
    charbeljc commented #174
  • Nov 18 21:45

    Enet4 on v0.5.0-rc.1

    (compare)

  • Nov 18 21:44

    Enet4 on master

    [pixeldata] update Cargo manife… (compare)

  • Nov 18 21:03

    Enet4 on master

    Bump crate versions in workspac… (compare)

  • Nov 18 21:01
    Enet4 converted_to_draft #174
  • Nov 18 19:24
    Enet4 labeled #203
  • Nov 18 19:24
    Enet4 opened #203
  • Nov 18 19:18

    Enet4 on toimage

    New crate dicom-toimage - base… (compare)

  • Nov 16 19:05
    Enet4 opened #202
  • Nov 16 19:05
    Enet4 labeled #202
  • Nov 16 19:05
    Enet4 labeled #202
  • Nov 16 19:03

    Enet4 on snafu-v0.7

    Bump snafu to 0.7.0-beta.2 Migrate all codebase to snafu 0… (compare)

  • Nov 16 15:47
    Enet4 edited #181
  • Nov 16 15:46
    Enet4 edited #189
Paul Knopf
@pauldotknopf
Is there a way to convert a InMemDicomObject to a byte array?
Paul Knopf
@pauldotknopf
How do we want to handle padding chars? I'm currently seeing odd string values with VR::UI have a trailing "NULL" char. I feel like this should be an implementation detail, hidden from the API surface entirely.
Christopher Speck
@neandrake

From http://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_6.2.html,

A character string containing a UID that is used to uniquely identify a wide variety of items. The UID is a series of numeric components separated by the period "." character. If a Value Field containing one or more UIDs is an odd number of bytes in length, the Value Field shall be padded with a single trailing NULL (00H) character to ensure that the Value Field is an even number of bytes in length.

When parsing the value of a UI as a String the null character should be removed from the end if the length is even, as the null character was added to enforce an even length
Certain character-sequence VRs can also be padded with spaces at the end of the value which the VR will indicate if it's considered significant or not.
Christopher Speck
@neandrake
Here's the current code I'm using for parsing a string value. It's incomplete and I've been working on adding tests to handle some other odd cases I've run into. https://gist.github.com/neandrake/dc402dbd2e6b4e24fa6bf2cf9f2383c0
Paul Knopf
@pauldotknopf
@neandrake, what is that code a part of? dicom-rs? Are you working on another implementation?
Christopher Speck
@neandrake
That's from my codebase. I've been working off-and-on over the past few years putting together a DICOM library in rust
Christopher Speck
@neandrake
I've watched this repo to keep tabs on how things are progressing. I've looked through the code a little but it looks to use much more idiomatic rust than I'm familiar with (I only have one generic type and just the other day added the first trait).
Ilya Baryshnikov
@ibaryshnikov
Hi all! Thanks for building such an awesome crate!
Eduardo Pinho
@Enet4
Oh, hello there! I'm sorry, I haven't been paying attention to chat. Thank you all for your participation so far! :+1:
Eduardo Pinho
@Enet4
To answer some of the concerns exposed here: writing objects into a byte array or any other target is indeed a matter for #15. It should definitely be worked on soon.
Whether the implementation should remove trailing spaces is a good concern. We might not benefit that much from this level of transparency. Regardless of how we treat these strings, working on lazy objects and string-preserving values seems like a step in the right direction so far.
Eduardo Pinho
@Enet4
This is an ambitious project, one which I have tried to push forward for quite a while. For a long time I fell into the trap of excessive refactoring, but at least this came with the benefit of ending up with a more mature code base in the end. One that will hopefully be more pleasing to work with in future years.
I also chose not to squat the crate names on crates.io until I had something substantial to show. I take a perspective of responsibility when using crate names in the registry to make something useful out of them, and not just like they're free real estate. Gladly, I was still able to take the names three years after the beginning of the project.
Ilya Baryshnikov
@ibaryshnikov
@Enet4 you have been working on this crate for three years?! That's massive! Thanks for sharing your work! As I use it for free, I still feel a need to give something back, sandly the best I can do at the moment is testing, due to lack of knowledge about DICOM standard...
Eduardo Pinho
@Enet4
Oops, I forgot this chatroom existed again. I should probably set up notifications on my phone.
@ibaryshnikov So far, I can only thank you for appreciating this work and for the contributions made so far. This has been quite a ride, and there's so much more to fulfil in this project.
Daryl.Xu
@ziqiangxu
image.png
Hello, why some dcm files have no pixel data?
Pavel Zaytsev
@iberisoft

Hello, why some dcm files have no pixel data?

It's simple: a file might be encapsulated PDF, structured report, presentation context... there are many DICOM files designed for storing something else than pixels.

Pavel Zaytsev
@iberisoft
Good evening @Enet4! Please explain how to switch from ValueReadStrategy::Preserved to ValueReadStrategy::Interpreted option. My issue is following: I get a DICOM element of DS type however the element holds PrimitiveValue::Strs instead of PrimitiveValue::F64 because of using decode::read_value_preserved rather than decode::read_value.
Eduardo Pinho
@Enet4
Hello, @iberisoft! Sorry about not paying attention to Gitter, this is usually a low traffic channel and apparently I'm still not receiving notifications.
I have replied to those concerns in the issue that you created. The rule of thumb is to prefer to_{type} methods, and only the others when you are sure that no conversion is ever needed.
AUGERClement
@AUGERClement

Hello everyone.

I am working with pynetDICOM since a few months ago, but I want to do more in rust and less python. Do you know how long it will take before adding Network features ?

I'm really enjoying this crate, and the ability to send C-FIND or C-MOVE could transform my multiples python projects into rust ones. I am not very experienced with rust, but I hope the best ffor you

Eduardo Pinho
@Enet4
@AUGERClement Hello there! The project provides some level of network capabilities already, through the dicom-ul crate. Currently, this requires implementers to follow the intended protocol after an association is made. Some proof of concept network utilities are also done, and a proof of concept for a Move SCU is in the works too (#108). In the future, it definitely makes sense for the project to incorporate higher level programmatic interfaces for SCUs and SCPs.
Troels Arvin
@troelsarvin
When I have used dicom::object::open_file(somepath).unwrap() to get myself a DefaultDicomObject from a file: Do I have to call some close-function when I'm done with the file? (I'm going to iterate through a large bunch of files, and I don't want to build up problem with lots of open file handles.)
Eduardo Pinho
@Enet4
@troelsarvin Hello! The current implementation of open_file will fetch the file into a representation fully in memory, so the file descriptor is released right afterwards.
In the future, with lazily loaded DICOM objects, file descriptors are dropped once the object itself is dropped or converted to another type of object.
Troels Arvin
@troelsarvin
I'm getting "Could not read data set token" when working with a subset of DICOM files. I need to grab study instance UID and SOP instance UID from them. When I use command line tools from dcmtk and from dcm4che, I can get the two types of UIs from such files. Is the "Could not read data set token" state recoverable in dicom-rs, so that I can grab the SIUID and SOP instance UID from the files, even though dicom-rs may not find the DICOM file perfectly well formed?
(Unfortunately, I cannot share the files, because they contain patient data; and I think that If I try to anonymize them, then the tag structure will probably be useless for debugging, because dcmodify (or alike) would have rewritten the tag data in the file.)
Eduardo Pinho
@Enet4
@troelsarvin I would love to look into that, but it is going to be hard without an example. Is the file by chance in deflated explicit VR little endian?
The error should also include a source error which can be reported by traversing the source chain (there is an example in dcmdump), and backtrackes are supported by setting the environment variable RUST_BACKTRACE.
Troels Arvin
@troelsarvin
It has "(0002,0010) UI =LittleEndianImplicit # 18, 1 TransferSyntaxUID". WineFile can open it as well, by the way. dcmdk does have a warning when opening the file, however: "W: Found element (2001,9000) with VR UN and undefined length, reading a sequence with transfer syntax LittleEndianImplicit (CP-246)".
Troels Arvin
@troelsarvin
dcmodify would fix the problem, but I managed to anonymize using a hexteditor, and the following anonymized file can be used to reproduce the issue: https://troels.arvin.dk/rust/dicom/Premature_data_set_end-anon.dcm
Troels Arvin
@troelsarvin
I chose to submit Enet4/dicom-rs#167 about the issue previously mentioned.
Eduardo Pinho
@Enet4
Much appreciated @troelsarvin.
Troels Arvin
@troelsarvin
I've been trying to use the Github version of dicom-rs using the a [patch] section of Cargo.toml. But now my code will not compile any more:
let siuid= obj.element(tags::STUDY_INSTANCE_UID).unwrap().to_clean_str().unwrap().to_string(); ^^^^^^^^^^^^^^^^^^^^^^^^ expected struct dicom::dicom_object::Tag, found struct dicom::dicom_core::Tag
Will there be a new dicom-rs version soon?
Troels Arvin
@troelsarvin
(I figured out how to use Cargo's patch system.)

There is another file which dicom-rs will not open, but which can be opened by both dcmtk, dcm4che and others (without warnings). Unfortunately, I cannot anonymize that file, because it has PIH burned into the pixel data. But I've run dicom-rs' dcmdump on it with RUST_BACKTRACE=1, and I get:

[ERROR] Could not read data set token

Caused by:
   0: Inconsistent sequence end: expected end at 2066 bytes but read 2296

It's a LittleEndianExplicit CT DICOM file. dcmtk and dcm4che don't even write a warning when working with the file. Is there a place in the dicom-rs code I should try to experiment with, in order to make dicom-rs robust with regards to this?

Eduardo Pinho
@Enet4
@troelsarvin That error is raised by the data set reader. One possible way to diagnose this is to use it directly on a file (after skipping the file specific header) and print out the tokens it produces until it reaches the error.
Troels Arvin
@troelsarvin
Enet4/dicom-rs#169 was raised due to this.
Troels Arvin
@troelsarvin
(Case 169 was about a different DICOM file than the one about "0: Inconsistent sequence end: expected end at 2066 bytes but read 2296".)
Troels Arvin
@troelsarvin

When trying to build a fresh clone of dicom-rs:

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

Caused by:
  process didn't exit successfully: `/home/user/git-clones/dicom-rs/target/debug/build/gdcm-rs-728410fd463b6696/build-script-build` (exit status: 101)
  --- stdout
  cargo:rerun-if-changed=build.rs
  cargo:rerun-if-changed=gdcm_wrapper.cc
  cargo:rerun-if-changed=wrapper.h
  running: "cmake" "/home/user/.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/user/git-clones/dicom-rs/target/debug/build/gdcm-rs-47c2b10697b77ec5/out" "-DCMAKE_C_FLAGS= -fPIC -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_C_COMPILER=/usr/bin/cc" "-DCMAKE_CXX_FLAGS= -std=c++11 -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_CXX_COMPILER=c++" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_ASM_COMPILER=/usr/bin/cc" "-DCMAKE_BUILD_TYPE=Debug"

  --- stderr
  fatal: Not a git repository (or any of the parent directories): .git
  thread 'main' panicked at '
  failed to execute command: No such file or directory (os error 2)
  is `cmake` not installed?

  build script failed, must exit now', /home/user/.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

Is that expected?

Eduardo Pinho
@Enet4
@troelsarvin The current HEAD requires CMake because it depends on gdcm to extend the features of the upcoming pixel data crate. Disabling the feature makes it build pure Rust again. I agree that it's a bit inconvenient, might change it in the near future.
Troels Arvin
@troelsarvin
If I install cmake, things still fail. This time because RHEL 7's cmake is too old :-(
  CMake 3.9.2 or higher is required.  You are running version 2.8.12.2
How does one disable the feature?
Eduardo Pinho
@Enet4
A bit of a mouthful right now: cargo build --no-default-features --features=inventory-registry,ul,backtraces
jdmichaud
@jdmichaud
Hello. What kind of test dicom-rs has? Do you have a database of DICOM file to test the conformance of the library?
Eduardo Pinho
@Enet4
@jdmichaud Hello there! A data oriented test harness is planned, and a small part of the existing integration tests are based on DICOM test files. https://github.com/Enet4/dicom-rs/wiki/Roadmap#data-oriented-test-harness Other than that, each library crate has its own test suite, unit tests for the most part.