search

cantaloupe-project / cantaloupe

High-performance dynamic image server in Java
https://cantaloupe-project.github.io/
Other
270 stars 111 forks source link

ISSUE-680: proper /MAX handling under pre-cropped and un-cropped scenarios #709

Closed DiegoPino closed 2 weeks ago

DiegoPino commented 2 weeks ago

What?

Solves #680

I tried to be as minimalistic (code-wise) as possible (after some iterations that had nothing of minimal).

HOW?

Basically now, before processing MAX at ::constrainSizeToMaxPixels, we request from the Operation List the actual "So far what size would this image result in?", and use that Dimension as base for all calculations. This way if a REGION/CROP (if any) results in less pixel area than MAX_PIXELS, MAX has no effect, but if not, scaling is done proportional to the REGION requested (including if REGION\CROP exceeded the actual source dimensions .. which is IIIF valid), and will then constrain the final dimensions to fit into a MAX_PIXELS sized region.

As always, test code is > than the actual fix :)

Note: according to me this works (tested with #680 image too). Test pass. But would be nice though if someone had the time to give this a human test.

DiegoPino commented 2 weeks ago

I'm getting Tests failing here (not related to this pull? -- yes, related to this pull).

Version3_0ConformanceTest.testXYRegionOutOfBounds:206 expected: <400> but was: <500>

Fixing this

DiegoPino commented 2 weeks ago

FYI: This assumes there is max. a single Crop (or extending class) operation in the Operation List. I don't know if somehow one could via a normal processing chain add more than one at all? but maybe (via code?) someone would?