Last modified: 2013-04-13 10:44:50 UTC
Since Bug 46551 was closed as "invalid", it is now desireable having a possiblity to limit the image revisions (imageinfo) for the tiltles queried to a small number if you want *avoid sending multiple queries* (e.g. if you want the latest thumburls of 10 files that may or may not have more than 50 image revisions in total). Otherwise setting generators and multiple titles is completely useless.
If you consider the given example, this should be *really possible*. When categories of images are displayed, 200 thumbnails are shown. Re-building this behaviour using the API is currently impossible (with a reasonable speed).
iilimit is per image and not per request, so using iilimit = 1 (which is the default) will give you one imageinfo per image. Due to the default of the dir, this is always the latest version. This can be mentioned better on the auto doc page, that is right. This query will give you 200 files from a category and the corrosponding url for a thumb to build the <img>: http://commons.wikimedia.org/w/api.php?action=query&generator=categorymembers&gcmtitle=Category:Commons%20statistics&gcmlimit=200&gcmtype=file&prop=imageinfo&iiprop=url&iiurlwidth=120
(In reply to comment #2) > iilimit is per image and not per request Thank you and I am sorry that I did not look at it more carefully. >This query will give you 200 files from a category and the corrosponding url >for a thumb to build the <img>: It will only give you 50 imageinfos max. Try this query (a category that has more than 50 images): http://commons.wikimedia.org/w/api.php?action=query&generator=categorymembers&gcmtitle=Category:Flowers&gcmlimit=200&gcmtype=file&prop=imageinfo&iiprop=url&iiurlwidth=120&format=jsonfm
Yes, that is right, because since Gerrit change #47189 you can do only 50 file transforms with the api (for normal and sysop) A transform is needed to create the thumb/provide the url for the thumb. Without the iiurlwidth parameter, you will get more imageinfos, but you need the url/thumb, so that does not help. I updated the docs with Gerrit change #57268
(In reply to comment #4) > A transform is needed to create the thumb/provide the url for the thumb. Do you know the reason why it's performance is bad? > I updated the docs with Gerrit change #57268 This indeed, clarifies things. Thanks.
(In reply to comment #5) > (In reply to comment #4) > > A transform is needed to create the thumb/provide > > the url for the thumb. > Do you know the reason why it's performance is bad? No, you can read only some comments on the gerrit change set for that. Maybe it halps in understanding (not for me) Maybe Aaron or Anomie can give a better explanation here. Brian Wolff asked on the change set, too.
(In reply to comment #5) > (In reply to comment #4) > > A transform is needed to create the thumb/provide the url for the thumb. > Do you know the reason why it's performance is bad? Because it has to actually resize the image, which can involve a good deal of image processing. I don't know why exactly it can't calculate the info for the thumbnail without actually resizing it, but that's how it works.
(In reply to comment #4) > I updated the docs with Gerrit change #57268 successfully merged If you think, that is enough for this bug, please close. Thanks.
(In reply to comment #8) > please close I thought it was. > can't calculate the info for the thumbnail without > actually resizing it When images are used in the usual UI, it's beneficial to know whether resizing works (or OOM occurs, it's over the max-size), ... but if this information is not forwarded to the API, there is no reason to scale all files. Also I doubt all were scaled because these queries usually took (and take) less than 1 s to complete while when requesting URIs of unusual image sizes, the server usually takes at least 1 s to respond per file. And I thought files are scaled on dedicated "image scalers"... so you really send requests out to these scalers and wait for them to complete and then send out the API response? Either I am under a misconception or this sounds really dubious...
