fix: several bug fixes related to internal use of image_span#5004
Merged
lgritz merged 1 commit intoAcademySoftwareFoundation:mainfrom Jan 18, 2026
Merged
fix: several bug fixes related to internal use of image_span#5004lgritz merged 1 commit intoAcademySoftwareFoundation:mainfrom
lgritz merged 1 commit intoAcademySoftwareFoundation:mainfrom
Conversation
* ImageBuf internal buffer span lacked correct chansize. The internal m_bufspan is an `imagespan<byte>`, and as such, it needs to remember the size of the original data type. Otherwise, there's a cascade of potential errors when it thinks that the individual values are byte sized. * In both ImageInput and ImageOutput, several sanity checks of image_span size versus expectations were incorrect. They were only checking if the total byte sizes matched expectations, but they are allowed to disagree when you consider type conversions (in which case, it's the total number of values that need to match, not the total byte sizes. Signed-off-by: Larry Gritz <lg@larrygritz.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR addresses critical bugs in the internal handling of image_span objects across ImageBuf, ImageInput, and ImageOutput classes. The main issue was incorrect size validation when type conversions occur between the data format and the native image format.
Changes:
- Fixed ImageBuf's internal buffer span initialization to correctly track the channel size of the original data type
- Replaced inline size validation logic in ImageInput and ImageOutput methods with a centralized
check_span_sizeutility that properly distinguishes between byte-size matching (for unknown types) and value-count matching (for concrete types with potential type conversion) - Removed commented-out dead code from ImageInput
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/libOpenImageIO/imagebuf.cpp | Fixed m_bufspan initialization to include chansize parameter for proper type tracking |
| src/libOpenImageIO/imageoutput.cpp | Added check_span_size utility and refactored all write methods to use correct size validation |
| src/libOpenImageIO/imageinput.cpp | Added check_span_size utility, refactored all read methods to use correct size validation, and removed dead code |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // total byte size needs to match the "native" size, or the format is | ||
| // concrete and the number of value must match (it's ok if the size | ||
| // doesn't match, since a data type conversion will occur). | ||
| if (datatype.is_unknown()) { // Unknown assumes native chan types |
There was a problem hiding this comment.
Corrected spelling of 'chan' to 'channel' in the comment for clarity.
Suggested change
| if (datatype.is_unknown()) { // Unknown assumes native chan types | |
| if (datatype.is_unknown()) { // Unknown assumes native channel types |
| // total byte size needs to match the "native" size, or the format is | ||
| // concrete and the number of value must match (it's ok if the size | ||
| // doesn't match, since a data type conversion will occur). | ||
| if (datatype.is_unknown()) { // Unknown assumes native chan types |
There was a problem hiding this comment.
Corrected spelling of 'chan' to 'channel' in the comment for clarity.
Suggested change
| if (datatype.is_unknown()) { // Unknown assumes native chan types | |
| if (datatype.is_unknown()) { // Unknown assumes native channel types |
Collaborator
Author
|
Any comments about these important bug fixes? |
Collaborator
Author
|
No objections -> merging. |
lgritz
added a commit
to lgritz/OpenImageIO
that referenced
this pull request
Jan 18, 2026
…SoftwareFoundation#5004) * ImageBuf internal buffer span lacked correct chansize. The internal `m_bufspan` is an `image_span<byte>`, and as such, it needs to remember the size of the original data type. Otherwise, there's a cascade of potential errors when it thinks that the individual values are byte sized. * In both ImageInput and ImageOutput, several sanity checks of image_span size versus expectations were incorrect. They were only checking if the total byte sizes matched expectations, but they are allowed to disagree when you consider type conversions (in which case, it's the total number of values that need to match, not the total byte sizes. Signed-off-by: Larry Gritz <lg@larrygritz.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
ImageBuf internal buffer span lacked correct chansize. The internal
m_bufspanis animage_span<byte>, and as such, it needs to remember the size of the original data type. Otherwise, there's a cascade of potential errors when it thinks that the individual values are byte sized.In both ImageInput and ImageOutput, several sanity checks of image_span size versus expectations were incorrect. They were only checking if the total byte sizes matched expectations, but they are allowed to disagree when you consider type conversions (in which case, it's the total number of values that need to match, not the total byte sizes.