You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Unknown normalization when rendering crops from spatial samples. #290
Thanks for the amazing framework. I am using the framework to extract non-linear features from image patches of visium samples. When performing some QC on the data, I noticed that the image renders of cropped patches have some sort of normalization which doesn't exist in the original image when loaded in QuPath or Openslide (https://openslide.org/api/python/).
Please find attached images. I tried to find the normalization function in the plot code, but without success.
Can you please help? Knowing what kind of normalization is used is crucial to minimise batch-effect in SOTA Histopathology analysis methods. If possible it would be great also to disable normalization by default since for different tissue images, the rendered normalizations shows vast differences in how the different stains are represented.
Not sure if it's an issue with matplotlib, the RGBA settings don't work when I'm doing gene expression plotting, too.
The issue: scverse/spatialdata#554
Hi, this issue appears to be plotting related. No normalization is performed when a bounding box query is applied and it seems that the problem is due to clipping the data to [0, 1]. I will therefore move the issue to spatialdata-plot.
(interpolation is performed, as implemented in dask_image.ndinterp.affine_transform, when rasterize() or transform() is called, but this doesn't seem to be the case of this issue).
In this particular case, normalizing the image to [0, 1] by dividing by 255, or, if the data appears to be integers, converting the dtype to int, should fix the problem. Please let me know if this fixes the issue.
I actually dug more into this and it looks like that the behavior is due to a side effect of the normalization strategy used in spatialdata-plot.
I could reproduce this on the Visium HD notebook. The full resolution image has unit values in {0, ... 255}, and we have that in spatialdata_plot.pl.render._render_images(), in the piece of code highlighted in the screenshot, the problem arises.
Precisely, for the Visium_HD_Mouse_Small_Intestine_hires_image image and for c=1, we have that
Can you please help? Knowing what kind of normalization is used is crucial to minimise batch-effect in SOTA Histopathology analysis methods. If possible it would be great also to disable normalization by default since for different tissue images, the rendered normalizations shows vast differences in how the different stains are represented.
On the positive side, @rushin682 I confirm that the downstream analysis would not be affected as this behavior only affects plotting, and the normalized data is never exposed outside the spatialdata-plot library.
Activity
Bioin-Mixologist commentedon Apr 29, 2024
Not sure if it's an issue with matplotlib, the RGBA settings don't work when I'm doing gene expression plotting, too.
The issue: scverse/spatialdata#554
melonora commentedon May 15, 2024
This is indeed matplotlib specific. See this issue also on stackoverflow: https://stackoverflow.com/questions/49643907/clipping-input-data-to-the-valid-range-for-imshow-with-rgb-data-0-1-for-floa
LucaMarconato commentedon Jul 10, 2024
Hi, this issue appears to be plotting related. No normalization is performed when a bounding box query is applied and it seems that the problem is due to clipping the data to [0, 1]. I will therefore move the issue to
spatialdata-plot.(interpolation is performed, as implemented in
dask_image.ndinterp.affine_transform, whenrasterize()ortransform()is called, but this doesn't seem to be the case of this issue).In this particular case, normalizing the image to [0, 1] by dividing by 255, or, if the data appears to be integers, converting the dtype to
int, should fix the problem. Please let me know if this fixes the issue.LucaMarconato commentedon Jul 10, 2024
(no action needed form the
spatialdata-plotdevelopers.)LucaMarconato commentedon Jul 13, 2024
I actually dug more into this and it looks like that the behavior is due to a side effect of the normalization strategy used in
spatialdata-plot.I could reproduce this on the Visium HD notebook. The full resolution image has

unitvalues in{0, ... 255}, and we have that inspatialdata_plot.pl.render._render_images(), in the piece of code highlighted in the screenshot, the problem arises.Precisely, for the
Visium_HD_Mouse_Small_Intestine_hires_imageimage and forc=1, we have thatbut
This leads to the warning
in
matploptlib.image._ImageBase._normalize_image_array().LucaMarconato commentedon Jul 13, 2024
On the positive side, @rushin682 I confirm that the downstream analysis would not be affected as this behavior only affects plotting, and the normalized data is never exposed outside the
spatialdata-plotlibrary.timtreis commentedon Sep 4, 2024
hey @rushin682, will merge the linked PR later this week. I think that should fix your issue. Would be happy for you to test with that branch 👍