Bug 6133 - Cover art scaling
: Cover art scaling
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: CLI
: 7.0
: PC Windows XP
: P2 normal (vote)
: ---
Assigned To: Unassigned bug - please assign me!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-11 17:50 UTC by Barry Gordon
Modified: 2007-11-11 19:55 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Barry Gordon 2007-11-11 17:50:24 UTC
Using HTTP and the nightly build of 11/03

I make the following request

GET /music/181/cover_100x100.jpg HTTP/1.0

I expect the cover to come back at 100x100 no matter how it is scaled.  It comes back as expected when the cover art is stored with x=y (e.g. 200x200)  It does not come back as expected when the art is stored  lets say as 200x232.  In that case there are white borders on the left and right sides. You are preserving the aspect ratio of the original cover, using the larger of the two dimensions and bordering the art to fill it out, but not fulfiling the request. SS 6.5.4 does it as expected rescaling the cover changing the aspect ratio.  Perhaps there should be an option to preserve the aspect ratio?

In 6.5.4 the option of Squash was the default if no option was spcified.  Do I now have to explicitly state the option?  It is almost as if the default is now Crop.
Comment 1 KDF 2007-11-11 19:37:13 UTC
from Slim/Web/Graphics.pm

# if both width and height are given but no resize mode, resizeMode is pad

you have given both height and width, so you get 'pad' mode.  this is new with SC 7 since most of the core artwork is using this method to get artwork at the existing aspect ratio and within the layout contraints.  If you wish to have stretch, you'll need to add that option.
Comment 2 Barry Gordon 2007-11-11 19:55:36 UTC
No issue.  Please update the documentation under changes to reflect same.  I added the option and it works fine