Last modified: 2014-09-24 00:50:43 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 T34387, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 32387 - InstantCommons broken for some images: Error creating thumbnail: Invalid thumbnail parameters
InstantCommons broken for some images: Error creating thumbnail: Invalid thum...
Status: PATCH_TO_REVIEW
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
unspecified
All All
: High normal (vote)
: ---
Assigned To: Gilles Dubuc
:
: 42342 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-11-12 20:05 UTC by Raimond Spekking
Modified: 2014-09-24 00:50 UTC (History)
20 users (show)

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


Attachments

Comment 1 Nemo 2012-08-23 09:02:25 UTC
Still there.
Comment 2 Sumana Harihareswara 2012-10-25 07:13:48 UTC
Still reproducible.
Comment 3 Nemo 2012-10-25 07:51:10 UTC
Both cases are (vertical) big images which show "Size of this preview: . Other resolution: ." as if MediaWiki as unaware of the image size at the point when those are calculated. Perhaps the local instance is not able to ask the correct width (which needs height info, cf. bug 25989)?
Comment 4 Bryan Tong Minh 2012-10-25 14:08:41 UTC
Can reproduce this locally, but only if scaler is not IM. The source of this error is around line 60 in Bitmap.php.

Essentially, we're bailing out on $srcWidth * $srcHeight > $wgMaxImageArea. This check should be ignored if we're not actually scaling the image ourselves.
Comment 5 Rob Lanphier 2012-10-25 18:17:20 UTC
Thanks Bryan!  Putting the "easy" tag on this since the fix looks like it's been spelled out, and someone just needs to do it.
Comment 6 Bryan Tong Minh 2012-10-25 20:11:47 UTC
I'm quite sure that a fix is not easy. BitmapHandler does not know whether the file actually needs to be scaled, or whether it is scaled externally, and I don't see an easy way to introduce this information.
Comment 7 Krinkle 2012-10-25 20:21:31 UTC
(removing 41371 tracker, this is not related to Wikimedia's thumbnail infrastructure as Wikimedia doesn't use InstantCommons)
Comment 8 Nemo 2012-10-25 20:26:32 UTC
(In reply to comment #7)
> (removing 41371 tracker, this is not related to Wikimedia's thumbnail
> infrastructure as Wikimedia doesn't use InstantCommons)

But it *provides* it as a service, which should work for MediaWiki and Commons to be as valuable. :-) Anyway you're right that it might be a confusing dependency. ;-)
Comment 9 Krinkle 2012-10-26 04:52:22 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > (removing 41371 tracker, this is not related to Wikimedia's thumbnail
> > infrastructure as Wikimedia doesn't use InstantCommons)
> 
> But it *provides* it as a service, which should work for MediaWiki and Commons
> to be as valuable. :-) Anyway you're right that it might be a confusing
> dependency. ;-)

Sure it does. But that's not relevant. bug 41371 is a tracker bug under the Wikimedia product (not MediaWiki) for its scaler infrastructure. This bug is not relevant. Simple as that.

Meaning where http://translatewiki.net/wiki/File:Amazone_-_Al_Hansen_-_Kölnisches_Stadtmuseum-5054.jpg is broken, these all work:
* https://commons.wikimedia.org/wiki/File:Amazone_-_Al_Hansen_-_K%C3%B6lnisches_Stadtmuseum-5054.jpg
* https://en.wikipedia.org/wiki/File:Amazone_-_Al_Hansen_-_K%C3%B6lnisches_Stadtmuseum-5054.jpg
* https://nl.wiktionary.org/wiki/File:Amazone_-_Al_Hansen_-_K%C3%B6lnisches_Stadtmuseum-5054.jpg

That doesn't make it less important, I just took it off a tracker that bugged the wrong people. This is a MediaWiki software bug, not a Wikimedia operations issue.
Comment 10 Nemo 2012-11-24 21:27:58 UTC
*** Bug 42342 has been marked as a duplicate of this bug. ***
Comment 11 PlusPedia 2012-11-25 00:17:21 UTC
If This is a duplicate of the bug: 42342:

Meanwhile I found the solution.

$wgMaxImageArea = 1.25e7; is too small.

My first Solution:
LocalSettings.php:
 $wgMaxImageArea = $wgMaxImageArea * 100 


Background File: Bitmap.php:

Til 18.4 (incl.):

        if ( $mimeType !== 'image/jpeg' &&
            $srcWidth * $srcHeight > $wgMaxImageArea )
        {
            return false;
        } 


Since 19.0:

            if ( $srcWidth * $srcHeight > $wgMaxImageArea &&
                    !( $image->getMimeType() == 'image/jpeg' &&
                        self::getScalerType( false, false ) == 'im' ) ) {
                # Only ImageMagick can efficiently downsize jpg images without
loading
                # the entire file in memory
                return false;
                  }
Comment 12 Nemo 2012-11-25 00:42:20 UTC
(In reply to comment #11)
>  $wgMaxImageArea = $wgMaxImageArea * 100 

Well, yes, I guess this is a functioning workaroung because you're basically disabling the check mentioned in comment 4, but you can as well (I think) kill your wiki if someone uploads a big PNG locally so it's definitely not a solution.
Comment 13 PlusPedia 2012-11-25 02:01:36 UTC
 *100 might bei too large. But *4 (50 Megapixel [7x7]) or *8 (100 Megapixel (10x10)) instead of just 12.5 Megapixel will be enough for most usual (consumer) Images. 

Our Server should make it. between *4 and *8 ist a qite good workaround i guess.
Comment 14 PlusPedia 2012-11-26 00:25:23 UTC
Actually it's not even a workaround. It's just setting the parameter to a higher Value.  However Media-Wiki should return a clearer error. Like: The image has too many pixels.
Comment 15 Sumana Harihareswara 2012-12-09 17:28:37 UTC
Umherirrender, could you take a look at this?
Comment 16 Umherirrender 2012-12-09 18:50:52 UTC
wgMaxImageArea was increased on wmf wikis to 25MP[1]. But the bug is from 2011, where the lower limit was also active on commons.

For the given file, mediawiki tests the resolution against its local limit, which gives false, because that limit is lower than the foreign limit on commons. PlusPedia's workaround works here.

Possible solution:
* Increase default limit in MediaWiki
* Always pass the check with true for foreign repo files, but I have no idea, if that works and what commons will give as error, when trying to get a "bigger" file (Some one knows a example file over 25 MP?)
* ...


For windows host there is another problem with these files (bug 42900).

[1] https://gerrit.wikimedia.org/r/gitweb?p=operations/mediawiki-config.git;a=commit;f=wmf-config/CommonSettings.php;h=d655a716d866089f94736a6964a303ab73f69b9a
Comment 17 Bawolff (Brian Wolff) 2012-12-09 22:57:08 UTC
> * Increase default limit in MediaWiki
> * Always pass the check with true for foreign repo files

The second option is the proper fix. The $wgMaxImageArea is meant to protect your own server from DOS - if the file isn't thumbnailed locally, you can't DOS your local server so the check should not apply.

>but I have no idea,
> if that works and what commons will give as error, when trying to get a
> "bigger" file (Some one knows a example file over 25 MP?)


There's a bunch at [[Commons:Category:PNG_files_affected_by_MediaWiki_restrictions]]. You will get an api response with a "thumberror" parameter:

thumberror: "Error creating thumbnail: Invalid thumbnail parameters or PNG file with more than 25 million pixels" (retrieved from https://commons.wikimedia.org/w/api.php?action=query&titles=File:Bch%20l.png&prop=imageinfo&iiprop=dimensions|url&iiurlwidth=100 )

I have no idea if instant commons handles that properly. Note most other errors (like OOM. Or the $wgMaxImageArea check on tiff files since PagedTiffHandler does the check later than it should) wouldn't be in the api response (On WMF anyhow with the scale on 404) since the error wouldn't happen until after the api response is sent. instant commons may detect that the result is not an image when it tries to cache the thumb, but i wouldn't bet on it.

(fun fact, the thumberror error varies with user language. Yay for things in the api getting translated when they shouldn't)
Comment 18 Umherirrender 2013-02-02 18:35:51 UTC
(In reply to comment #17)
> > * Increase default limit in MediaWiki
> > * Always pass the check with true for foreign repo files
> 
> The second option is the proper fix. The $wgMaxImageArea is meant to protect
> your own server from DOS - if the file isn't thumbnailed locally, you can't DOS
> your local server so the check should not apply.

I am not sure, for ForeignDBRepo the transform is done on the client and not on the repo, when bypassing the check for local files, what does that means for transform under ForeignDBRepo?

> thumberror: "Error creating thumbnail: Invalid thumbnail parameters or PNG file
> with more than 25 million pixels" (retrieved from
> https://commons.wikimedia.org/w/api.php?action=query&titles=File:Bch%20l.png&prop=imageinfo&iiprop=dimensions|url&iiurlwidth=100
> )
> 
> I have no idea if instant commons handles that properly. Note most other errors
> (like OOM. Or the $wgMaxImageArea check on tiff files since PagedTiffHandler
> does the check later than it should) wouldn't be in the api response (On WMF
> anyhow with the scale on 404) since the error wouldn't happen until after the
> api response is sent. instant commons may detect that the result is not an
> image when it tries to cache the thumb, but i wouldn't bet on it.

I have commited Gerrit change #47225 to report the thumb error from the api to the user.
Comment 19 Nemo 2013-05-19 16:32:42 UTC
(In reply to comment #18)
> I have commited Gerrit change #47225 to report the thumb error from the api
> to the user.

Merged. So, what now?
Comment 20 Bawolff (Brian Wolff) 2013-05-19 17:04:45 UTC
(In reply to comment #19)
> (In reply to comment #18)
> > I have commited Gerrit change #47225 to report the thumb error from the api
> > to the user.
> 
> Merged. So, what now?

In certain (probably extremely rare cases if you are using commons as the foreign repo) the end user will get better error reporting. Its a good thing, but doesnt fix this bug.
Comment 21 ryan.glasnapp 2013-10-22 19:07:08 UTC
I'm having what appears to be the same issue, but with local images instead of those via commons. 

MW 1.21.2, with $wgImageMagick set to false.

I first noticed this issue when I upgraded from 1.18 to 1.21. 

I increased $wgMaxImageArea to 5e7 which seems to "fix" the issue for individual images; however, pages with large numbers of images hit a 30s execution timeout.
Comment 22 Fabrice Florin 2013-12-18 19:27:37 UTC
Is this problem still an issue for the latest version of MediaWiki? If so, can we close this bug?
Comment 23 Nemo 2013-12-18 19:32:23 UTC
Yes, still current.
Comment 24 Bawolff (Brian Wolff) 2014-03-26 13:16:55 UTC
Suggested fix for this bug:

* Add a new method in the MediaHandler class, canRenderImageThisSize( $file ) which takes a File object as its only parameter, and returns a boolean to signal if image is small enough to render. The implementation in MediaHandler should be a stub method always returning true, with an implementation in BitmapHandler which actually checks $wgMaxImageArea. This should replace the code dealing with $wgMaxImageArea currently in BitmapHandler::normaliseParams (Although possibly not the BitmapHandlerCheckImageArea hook).

* In the FileRepo class, new method that returns a boolean - enforceFileSizeChecks(), which would return true in FileRepo class, but false in ForeignAPIRepo class to signal that Foreign api files don't do the file resolution check.

*In the File::transform method, add some code which checks for $this->repo->enforceFileSizeChecks(), if that's true, then it checks $this->handler->canRenderImageThisSize( $this ), if that's false, it outputs a MediaTransformError object, the first argument should be a specific error message to this situation, not the generic 'thumbnail_error' message.

*Tiff handler should also be migrated to this new system (bug 62306)
Comment 25 D Hugh Redelmeier 2014-06-25 06:38:08 UTC
I just hit this "problem".  Or perhaps a variant of it.

- local JPEG file from a modest camera takes pictures with more than 12.5 megapixels

- uploading it to our Wiki yields this opaque error message:
    Error creating thumbnail: Invalid thumbnail parameters

- debugging ensues.  Wasted hours.

The absolutely simple fix is to print a useful diagnostic.  Perhaps
   Error creating thumbnail: image is larger than nnn megapixels

Bonus points: a link to a guide to how to deal with this problem.
Here's a minimal one I just created:

https://www.mediawiki.org/wiki/Manual:Errors_and_Symptoms#JPEG

Summary: think of the poor users who hit this limit.

(Perhaps every error message ought to have its own wiki page.)
Comment 26 Nemo 2014-06-25 06:43:10 UTC
(In reply to D Hugh Redelmeier from comment #25)
> The absolutely simple fix is to print a useful diagnostic.  Perhaps
>    Error creating thumbnail: image is larger than nnn megapixels

You're very right, can you file a bug about this specific enhancement to the output and mark it as blocker of this? As said above and elsewhere, I believe the problem is the thumbnailing process is so entangled that errors are not easy to tell apart, so it's not trivial to satisfy your request, but we definitely should.

Another bug may be needed for max memory; even DreamHost (!!) recommends 500 MB... http://wiki.dreamhost.com/MediaWiki#Not_enough_memory
Comment 27 Gerrit Notification Bot 2014-06-25 19:30:38 UTC
Change 142046 had a related patch set uploaded by Umherirrender:
Skip $wgMaxImageArea for InstantCommons files

https://gerrit.wikimedia.org/r/142046

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


Navigation
Links