Wikimedia Bugzilla is closed!

Still there.

Still reproducible.

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)?

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.

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.

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.

(removing 41371 tracker, this is not related to Wikimedia's thumbnail infrastructure as Wikimedia doesn't use InstantCommons)

(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. ;-)

(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.

*** Bug 42342 has been marked as a duplicate of this bug. ***

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;
                  }

(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.

 *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.

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.

Umherirrender, could you take a look at this?

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

> * 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)

(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.

(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 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.

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.

Is this problem still an issue for the latest version of MediaWiki? If so, can we close this bug?

Yes, still current.

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)

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.)

(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

Change 142046 had a related patch set uploaded by Umherirrender:
Skip $wgMaxImageArea for InstantCommons files

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