Last modified: 2014-05-29 20:47:33 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T36974, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 34974 - image's real dimensions could differ from dimension specified in html if height-based scaling is used
image's real dimensions could differ from dimension specified in html if heig...
Status: NEW
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
1.19
All All
: Lowest trivial (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-04 22:22 UTC by Saibo
Modified: 2014-05-29 20:47 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
"broken" commons logo (1.57 KB, image/png)
2012-03-05 23:05 UTC, Saibo
Details
correctly scaled to 41x100 with GIMP based on a 1000px rendering (cropped afterwards) (1.49 KB, image/png)
2012-03-05 23:09 UTC, Saibo
Details

Description Saibo 2012-03-04 22:22:03 UTC
Wiki: [[Datei:NowCom2010-Q-2.svg|x100px|right]]
HTML: <img width="41" height="100" src="//upload.wikimedia.org/wikipedia/commons/thumb/f/f1/NowCom2010-Q-2.svg/41px-NowCom2010-Q-2.svg.png" alt="NowCom2010-Q-2.svg">

but the image is: 41px × 99px https://upload.wikimedia.org/wikipedia/commons/thumb/f/f1/NowCom2010-Q-2.svg/41px-NowCom2010-Q-2.svg.png on top right corner of https://de.wikipedia.org/w/index.php?title=Wikipedia:WikiProjekt_Commons-Transfer&oldid=100481318

Results in a bad scaling (Commons circle looks broken) of the image in my FF10.
Comment 1 Bawolff (Brian Wolff) 2012-03-04 23:00:46 UTC
So what's happening is that making it 41px wide is not tall enough, but 42px wide is to tall, so MediaWiki compromises and makes it 41px wide, but tells the browser to scale the height to be 100px, in order to be close as possible.

Work around is to just use [[Datei:NowCom2010-Q-2.svg|x99px|right]].

Making it possible for the images to be scaled with a height that's correct down to the pixel seems like it would introduce quite a bit of complication for something that is not really applicable very often.
Comment 2 Mark A. Hershberger 2012-03-05 22:21:50 UTC
(In reply to comment #0)
> Results in a bad scaling (Commons circle looks broken) of the image in my FF10.

I'm confused.  What exactly do you suggest we should do?
Comment 3 Saibo 2012-03-05 23:02:25 UTC
(In reply to comment #2)
> (In reply to comment #0)
> > Results in a bad scaling (Commons circle looks broken) of the image in my FF10.
> 
> I'm confused.  What exactly do you suggest we should do?

Let the server scale it to this height (but not advise the browser to do so). The thumbnail should be scaled to the dimension which is written to html. That would not introduce bad artifacts since the server has the full image as source available (the browser only has the thumbnail available and may use simple scaling algorithms like "nearest neighbor").

I guess, the problem is that there is probably(?) no interface to request thumbnails with a height specified at the scaling servers. Only requesting thumbnails by width is possible. So my previous request is not possible.  So this bug maybe could only be a LATER since the interface to the scaling servers is too less powerful.  

Another option: do not write a height to html which is not served as image. Problem: the user specifically asked for this height.
Comment 4 Saibo 2012-03-05 23:05:52 UTC
Created attachment 10181 [details]
"broken" commons logo
Comment 5 Saibo 2012-03-05 23:09:39 UTC
Created attachment 10182 [details]
correctly scaled to 41x100 with GIMP based on a 1000px rendering (cropped afterwards)
Comment 6 Saibo 2012-03-05 23:12:13 UTC
It would be nice to know that the requested height is not really available and that a bad compromise is used. Then the wiki page author could choose another height. But I have no idea how this message could be brought to him.
Comment 7 Bawolff (Brian Wolff) 2012-03-05 23:13:39 UTC
[mid air collision]

>I guess, the problem is that there is probably(?) no interface to request
>thumbnails with a height specified at the scaling servers. Only requesting
>thumbnails by width is possible

That is correct in the current code. (OTOH support for adding arbitrary new
parameters seems to be there, so its quite possible it wouldn't be difficult to
change that)

>Another option: do not write a height to html which is not served as image.
>Problem: the user specifically asked for this height.


There's also things going the other direction where one wants to scale a very
narrow image to some height, and the scalers en up scaling it too high. As a
matter of fact, I think the writing the differing width in html is relatively
new behaviour ( bug 28076 possibly)
Comment 8 C. Scott Ananian 2014-05-29 20:47:33 UTC
Yes, the stored filename and all indexing for the thumbnail are width based.  This means that we can't distinguish between multiple thumbnails with different heights but the same (rounded) width.  This is a pretty fundamental limitation of the current code, but also a good way to prevent unnecessarily proliferation of thumbnail variants.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links