Still there.

sumanah wrote:

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

Bryan.TongMinh wrote:

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.

Bryan.TongMinh wrote:

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 (T43371) 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. ***

bugzilla wrote:

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

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

bugzilla wrote:

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

bugzilla wrote:

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.

sumanah wrote:

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

hugh wrote:

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

In T34387#848369, @Umherirrender wrote:

As in previous comments, I am not sure if a File::isLocal() call is okay, because I did not know, if a DBForeignFiles does the transform on the same server as the wiki is running or not. I assume this, so the isLocal is not enough, because than you will get a thumb on the remote wiki, which will not be rendered on the local wiki.

Indeed. there is not much difference between a local and a ForeignDB file apart from using a different database (and fetching the file description page in a different way).

Change 186602 had a related patch set uploaded (by Umherirrender):
Bypass TransformTooBigImageAreaError for ForeignApiFile

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

Patch-For-Review

Is the issue at https://commons.wikimedia.org/wiki/File:Logiz_de_la_Lune_Rousse-Affiche1900.jpg related to this?
A big image (14,887 × 10,300 pixels, file size: 47.31 MB) with "Error creating thumbnail: Error code: 137".

In T34387#1312392, @Yann wrote:

Is the issue at https://commons.wikimedia.org/wiki/File:Logiz_de_la_Lune_Rousse-Affiche1900.jpg related to this?
A big image (14,887 × 10,300 pixels, file size: 47.31 MB) with "Error creating thumbnail: Error code: 137".

No, its unrelated. Try changing the format of the jpg from progressive to baseline.

OK, see https://phabricator.wikimedia.org/T100435

Change 186602 merged by jenkins-bot:
Bypass TransformTooBigImageAreaError for ForeignApiFile

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

• https://gerrit.wikimedia.org/r/186602 (branch master): MW-1.26-release, WMF-deploy-2015-05-27_(1.26wmf8)