Bugzilla – Bug 17140
Non-square cover art issue
Last modified: 2011-11-23 11:15:06 UTC
If an album has non-square cover art, more specifically, if the cover art is higher than wider then the cover art is displayed wrongly (my opinion at least) in the default skin. In the classic skin the cover art is shown better. As I have always been using fishbone skin until recently I don't know whether the default skin has always handled handled non-square cover art this way or if this is a result of the onebrowser development. The attachment defaultskin.jpg shows non-square cover art in the default skin. THe attachment classic.jpg shows non-square cover art in the classic skin.
Created attachment 7230 [details] non-square cover art in default skin.
Created attachment 7231 [details] non-square cover art in classic skin
This shouldn't happen, but can you attach the original image file so I can try and reproduce?
Created attachment 7246 [details] Example of cover art which is non-square. Here is an example of a cover art that his higher than wider. I don't know if it is important or not but have all my cover art embedded in my FLAC files. If needed I have more examples. By the way, the other way around, i.e. when a cover is wider than higher is treated OK by the default skin.
Yes, I'm seeing this too in the Default skin. With a cover taller than it is wide, the text below the cover art in the large artwork view is obscured.
Why isn't this targeted for 7.6.0? This is something that should work.
== Auto-comment from SVN commit #32832 to the slim repo by mherger == == http://svn.slimdevices.com/slim?view=revision&revision=32832 == Bug: 17140 Description: add workaround for the resizing issue of non-square cover art. Let the JS limit the height to the maximum size we want
The web UI uses 100x100_o which maintains the aspect, I'm not sure if this is a bug or if the JS fix is enough here. There's no bug in the resizer itself. Michael?
I should add that when I say "maintains the aspect", in 'o' mode the resizer uses the desired width and ignores the desired height. If what we really want is a transparent-padded square image we would need to use mode 'm'. The web UI also uses 50x50_o for small artwork, which has the same problem of course.
Is the transparency necessary? Since the web ui always wants to fit the artwork within a square space, is there a mode that maintains aspect ratio while scaling the _larger_ of either width or height to n pixels, without the transparency?
Yeah the m mode does what you describe (m=max), and you do want transparency, otherwise you get ugly black borders. I think the web UI might use _o so that the popup large artwork doesn't have to be square.
Wouldn't that mean returning everything as png files? I thought that was tried once before and then you came back to returning jpegs (or maybe it returns the original format)? Couldn't the resizer have a mode that takes a numeric argument and rather than scaling either the width or the height to fit that number, it would examine the width and height of the original image and scale the larger of the two dimensions to that number.
Yeah PNG is used but only for non-square images. It's the only way to do it. Most artwork is square so is JPEG.
Andy - the bug is that 100x100_o would return eg. a 100x120px image. Only the width is respected, but not the height: http://gyazo.com/f07aae4223af6afbc7440f80d8ffdc33 But with the workaround in place this no longer is a 7.6.1/p2 issue.
Yeah, that is how 'o' it is supposed to work, though. 100x100_m will fit it into a 100x100 square with padding.
This is really a bug with how the web UI works, not a resizing bug.
Is the issue discussed in this thread http://forums.slimdevices.com/showthread.php?t=90990 maybe a side effect of the work around mentioned in comment 7 of this bug report? Johan
> Is the issue discussed in this thread > http://forums.slimdevices.com/showthread.php?t=90990 maybe a side effect of the > work around mentioned in comment 7 of this bug report? No. Comment #7 added a workaround to the web UI. Andy - the problem is the resizing code. It's broken on device as well as the web UI. I added a workaround as mentioned. But on device it's still broken.
== Auto-comment from SVN commit #33731 to the slim repo by agrundman == == http://svn.slimdevices.com/slim?view=revision&revision=33731 == Fixed bug 17140, the code that switched to png for images resized to a different aspect ratio was missing from the newer resizing code, oops