Comments (6)
Please use
to_multi_f64
instead.float64_slice
is a non-converting method, and would only work for FD-type or OD-type elements.
Thank you, it seems to work!
from dicom-rs.
Thank you for reaching out. Note that changing the parser reading strategy is not necessary for that use case. It only means that a conversion needs to take place after the parsing, which is the standard way of working with DICOM values at the moment. To treat a DS value as a floating point number:
// example
let val = DicomValue::new(dicom_value!(Strs, ["1300", "664 "]));
// converts strings automatically
let ww = val.to_float64()?;
// for multiple window levels, returns a vector
let ww = val.to_multi_float64()?;
The documentation on DicomValue
has the full list of methods available. The ones named string
, uint16
(and so on) only check their internal representation without conversion, whereas methods named to_*
will try to convert the internal data if necessary. Note also that retrieving a simple enum value describing the value's type can be done through the method value_type
.
Changing the value reading strategy requires creating the data set reader with the function DataSetReader.new_with_dictionary
, then passing it manually to InMemDicomObject.from_element_source
. This is not even sure to work well. The main reason for this is that any non-compliant value, such as a date or time value in another format, could prevent the parser from reading the rest of the data set. Context: #9 #10
from dicom-rs.
Thank you @Enet4 for the detailed explanation. I got the idea of conversion on retrieval. Well... dates/times can be treated this way: storing strings but retrieving dates/times. However please explain why you did the same for floating-point values in contrast to integer values stored natively? Are you afraid of meeting a non-standard floating-point value, for example, with a decimal comma instead of a dot? Thank you for following up on this conversation!
from dicom-rs.
However please explain why you did the same for floating-point values in contrast to integer values stored natively? Are you afraid of meeting a non-standard floating-point value, for example, with a decimal comma instead of a dot?
That would be a good point, and a justification to continue with this strategy, but the reasoning of this being the default is primarily to preserve the original representation: any textual value stays textual, thus preventing failures during the parsing phase and other oddities (such as decimal numbers losing precision when turned to a binary type).
This does not apply uniquely to dates/times and floating point values. If the VR is IS (e.g. for Instance Number), it will still be kept as a string. This is fine, as conversion is trivially done at a later stage through to_int
or any of the other conversion methods.
from dicom-rs.
OK @Enet4, thanks for clarifying the architecture.
Now I would like to share a real code converting DICOM elements into JSON values (some of them at least):
fn value_to_json<I, P>(element: &DataElement<I, P>) -> Option<JsonValue> {
if element.header().len.get().unwrap() == 0 {
return None;
}
println!("VR: {}", element.vr());
let value = element.value();
if value.primitive().is_some() {
return match value.multiplicity() {
0 => None,
1 => single_value_to_json(value),
_ => multi_value_to_json(value),
};
}
println!("Skip {} as non-primitive element", element.header().tag);
None
}
fn single_value_to_json<I, P>(value: &DicomValue<I, P>) -> Option<JsonValue> {
if let Ok(value) = value.float64() {
println!("float64");
return Some(JsonValue::from(value));
}
if let Ok(value) = value.uint16() {
println!("uint16");
return Some(JsonValue::from(value));
}
if let Ok(value) = value.string() {
println!("string");
return Some(JsonValue::from(value));
}
None
}
fn multi_value_to_json<I, P>(value: &DicomValue<I, P>) -> Option<JsonValue> {
if let Ok(value) = value.uint16_slice() {
println!("uint16[]");
return Some(JsonValue::from(value));
}
if let Ok(value) = value.float64_slice() {
println!("float64[]");
return Some(JsonValue::from(value));
}
if let Ok(value) = value.strings() {
println!("string[]");
return Some(JsonValue::from(value));
}
None
}
It traces the following for a file:
VR: UI
string
VR: UI
string
VR: DA
string
VR: TM
string
VR: CS
string
VR: LO
string[]
VR: CS
string
VR: UI
string
VR: UI
string
VR: US
uint16
VR: CS
string
VR: US
uint16
VR: US
uint16
VR: DS
string[]
VR: US
uint16
VR: US
uint16
VR: US
uint16
VR: US
uint16
VR: LT
string
Please note that value.float64_slice
seems to return None
for a multi-value DS-type element. I see a similar issue for single-value elements: value.float64
seems to return None
for them. Could you explain why?
from dicom-rs.
Please use to_multi_f64
instead. float64_slice
is a non-converting method, and would only work for FD-type or OD-type elements.
from dicom-rs.
Related Issues (20)
- Bulk image conversion of DICOM files to a directory
- toimage command line utility error - panics on LUT value processing HOT 4
- 1-bit pixel data conversion is currently not supported
- Inspect shared/per-frame functional groups HOT 2
- Deflated Explicit VR Little Endian Case - "Could not read data set token" HOT 3
- Decompose findscu to be more modular and have an easy-to-use library HOT 2
- InMemDicomObject with defined Length retains Length value after changes to inner value of object HOT 2
- dicom_dump not visible HOT 1
- toimage utility exports jpeg with 411 vs 422 sampling HOT 3
- detect_preamble and in extension from_reader_with_all_options doesn't check for size HOT 1
- Can't set_transfer_syntax in some cases
- First two bytes are not an SOI marker error HOT 4
- Iterate over all tags with an AttributeSelector HOT 4
- Adding private data elements (with creator) HOT 4
- dicom-transfer-syntax-registry does not build on Windows by default HOT 1
- Extended offset table support
- Support for multiple character repertoires (extended character sets) HOT 1
- Could not compile openjp2 HOT 10
- Issue when trying to open a DICOM file. HOT 2
- DICOM naive datetime retrieval HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dicom-rs.