Keep shrink-on-load from moving the projection - #1
Open
kbond wants to merge 1 commit into
Open
Conversation
A decode rung that is not a proportional shrink of the source makes the pipeline solve geometry against a raster the plan never measured, so `hint()` now climbs past any rung the plan does not project the same way.
2 tasks
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.
Same file, same transform: GD returns 100x120, imagick throws. Scaling a 563x678 JPEG to width 100 decodes at 141x170 under shrink-on-load, and the pipeline solves the resize against that raster rather than the source the plan measured, so it lands on 100x121 and the driver refuses its own work. Any JPEG whose dimensions aren't block-aligned can hit it - over a sweep of 458 such sizes,
inside=800xdrifts on 38%.hint()now climbs past any rung the plan doesn't project the same way, so the shrink survives where it's safe (93-100% of those sizes) instead of being abandoned. The corpus gains an unaligned JPEG, since the existing two are 600x400 and 400x600 and every rung of them is exact - which is why neitherProjectionAccuracyTestnorCrossDriverEquivalenceTestcould see this. With the fixture and without the fix, both go red.Found while writing an
alto/imagetransformer forzenstruck/image.