Skip to content

Set self._data_dtype in scale_and_set_data for CPU scaled textures#2601

Merged
brisvag merged 5 commits intovispy:mainfrom
aganders3:fix-scalable-texture-dtype
Jun 19, 2024
Merged

Set self._data_dtype in scale_and_set_data for CPU scaled textures#2601
brisvag merged 5 commits intovispy:mainfrom
aganders3:fix-scalable-texture-dtype

Conversation

@aganders3
Copy link
Copy Markdown
Contributor

I noticed this warning when running tests, and I think it traces back to the change in this PR.

vispy/visuals/tests/test_colormap.py: 6 warnings
vispy/visuals/tests/test_image.py: 39 warnings
vispy/visuals/tests/test_scalable_textures.py: 4 warnings
  /Users/aandersoniii/src/vispy/vispy/gloo/texture.py:18: DeprecationWarning: finfo() dtype cannot be None. This behavior will raise an error in the future. (Deprecated in NumPy 1.25)
    info = np.finfo(dtype)

See #2350 (comment) for some context.

I am partly guessing what this code meant to be doing, but here the _data_dtype is set the first time scale_and_set_data is called. @brisvag at your suggestion I am trying to think of a test that could have caught this, but need to think about it a little more.

@aganders3 aganders3 marked this pull request as ready for review June 14, 2024 17:09
Copy link
Copy Markdown
Collaborator

@brisvag brisvag left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, looking back at it:

  • this should happen when the texture is first initialized with no data, resulting in self._data_dtype == None
  • then, if new data is set via scale_and_set_data, a new dtype is saved. However, before this PR, the self._data_dtype remains None.
  • the next time data is set, if the data has a different dtype, things should get messed up because the conversion/clipping will go awry.

I tried to spin up a simple test but things are getting in the way and I don't have the time now to dive deeper, so if you do please take a stab!

@aganders3
Copy link
Copy Markdown
Contributor Author

@brisvag does this test make sense to you?

Here is a failed run without the proposed change:
https://github.com/vispy/vispy/actions/runs/9549721978/job/26320015919

Copy link
Copy Markdown
Collaborator

@brisvag brisvag left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perfect! Thanks @aganders3 :)

@aganders3
Copy link
Copy Markdown
Contributor Author

Of course I left a bad debug print in there though. 🤦

I believe tests will pass now with b1692b4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants