cornerstonejs
Why does the loader warn "rendering performance will suffer considerably", when minMax comparison fails?
Hey,
I'm trying to make sense of an error message I'm getting for a particular DICOM volume. So this file has the "classic" wrong min / max pixel values that were already discussed at length in #73, #76, #83, and ultimately fixed by introduction of the "non-strict mode" in #127. The thing I'm not understanding is the Warning message itself. It's saying "rendering performance will suffer considerably". I'm mostly asking out of interest here, but why is this? Looking at the source I can see the warning is emitted in src/shared/calculateMinMax.js, after calculating the minMax (and getMinMax.js is explicitly saying in a comment: "We always calculate these values because we don't trust DICOM"). So if it's not the calculation of the minMax itself that's causing the performance drop, what is?
Sorry for asking a question here, I'm not sure if this project has a mailing list or chat channel somewhere. Happy to ask it there if someone can point me to it. Thanks!
This warning may no longer be valid, especially if we always calculate the min/max value. CornerstoneJS uses an array to map raw pixel values to display pixels as part of the display pipeline. The array is indexed based on raw pixel value and sized specifically to cover the entire dynamic range of raw pixel values to conserve memory. This size is based on the min and max pixel values - and if wrong, could result in lookups on array indices that didn't exist resulting in a major performance slowdown. This was 5 years ago though, so the same performance slowdown may no longer exist - and won't happen if we always calculate min/max
Thank you very much for clarifying and explaining the reasoning behind this. Should we get rid of the "rendering performance" part of the warning? Also, do you happen to have any idea as to why this happens? I scanned for the error (minMax values incorrect) in the data corpus I have access to (CT data), it doesn't seem to be related to scanner or manufacturer, the calculation seems to be wrong seemingly at random. Maybe it's related to some anonymizer, but it'd beyond me why anonymizers would want to touch these tags.