[MGNLIMG-72] MultiStepResizer: processes infinitely if the target size is bigger than the input image Created: 14/Oct/10  Updated: 04/Dec/13  Resolved: 15/Oct/10

Status: Closed
Project: Imaging
Component/s: image operations
Affects Version/s: 2.0.5
Fix Version/s: 2.0.6

Type: Bug Priority: Critical
Reporter: Philipp Bärfuss Assignee: Jan Haderka
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
causality
is causing MGNLETK-43 Imaging causes high CPU usage Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

The algorithm only works for downsizing:

  • h,w are not going to change as they are bigger than targetWidth and targetHeight
  • the condition (w != targetWidth || h != targetHeight) is never true


 Comments   
Comment by Boris Kraft [ 14/Oct/10 ]

resizing should never scale up. This makes zero sense in the context of web publishing, where you want quality.

For what its worth, one alg that would be interesting is to create a bigger image with say transparent bg and place the smaller image in the middle.

Comment by Philipp Bärfuss [ 15/Oct/10 ]

Boris: that is very true and the auto crop/resize should probably work that way. But if you use the resize operation to scale up, be it by will or by mistake, it should still not block the magnolia instance.

As for now you go to the online demo, open the gallery, open the showbox -> boom!

So we have to fix it immediately. The strategy of the auto cropping/resizing can be changed later.

Generated at Mon Feb 12 02:12:00 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.