Warper: improve XSCALE/YSALE computation logic when the target shape is quite different from the source shape #13806
+310
−223
Conversation
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
rouault
force-pushed
the
warp_scale_geolocation_with_rotation
branch
8 times, most recently
from
adb898a to
dc9d6f6
Compare
Collaborator
…is quite different from the source shape The current logic to compute them is quite naive, and only reasonably works when the shape of the output chunk is similar (in proportion and orientation) to the one of the input chunk. Failing that, inappropriate values are computed leading typically to blurring. Rework the logic to be closer to a specific case that had already been implemented to deal with discontinuities at the antimeridian, but with modifications. So we compute the transformation of a maximum of 10x10 unit squares in the target pixel space to the source pixel space. If a source polygon retains an approximative rectangular shape with modest rotation, use the width/height of that rectangle to compute XSCALE/YSCALE. Otherwise compute the area of the rectangle and make XSCALE/YSCALE be the inverse of the square root of the area. Average the values for each output polygon, except values that are less than 10% of the maximum scale, to avoid issues with polar discontinuities Also revise the logic to decide whether we use a 4 input sample per output pixel vs generalized resampling kernel for bilinear and bicubic. Previously we only used the 4-sample formula if not downsampling (with a margin error of 5%). Increase that tolerance to allow up to a 50% downsampling. And emit a debug trace when the generalized formula is used instead of the 4 sample one. Due to those changes, a few existing expected checksums had to be adjusted. And we also had to adjust a heuristics in the average/mode/Q1/Q3/max/etc. resampling code path that dealt with polar discontinuities to make a related test still pass.
rouault
force-pushed
the
warp_scale_geolocation_with_rotation
branch
from
dc9d6f6 to
7e18bd3
Compare
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.
The current logic to compute them is quite naive, and only reasonably works when the shape of the output chunk is similar (in proportion and orientation) to the one of the input chunk. Failing that, inappropriate values are computed leading typically to blurring.
Rework the logic to be closer to a specific case that had already been implemented to deal with discontinuities at the antimeridian, but with modifications. So we compute the transformation of a maximum of 10x10 unit squares in the target pixel space to the source pixel space. If a source polygon retains an approximative rectangular shape with modest rotation, use the width/height of that rectangle to compute XSCALE/YSCALE. Otherwise compute the area of the rectangle and make XSCALE/YSCALE be the inverse of the square root of the area. Average the values for each output polygon, except values that are less than 10% of the maximum scale, to avoid issues with polar discontinuities
Also revise the logic to decide whether we use a 4 input sample per output pixel vs generalized resampling kernel for bilinear and bicubic. Previously we only used the 4-sample formula if not downsampling (with a margin error of 5%). Increase that tolerance to allow up to a 50% downsampling. And emit a debug trace when the generalized formula is used instead of the 4 sample one.
Due to those changes, a few existing expected checksums had to be adjusted. And we also had to adjust a heuristics in the average/mode/Q1/Q3/max/etc. resampling code path that dealt with polar discontinuities to make a related test still pass.