fix(tiff): check for invalid bit depth for palette images#5091
Merged
lgritz merged 1 commit intoAcademySoftwareFoundation:mainfrom Mar 17, 2026
Merged
fix(tiff): check for invalid bit depth for palette images#5091lgritz merged 1 commit intoAcademySoftwareFoundation:mainfrom
lgritz merged 1 commit intoAcademySoftwareFoundation:mainfrom
Conversation
Reading the TIFF 6.0 spec, on p. 23, it sure looks like palette images can only be 4 or 8 bits per sample. But the libtiff set of test images indeed has 2, 4, 8, and yes, 16 bps palette images among the examples. So I think we should support up to 16, since we might encounter it in the wild, but no higher. We didn't previously check for this, though, and that could lead to accepting invalid TIFF files, and then potentially have problems with `(1 << m_bitspersample)` which appears several times. That of course is safe if m_bitspersample can't be > 16. Also check and proper error for a file that has a bitspersample that is not one of the valid choices (1, 2, 4, 6, 8, 10, 12, 14, 16, 24, 32, 64), and proper errors for if the sampleformat was an unknown value or was not a valid value for the number of bits per sample. Note that this changes the reference output of some tests because the new checks can alter the first error discovered in a corrupt file. Signed-off-by: Larry Gritz <lg@larrygritz.com>
lgritz
added a commit
to lgritz/OpenImageIO
that referenced
this pull request
Mar 19, 2026
…twareFoundation#5091) Reading the TIFF 6.0 spec, on p. 23, it sure looks like palette images can only be 4 or 8 bits per sample. But the libtiff set of test images indeed has 2, 4, 8, and yes, 16 bps palette images among the examples. So I think we should support up to 16, since we might encounter it in the wild, but no higher. We didn't previously check for this, though, and that could lead to accepting invalid TIFF files, and then potentially have problems with `(1 << m_bitspersample)` which appears several times. That of course is safe if m_bitspersample can't be > 16. Also check and proper error for a file that has a bitspersample that is not one of the valid choices (1, 2, 4, 6, 8, 10, 12, 14, 16, 24, 32, 64), and proper errors for if the sampleformat was an unknown value or was not a valid value for the number of bits per sample. Note that this changes the reference output of some tests because the new checks can alter the first error discovered in a corrupt file. Signed-off-by: Larry Gritz <lg@larrygritz.com>
ssh4net
pushed a commit
to ssh4net/OpenImageIO
that referenced
this pull request
Apr 1, 2026
…twareFoundation#5091) Reading the TIFF 6.0 spec, on p. 23, it sure looks like palette images can only be 4 or 8 bits per sample. But the libtiff set of test images indeed has 2, 4, 8, and yes, 16 bps palette images among the examples. So I think we should support up to 16, since we might encounter it in the wild, but no higher. We didn't previously check for this, though, and that could lead to accepting invalid TIFF files, and then potentially have problems with `(1 << m_bitspersample)` which appears several times. That of course is safe if m_bitspersample can't be > 16. Also check and proper error for a file that has a bitspersample that is not one of the valid choices (1, 2, 4, 6, 8, 10, 12, 14, 16, 24, 32, 64), and proper errors for if the sampleformat was an unknown value or was not a valid value for the number of bits per sample. Note that this changes the reference output of some tests because the new checks can alter the first error discovered in a corrupt file. Signed-off-by: Larry Gritz <lg@larrygritz.com> Signed-off-by: Vlad (Kuzmin) Erium <libalias@gmail.com>
ssh4net
pushed a commit
to ssh4net/OpenImageIO
that referenced
this pull request
Apr 1, 2026
…twareFoundation#5091) Reading the TIFF 6.0 spec, on p. 23, it sure looks like palette images can only be 4 or 8 bits per sample. But the libtiff set of test images indeed has 2, 4, 8, and yes, 16 bps palette images among the examples. So I think we should support up to 16, since we might encounter it in the wild, but no higher. We didn't previously check for this, though, and that could lead to accepting invalid TIFF files, and then potentially have problems with `(1 << m_bitspersample)` which appears several times. That of course is safe if m_bitspersample can't be > 16. Also check and proper error for a file that has a bitspersample that is not one of the valid choices (1, 2, 4, 6, 8, 10, 12, 14, 16, 24, 32, 64), and proper errors for if the sampleformat was an unknown value or was not a valid value for the number of bits per sample. Note that this changes the reference output of some tests because the new checks can alter the first error discovered in a corrupt file. Signed-off-by: Larry Gritz <lg@larrygritz.com> Signed-off-by: Vlad (Kuzmin) Erium <libalias@gmail.com> Signed-off-by: Vlad <shaamaan@gmail.com>
ssh4net
pushed a commit
to ssh4net/OpenImageIO
that referenced
this pull request
Apr 1, 2026
…twareFoundation#5091) Reading the TIFF 6.0 spec, on p. 23, it sure looks like palette images can only be 4 or 8 bits per sample. But the libtiff set of test images indeed has 2, 4, 8, and yes, 16 bps palette images among the examples. So I think we should support up to 16, since we might encounter it in the wild, but no higher. We didn't previously check for this, though, and that could lead to accepting invalid TIFF files, and then potentially have problems with `(1 << m_bitspersample)` which appears several times. That of course is safe if m_bitspersample can't be > 16. Also check and proper error for a file that has a bitspersample that is not one of the valid choices (1, 2, 4, 6, 8, 10, 12, 14, 16, 24, 32, 64), and proper errors for if the sampleformat was an unknown value or was not a valid value for the number of bits per sample. Note that this changes the reference output of some tests because the new checks can alter the first error discovered in a corrupt file. Signed-off-by: Larry Gritz <lg@larrygritz.com> Signed-off-by: Vlad <shaamaan@gmail.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
2 participants
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.
Reading the TIFF 6.0 spec, on p. 23, it sure looks like palette images can only be 4 or 8 bits per sample. But the libtiff set of test images indeed has 2, 4, 8, and yes, 16 bps palette images among the examples. So I think we should support up to 16, since we might encounter it in the wild, but no higher.
We didn't previously check for this, though, and that could lead to accepting invalid TIFF files, and then potentially have problems with
(1 << m_bitspersample)which appears several times. That of course is safe if m_bitspersample can't be > 16.Also check and proper error for a file that has a bitspersample that is not one of the valid choices (1, 2, 4, 6, 8, 10, 12, 14, 16, 24, 32, 64), and proper errors for if the sampleformat was an unknown value or was not a valid value for the number of bits per sample.
Note that this changes the reference output of some tests because the new checks can alter the first error discovered in a corrupt file.