Fix opening 358MPix Tiff #670
Merged
Conversation
This file contains 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
… DT can open 26770x13385 TIFF
Was done when trying to open 26770x13385 TIFF
This also fixes potential issues when buf was not allocated or if(t.spp > 1 && config != PLANARCONFIG_CONTIG)
|
I do not think this breaks anything, so unless there is any comment, i'm planning on merging this in +~24h |
LebedevRI
added a commit
to llvm/llvm-project
that referenced
this pull request
Apr 13, 2021
Overflows are never fun. In most cases (in most of the code), they are rare, because usually you e.g. don't have as many elements. However, it's exceptionally easy to fall into this pitfail in code that deals with images, because, assuming 4-channel 32-bit FP data, you need *just* ~269 megapixel image to case an overflow when computing at least the total byte count. In [[ https://github.com/darktable-org/darktable | darktable ]], there is a *long*, painful history of dealing with such bugs: * darktable-org/darktable#7740 * darktable-org/darktable#7419 * darktable-org/darktable@eea1989 * darktable-org/darktable@70626dd * darktable-org/darktable#670 * darktable-org/darktable@38c69fb and yet they clearly keep resurfacing still. It would be immensely helpful to have a diagnostic for those patterns, which is what this change proposes. Currently, i only diagnose the most obvious case, where multiplication is directly widened with no other expressions inbetween, (i.e. `long r = (int)a * (int)b` but not even e.g. `long r = ((int)a * (int)b)`) however that might be worth relaxing later. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D93822
arichardson
pushed a commit
to arichardson/llvm-project
that referenced
this pull request
Sep 10, 2021
Overflows are never fun. In most cases (in most of the code), they are rare, because usually you e.g. don't have as many elements. However, it's exceptionally easy to fall into this pitfail in code that deals with images, because, assuming 4-channel 32-bit FP data, you need *just* ~269 megapixel image to case an overflow when computing at least the total byte count. In [[ https://github.com/darktable-org/darktable | darktable ]], there is a *long*, painful history of dealing with such bugs: * darktable-org/darktable#7740 * darktable-org/darktable#7419 * darktable-org/darktable@eea1989 * darktable-org/darktable@70626dd * darktable-org/darktable#670 * darktable-org/darktable@38c69fb and yet they clearly keep resurfacing still. It would be immensely helpful to have a diagnostic for those patterns, which is what this change proposes. Currently, i only diagnose the most obvious case, where multiplication is directly widened with no other expressions inbetween, (i.e. `long r = (int)a * (int)b` but not even e.g. `long r = ((int)a * (int)b)`) however that might be worth relaxing later. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D93822
mem-frob
pushed a commit
to draperlaboratory/hope-llvm-project
that referenced
this pull request
Oct 7, 2022
Overflows are never fun. In most cases (in most of the code), they are rare, because usually you e.g. don't have as many elements. However, it's exceptionally easy to fall into this pitfail in code that deals with images, because, assuming 4-channel 32-bit FP data, you need *just* ~269 megapixel image to case an overflow when computing at least the total byte count. In [[ https://github.com/darktable-org/darktable | darktable ]], there is a *long*, painful history of dealing with such bugs: * darktable-org/darktable#7740 * darktable-org/darktable#7419 * darktable-org/darktable@eea1989 * darktable-org/darktable@70626dd * darktable-org/darktable#670 * darktable-org/darktable@38c69fb and yet they clearly keep resurfacing still. It would be immensely helpful to have a diagnostic for those patterns, which is what this change proposes. Currently, i only diagnose the most obvious case, where multiplication is directly widened with no other expressions inbetween, (i.e. `long r = (int)a * (int)b` but not even e.g. `long r = ((int)a * (int)b)`) however that might be worth relaxing later. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D93822
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
With following changes DT can now open 358MPix Tiff file produced by Hugin:
I also tested it on all combinations of TIFF's DT can produce - no regressions.
Also some generic cleanup.
TODO: BigTIFF support.