-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Difficulty Converting DICOM Image to Viewable JPEG (uint8) - Inconsistent Pixel Value Ranges #1823
Comments
This is almost certainly this bug in bioformats: ome/bioformats#3620 |
I think the solutions would be to (a) modify bioformats, (b) when the inverted flag is set, undo what bioformats does, or (c) have a different tile source that would read non-slide modality dicoms. |
Looking further into this, I think the correct solution for bioformats would be to NOT invert the values when rescale=false (and then the bug they have would be avoided). The window width and center are for the actual values. Bioformats does an inversion when the photometric interpretation is MONOCHROME1 (and then, only for 16 bit samples, incorrectly applied window width and center). |
Bioformats ignores the rescale=false option with MONOCHROME1 dicom data. Further, not only does it invert the pixel value direction, but it offsets 16 bit data incorrectly. This undoes these effects so that the raw pixel data is returned. Fixes #1823.
Bioformats ignores the rescale=false option with MONOCHROME1 dicom data. Further, not only does it invert the pixel value direction, but it offsets 16 bit data incorrectly. This undoes these effects so that the raw pixel data is returned. Fixes #1823.
@alevangel Can you see if the change in #1834 works for you? There are CI-built wheels at https://app.circleci.com/pipelines/github/girder/large_image/6626/workflows/91dae0ca-d09c-4186-b210-beecb47f9094/jobs/47848/artifacts. |
Bioformats ignores the rescale=false option with MONOCHROME1 dicom data. Further, not only does it invert the pixel value direction, but it offsets 16 bit data incorrectly. This undoes these effects so that the raw pixel data is returned. Fixes #1823.
@manthey In the proposed solution, I observed that the image contrast varies significantly depending on the zoom levels. This leads to an inconsistent color display, where the image appears different at different zoom levels. In other words, the image does not maintain uniform and consistent coloring during zooming. My current hotfix addresses this issue by adjusting the bit depth of the image tiles before normalization. Specifically: bits_stored = int(self._metadata['seriesMetadata']['0028,0101 Bits Stored'])
high_bit = int(self._metadata['seriesMetadata']['0028,0102 High Bit'])
if high_bit < bits_stored - 1:
shift = (bits_stored - 1) - high_bit
tile = tile << shift
mask = (1 << bits_stored) - 1
tile = tile & mask Subsequently, I normalize the image using the min and max values obtained from the thumbnail image: min_max_range=(np.min(thumbnail_image), np.max(thumbnail_image))
image = (image - min_max_range[0]) / (min_max_range[1] - min_max_range[0]) * 255 |
In the sample image provided, I'm not seeing a different based on zoom. That is, the data looks like it is all on the same scale from 0 to 16383, with the interesting contrast range identified by the window width and center. The default as jpegs all end up with pixel values between 128 and 191 (because of how int16 data is scaled to uint8). Can you share more specifically how you are seeing the data vary by zoom? |
Bioformats ignores the rescale=false option with MONOCHROME1 dicom data. Further, not only does it invert the pixel value direction, but it offsets 16 bit data incorrectly. This undoes these effects so that the raw pixel data is returned. Fixes #1823.
Description
I'm encountering an issue when trying to read and display a specific DICOM image (
int16
). Specifically, I'm having trouble converting a region of the image to a JPEG (uint8
) format suitable for easy viewing.The DICOM metadata includes
0028,1050 Window Center
and0028,1051 Window Width
values, suggesting a recommended intensity window for display. I initially assumed that clipping the pixel values within this range would produce a viewable image. However, this approach doesn't work correctly. There are areas within the image (at different magnifications) where useful pixel data falls significantly outside the specified window, leading to an incorrect visualization.The provided code example demonstrates the issue. When extracting a
512x512
region at a low magnificatio, the resulting NumPy array contains values clustered around-15708
. Using this value as a baseline for normalization doesn't produce consistent results across all regions at that magnification. The dynamic range of values is not consistent. How should such case be handled?Is also note that QuPath is able to handle this image correctly at all zoom levels, indicating that a proper display solution exists.
Download file: 1.3 1.dcm.zip
Code example:
Environment
References
uint16
format, which might be relevant to understanding the underlying data representation.The text was updated successfully, but these errors were encountered: