Enet4
Confusion between multiple windowing values vs. per-frame windowing values?
Hi!
I was reading through the pixeldata/src/attribute.rs and pixeldata/src/lib.rs to get familiar with how dicom-rs renders pictures.
Currently, if my understanding is correct:
-
ImagingProperties.windowcan hold one or window centers/widths. - Those values are fetched either from a global tag (that can have one or more values), either from per-frame groups - but the info of where the values came from is not recorded.
- Later in the rendering code, we either pick the only value, or assume that the number of values match the number of frames (else falling back to the first value).
I have couple of files locally that have more than one window values, those would render correctly (leaving behind a warning, but not sure if those are even printed by default?). But I suppose there's a (very theoretical) case where a file would have N frames and N global window values, then each frame would be rendered with a different window value?
According to General requirements for Window Center and Window Width, there can be multiple values of window center/window width which conveys that multiple alternative views can be presented.
The window level and rendering code don't seem to have support for this now, the image would just be rendered with the first combination.
If the values come from the per-frame group, then there can still be multiple window center/window widths per frame (it seems), but each frame needs to have the window center/width defined, so there isn't really a need to store which frame each window center/width came from.
Does this answer your question?
Yup, I'm aware that you can have many values, but thanks for clarifying :) My point was more that, with the current API I believe there's no way to distinguish between alternative window values and per-frame window values. The current code basically just assumes that the cardinality of window values is 1 or number of frames, and exposes all the values in a "flat" Vector. I suspect that to "properly" support multiple window values, we'd need to move from a flat list to a list of lists basically - though that'd be an API break.
Disclaimer: I'm quoting myself from memory now though and haven't looked at the code in a while 😅
Yep, agreed with you on that. I can try to find a time to work on that at some point!
That'd be awesome! It's not a blocking point for me currently (if that matters), but I suppose that it makes sense to shape the API into something future-proof earlier than later...
Thank you for the issue and follow-up discussion! I suppose the only way to take alternative window levels at the moment would be to retrieve them manually and add the option VoiLutFunction::Custom. Granted, it would be more intuitive if this part of API would let the consumer pick from one of the multiple window levels available, maybe by index.
Maybe there is something incoherent about the way window levels are interpreted in multi-frame scenarios (maybe multi-value Window Width and Window Center should mean something other than per-frame window levels?), in that case we ought to treat it as a bug.
And if performance is an issue, we can keep already keep a reference to the original data set object, so we may be able to defer VOI LUT property resolution for when it's truly needed.
Also leaving a mention of https://github.com/Enet4/dicom-rs/pull/632, which may be touching the same code.
