Skip to content

[Bug]: get_data_shape on list of Data objects is incorrect #1269

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

Closed
rly opened this issue May 2, 2025 · 1 comment · Fixed by #1270
Closed

[Bug]: get_data_shape on list of Data objects is incorrect #1269

rly opened this issue May 2, 2025 · 1 comment · Fixed by #1270
Assignees
Labels
category: bug errors in the code or code behavior

Comments

@rly
Copy link
Contributor

rly commented May 2, 2025

What happened?

get_data_shape is used in many places, including shape validation and getting dimension labels. In NWB, an Image neurodata type is a descendent of Data, i.e., a dataset. ImageReferences has a field that stores a 1-D list/array of Image objects. However, when validating the shape of input to that field in ImageReferences, get_data_shape recurses into the Image data to get the shape of the images. As a result, a 1-D list of references to Image objects, which on disk has shape (N, ), will be reported by get_data_shape as having shape (N, W, H). where (W, H) is the shape of the first image. The schema says the field should have shape (N, ).

Secondly, writing valid ImageReferences produces a warning on write:
/Users/rly/Documents/NWB/hdmf/src/hdmf/build/objectmapper.py:874: IncorrectDatasetShapeBuildWarning: Shape of data does not match shape in spec 'ImageReferences'
warnings.warn(msg, IncorrectDatasetShapeBuildWarning)

This occurs when getting dimension labels.

get_data_shape on a list/array of Data objects (a dataset of references) should return the shape of the list/array and not recurse deeper.

Steps to Reproduce

get_data_shape([Data(name="a", data=[1, 2]), Data(name="b", data=[3, 4])])

Traceback

Operating System

macOS

Python Version

3.13

Package Versions

No response

@rly rly added the category: bug errors in the code or code behavior label May 2, 2025
@rly rly self-assigned this May 2, 2025
@h-mayorquin
Copy link
Contributor

Maybe related to #1238 and #1237

@rly rly closed this as completed in #1270 May 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category: bug errors in the code or code behavior
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants