Page MenuHomePhabricator

TIFF images that are too big to thumbnail don't display errors on image page
Closed, ResolvedPublic

Description

I've been confused for a while on why some files return a HTML version of an error, and others a textual version.

For instance: http://commons.wikimedia.org/wiki/File:Harplute-mechanicaldrawing-large-sidneyrobertsoncowell.png returns an HTML error and http://commons.wikimedia.org/w/index.php?title=File:England_Administrative_1931.tif&page=1 an image url. (the image contains the error report as well, but that is not the point really).

I cannot determine what the difference is between the two render methods. Clearly in one case we get the toHtml of ThumbnailImage class and in the other of MediaTransformError class, but


Version: 1.17.x
Severity: normal

Details

Reference
bz25647

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 21 2014, 11:14 PM
bzimport set Reference to bz25647.
bzimport added a subscriber: Unknown Object (MLST).
TheDJ created this task.Oct 25 2010, 8:31 PM

For those chasing this down: the first URL returns "Error creating thumbnail: Invalid thumbnail parameters or PNG file with more than 12.5 million pixels"

The second URL shows the alt-text for the image but no image. Right clicking and selecting "view image". A squid error page is shown then with this text:

While trying to retrieve the URL: http://upload.wikimedia.org/wikipedia/commons/thumb/b/bb/England_Administrative_1931.tif/lossy-page1-488px-England_Administrative_1931.tif.jpg

The following error was encountered:

    Unable to forward this request at this time. 
....
Generated Sat, 02 Apr 2011 03:05:42 GMT by sq49.wikimedia.org

So, in the second case there is a squid error for some reason. Perhaps the thumbnail failed but MW wasn't informed of the failure. The first image just doesn't get thumbnailed because, as the message says, the image was too big.

-shell. No explation given for its needness.

Presumably the png is failing the $wgMaxImageArea check in the Bitmap image handler, (normaliseParams is returning false, which is checked before TRANSFORM_LATER, thus the error is known at the time when the page is rendered). In Paged Tiff Handler, the equivalent check is done towards the end of the doTransform method (after the self::TRANSFORM_LATER check), so the error is only encountered when the 404 handler tries to make the thumbnail, not at page render time.

Looks like the squid error was part of the thumbnail backlog. The tif.jpg url now gives:

Error generating thumbnail

Error creating thumbnail: The resolution of the source file is too large.
No thumbnail will be generated.

So bawolff was right. It seems like some preliminary checks (like "Is this image too big?") would be useful.

mdale wrote:

maybe take into consideration bug 28135 for future large tiff support

Thehelpfulonewiki wrote:

Reassigning to wikibugs-l per bug 37789

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

Changing status Assigned -> New, since it is assigned to wikibugs-l...

greg added a comment.Jul 25 2013, 7:02 PM

All 3 urls mentioned in this report work for me today.

Can someone provide example TIFFs that *don't* work as expected? VipsScaler might be a solution to this problem.

Here's some:
MariaDB [commonswiki_p]> select img_name from image where img_media_type= 'BITMAP' and img_major_mime = 'image' and img_minor_mime = 'tiff' and img_width*img_height > 60000000 limit 20;
+-----------------------------------------------------------------------------------------------------------------------+

img_name

+-----------------------------------------------------------------------------------------------------------------------+

19F_chemical_shifts.tif
255-CC-65-HC-223,_back.tif
255-CC-65-HC-223.tif
A_street_in_yorktown_va.tif
Bathing_beauties_dancing_on_Washington_beach-t.tif
Bill_of_Rights.tif
Boylston_Street_and_the_Public_Garden,_showing_subway_entrance,_Boston,_Mass..tif
Buffalo_Light_House_-_00001a.tiff
Buffalo_Light_House_-_00002a.tiff
Buffalo_Light_House_-_00003a.tiff
Buffalo_Light_House_-_00004a.tiff
Buffalo_Light_House_-_00005a.tiff
Buffalo_Light_House_-_00006a.tiff
Buffalo_Light_House_-_00007a.tiff
Buy_Your_Victory_Bonds._Color_poster._Issued_by_Victory_Bond_Committee,_Ottawa,_Canada.,_ca._1917_-_NARA_-_516338.tif
Capitol_statuary_hall.tif
Christ_Church_(Cambridge,_Massachusetts)_-_00000a.tif
Christ_Church_(Cambridge,_Massachusetts)_-_00001a.tif
Christ_Church_(Cambridge,_Massachusetts)_-_00002a.tif
Christ_Church_(Cambridge,_Massachusetts)_-_00003a.tif

+-----------------------------------------------------------------------------------------------------------------------+

VIPS can be a soltion, but at the moment we don't have code to selectively do it only for bug tiffs (yet).

Of course this bug is more about max image area being checked at image render time instead of page parse time.

TheDJ added a comment.Jul 25 2013, 8:22 PM

And a handy category to remember:
https://commons.wikimedia.org/wiki/Category:Images_without_thumbnails

I'm doing some purges now btw. It seems they are pretty taxing on the system, I think I just dos'ed the thumbnailing server for a few seconds. :(

(In reply to comment #11)

And a handy category to remember:
https://commons.wikimedia.org/wiki/Category:Images_without_thumbnails
I'm doing some purges now btw. It seems they are pretty taxing on the
system, I
think I just dos'ed the thumbnailing server for a few seconds. :(

Btw, for thumbnails that are broken, purging is probably unnessary as we retry on every page view afaik

Someone please mark this bug as Resolved_Duplicate of bug 52045
(bug 52045 has a Patch to review which solves this issue)

  • This bug has been marked as a duplicate of bug 52045 ***
Gilles raised the priority of this task from Normal to Unbreak Now!.Dec 4 2014, 10:20 AM
Gilles added a project: Multimedia.
Gilles moved this task from Untriaged to Done on the Multimedia board.
Gilles lowered the priority of this task from Unbreak Now! to Normal.Dec 4 2014, 11:22 AM
Restricted Application added a project: Commons. · View Herald TranscriptFeb 22 2019, 2:30 PM