Template talk:LargeImage

4 MP

This is a great template... but 4 MP is not a "large" image, if you consider what is out there in the camera market today. I changed the recommendation to 30 megapixles. It's just an arbitrary number. I could see the number as low as 20MP, but much lower then that doesn't seem very useful. J.smith (talk) 23:17, 11 December 2008 (UTC)

GIF Animations

Could this be used for monster GIF animations like this one, I wonder? Or perhaps a different but similar template? --Keith111 (talk) 06:55, 9 September 2009 (UTC)

Links too other sizes

File:Gustave Doré - The Holy Bible - Plate I, The Deluge.jpg has links to pages with other sizes of the image (800px, 1000px, 2000px, and 3000px). I think it would be useful to put that functionality into this template. I think it may be possible to use urls like 1000px version. Does anyone know ho how to construct such urls automatically in the template? /Ö 14:31, 15 January 2010 (UTC)

I just added a link to an interactive zooming vimage viewer on the toolserver. --Dschwen (talk) 13:27, 19 March 2010 (UTC)

And as a side note: I just finished processing the about 3000 largest images on commons for the zooming image viewer on an external server with more available memory than the toolserver. --Dschwen (talk) 21:38, 29 April 2010 (UTC)

Stupid template name

Sorry, but this template name is not a good choice. It implies that uploading large images is a bad thing. Furthermore it is applied inconsistently. I'll be running a bot soon to retag images based on their pixel count. I will set an arbitrary number such a s 50MP. Below the tag will be removed, above it will be added. It would be nice if we could come up with a better name, such as {{VeryLarge}}.

P.S.: every threshold will be arbitrary, and endless discussions about it won't make that fact go away. There is a wide spectrum of hardware/connection capabilities on the user end and choosing one number will always be bad for at least one part of the spectrum (dialup/broadband, desktop/mobile-phone). And we have a zooming image viewer that incrementally fetches image data now, so nobody has to download gigantic images just to view a tiny detail anymore. --Dschwen (talk) 13:33, 19 March 2010 (UTC)

Renamed to {{LargeImage}} (conforms with the category name). Next step: writing a bot to maintain this tag automatically. --Dschwen (talk) 15:53, 26 April 2010 (UTC)

The bot is now running. --Dschwen (talk) 03:24, 27 April 2010 (UTC)

I think the threshold should be lowered considerably. The template provides a great function of linking to the zooming image viewer you mentioned, but it's needed for images much smaller than 50 MP. The vast majority of users have a screen resolution of 1280x1024 or less. Most browsers give you two options when viewing images larger than the canvas area of your browser: fit to screen and full size. You say that no one has to download gigantic images to view a tiny detail anymore, yet your 50 MP threshold would force just that for quite a large number of images that would greatly benefit from the zooming viewer. Additionally, images far less than 50 MP can cause problems for users who try to view them in their browser, including the image not appearing at all, locking up the browser, or crashing the OS. Much smaller images will consume a large amount memory when decompressing to render. For example, a 16 MP image will take up around 45 MB of memory. A number of websites (correctly) warn visitors of large images that are much smaller than 50 MP. E.g., see STScI's warning text for their "massive file"[1] (52+ MP) and "large file"[2] (<9 MP) full resolution images. I would recommend a minimum threshold of around 8-10 MP. That way, users won't have to worry about one of the aforementioned problems and they will have an easy way to view images that are too large for screen display. Also, also, I like the icon and visibility of the hand-generated warning at File:Whole world - land and oceans 12000.jpg -- Earthsound (talk) 21:59, 30 April 2010 (UTC)

Screen resolution is irrelevant here. 50MP occupy between 150 and 200MB of RAM (depending on RGB vs. RGBA representation), computers nowadays can be expected to have well above 512MB RAM. Almost every digital camera nowadays has at least a resolution of 10MP. I am not willing to label such common images as having an unusually large number of pixels. Short: in absence of convincing arguments I will not change the threshold of the bot. I am fully aware that any number will always have a certain degree of arbitrariness. The current threshold affects about 2000-3000 images on commons, lowering it to 10MP or even 8MP would make the process completely unmanageable, having to tag hundreds of thousands of images. Plus it will send the wrong message. I absolutely want to avoud discouraging people form uploading high resolution imagery. The handcrafted template you mention will do just that. A scary warning icon, implying that something bad is going on. --Dschwen (talk) 21:19, 7 May 2010 (UTC)

I disagree for two reasons. First, I think screen resolution has a lot to do with this discussion, which is what you yourself argued when you said "we have a zooming image viewer that incrementally fetches image data now, so nobody has to download gigantic images just to view a tiny detail anymore". Viewing images that are much larger than your screen's resolution currently poses a very real problem for Wikimedia Commons users. This template provides a link to excellent tools that provide for a much better user experience when encountering these large files. There are quite a few images that are lower than the current threshold that really need something like the interactive viewers to help the end user experience. The MP threshold you keep going back to is the less relevant concern, IMHO, even if we assume that every user's machine has the RAM necessary to handle images of any size. I think we should encourage the use of a tools like the interactive viewers, as there isn't another built-in option (in web browsers) for finer control over how to view images more than a few multiples of screen width or height. Secondly, as the Wikimedia Commons' audience is worldwide, one cannot/should not assume that the common, current computer spec (wrt RAM) is applicable to a large percentage of users. I think it would be better to make reasonable efforts to help those with less RAM. Digital cameras may have 10MP images, but that's to improve image quality (especially when printing) and to capture more information in the image. This increase in image resolution has nothing to do with whether they can be viewed in a browser. On the contrary, the fact they are much larger than screen resolutions goes hand-in-hand with the need for more more control over viewing large images. As such, I don't think it's a valid argument for keeping these images from linking to the interactive viewers, regardless of their commonality. Rather than a MP threshold, I think it would be better to use the larger of an image's width and height as the threshold, so that more images can make use of the viewing tool. Is there a technical (or other) reason why a bot(s) would have trouble handling 50k, 500k (or more) images that would be tagged as such? As for the message it could send (discouraging the uploading of high res images), changing the wording and layout of the template should be able to alleviate that concern. Which reminds me, I think changing the template by moving the links to the interactive viewers to a new first line (changing the linked text to something like "View this image in the interactive, zoomable viewer", e.g.) and prepending the warning text with copy to explain the viewers and why they are there would be useful. Earthsound (talk) 17:29, 25 May 2010 (UTC)

It seems to me that what you want is to make the zoom viewer gadget enabled by default. I'll make a few adjustments to it (disabling it for images smaller than screen resolution), improve user interface (i.e. make the zoom links more obvious than the full-res download link). --Dschwen (talk) 18:40, 25 May 2010 (UTC)

---

“Screen resolution is irrelevant here.” Small image sizes but big file size: I used it for SVG File:1 42 polytope 7-cube.svg right?Perhelion (talk) 15:33, 8 July 2011 (UTC)

SVG images are somewhat of a different story. Indeed a large filesize can cause a drain on a weak computer simply because it means long rendering times. --Dschwen (talk) 18:43, 8 July 2011 (UTC)

Hello, I see now this template is only for JPG, this is not mentioned at all. What is for example with a PNG filesize of 20MB (this must be a strong limit for MediaWiki)? -- Perhelion 10:35, 9 July 2011 (UTC)

Stupid template icon

Would this be better?

Also the icon is a little bit stupid, it looks like that of the copyvio-template. I don't want to tag the best commons-images with such an icon. Perhaps somebody has a better idea, to generate a positive attention. --Kolossos (talk) 20:18, 20 April 2010 (UTC)

No, it sucks. :-) (wenn wir mal bei dem Sprachgebrauch bleiben wollen). The "feature" star has no place in this, it dilutes its meaning. In fact I'm looking at completely redesigning the template. Btw. I'm already running tests with a bot to automatically tag/untag images with this template. --Dschwen (talk) 20:01, 26 April 2010 (UTC)

Second idea.

Probably you have right. Whats with the second icon? It means to become bigger and bigger with the borders. Perhaps is also a text like:
LARGE
IMAGE
the best solution. --Kolossos (talk) 20:34, 26 April 2010 (UTC)

No. I think it is to clunky and I do not like the hand metaphor at all. I would like to make the template comply with the {{Information}} style, but with a slight color change. And I would like to add a sit javascript which switches the original full resolution link with a link to the interactive viewer (and modifies the template text accordingly). Without javascript the template would be just a warning and a link to the viewer, with javascript the viewer would be the default in place of the full resolution link, and the waning template would contain the full resolution link. This seems less obstrusive and most effective. We would be presenting a more reasonable default choice to the user. Commons has only about 3100 images with more than 50MP. --Dschwen (talk) 20:51, 26 April 2010 (UTC)

The redisign should also reduce the massive amount of text that creeped into the template. Who bothers reading this? I'd rather have a nice page behind the "(info)" link. --Dschwen (talk) 21:02, 26 April 2010 (UTC)

Sounds ok. It was definitely too much text.

Will this javascript also works if a normal user (IP) looks an image inside the wikipedia? I believe this is important, because only few found the link to commons.

I hope we have in a year over one million good images with >50MP :-) --Kolossos (talk) 21:05, 26 April 2010 (UTC)

Ok, I changed the template design and cut down on the text in most translations. The new version of the template makes formatting (big/bold/font size) in the translations unnecessary. This is done in the layout template now. --Dschwen (talk) 03:27, 27 April 2010 (UTC)

Unusually large number of pixels?

I just observed that an image of 7.77 MB has received the template. What I suggest is to replace the text "This image has an unusually large number of pixels..." by "This image has a large number of pixels...". Wouter (talk) 06:23, 27 April 2010 (UTC)

The file size in MB is not really relevant here. It is not so much about download speed, rather than the uncompressed size of the image. --Dschwen (talk) 21:33, 29 April 2010 (UTC)

Thanks for the explanation. I just suggest to not using the word "unusually". What is unusually now may be usually in two years time. Wouter (talk) 07:13, 1 May 2010 (UTC)

The template threshold will be adapted then. For now it is unusual. --Dschwen (talk) 12:33, 1 May 2010 (UTC)

The file size in MB is relevant; it is a very severe problem for those people who are still on dial-up modems (of whom there are plenty, in rural and third-world regions). Maybe 10 MB might be a suitable size for a warning? - MPF (talk) 11:22, 20 July 2010 (UTC)

Megabytes and Megapixels pose a completely different challenge. The template was designed to warn users about images that upon uncompressing occupy so much space that they could slow down or crash their computers. This is a situation that cannot easily be averted once it happens, hence it warrants a warning. A slow download can easily be averted by just canceling it. In my opinion no warning is necessary here. --Dschwen (talk) 13:14, 20 July 2010 (UTC)

"Link" to viewer

Does anyone agree that there should be a sentence included like this:

If you are not sure your system can handle this image simply use the viewer linked on the right.

Cheers --Saibo (Δ) 13:36, 18 September 2010 (UTC)

I have prepared a JavaScript which will make the viewer links appear in place of the download link by default on LargeImage tagge dimages. The link to the full resolution will appear in the template below. I absolutely believe that this is superior to adding more text. People won't read text. Too much text clutters the page. More text means more translation work. --Dschwen (talk) 17:15, 18 September 2010 (UTC)

Yep, good idea - indeed. I imported this script now. The link of the preview image is not working. And I would put the non-flash link first - flash should be avoided. Additionally the flash viewer shows a very blurry image.

Now just integrate this into Mediawiki to let it appear automatically without the need for a template if the image exceeds a predefined number of MPx. ;-) Cheers --Saibo (Δ) 20:26, 18 September 2010 (UTC)

I added the linkswap to the general javascript here. --Dschwen (talk) 02:11, 3 January 2011 (UTC)

Download button

This template refers to a 'Download' button above the image, but this button does not exist on the Monobook skin. Is this option available to those not using Vector? If so, it would be good to provide a link in this template. Modest Genius (talk) 23:16, 4 February 2011 (UTC)

Interactive viewer broken? Formatting suggestion (again)

The flash & non-flash interactive viewers appear broken to me in the most recent versions of Firefox (11), Opera (11.62), & chromium (19.0.1085.0). See the following examples for two different problems:

thumbnail not sized correctly: http://toolserver.org/~dschwen/iip/wip.php?f=1887_Perspective_Map_of_Anniston_Alabama.jpg&flash=no

"Not a valid JPG file!" error: http://toolserver.org/~dschwen/iip/wip.php?f=Magna_Carta.jpg&flash=no

The flash viewer is also broken for those files:

http://toolserver.org/~dschwen/iip/wip.php?f=1887_Perspective_Map_of_Anniston_Alabama.jpg

http://toolserver.org/~dschwen/iip/wip.php?f=Magna_Carta.jpg

Also, can the text/links to the viewers be moved to the left side of the template and some natural language added? Something like "Use the interactive large-image-viewer."

Earthsound (talk) 20:50, 29 March 2012 (UTC)

The two images are fixed now. --Dschwen (talk) 22:57, 29 March 2012 (UTC)

CFD

The category this template uses is up for discussion at Commons:Categories for discussion/2012/04/Category:Large images. - dcljr (talk) 22:41, 3 April 2012 (UTC)

Duplicate?

Template:InteractiveViewer description? -- πϵρήλιο ℗ 01:19, 28 April 2012 (UTC)

Indeed. Looks to be the same. According to the transclusion count, Template:InteractiveViewer is used 600 times. And Template:LargeImage is used 14,000 times, so I'm suggesting we'll unify towards Template:LargeImage. --Krinkle 21:34, 7 February 2019 (UTC)

Justification for flash viewer

Hi, I just tried both the flash viewer and the non-flash viewer and I found the non-flash version to be easier to use (scroll-wheel zooming works) and not slower or less capable in any other way that I would have noticed. Is there a good reason that I missed why the flash viewer option should be the primary option? I think that whatever can be done without flash should be done without flash. — Julian H.^✈ 18:49, 15 November 2015 (UTC)

 Done. --Krinkle 21:29, 7 February 2019 (UTC)

Curation SQL

Because no bot performs the task of curation at the moment, a list of files tagged with {{LargeImage}} that are under X Megapixels can be generated, ready for import into a gallery for COM:VFC with the following quarry: sql:

USE commonswiki_p;
SELECT concat("File:",img_name) 
FROM page
INNER JOIN categorylinks ON (cl_to="Large_images") AND page_id=cl_from
JOIN image ON img_name = page_title
WHERE  img_width*img_height<X000000 ;

Note that it false-positives some customized description templates regardless of size when {{LargeImage}} is automatically added regardless of filesize. Storkk (talk) 08:53, 18 May 2016 (UTC)

Does this still work?

Tracked in Phabricator
Task T263141

I get a "No response from server iipsrv.fcgi" alert box error when I click the link on any file that uses it (eg. File:St Pancras Railway Station 2012-06-23.jpg). --Lord Belbury (talk) 14:32, 24 July 2020 (UTC)

This problem still persists. I Phabricator ticket has been opened in September 2020 but there has been no f'up or activity since then. --AFBorchert (talk) 11:55, 2 April 2021 (UTC)

This has now been fixed, see this discussion. --AFBorchert (talk) 15:54, 8 April 2021 (UTC)

Wow, I had no idea it was broken this long. Do we have automated testing available that could be used to alert devs to service failures like this? (like statuscake) --Dschwen (talk) 18:44, 8 April 2021 (UTC)

Blank template while it's down?

Tracked in Phabricator
Task T343796

It has been a while since this is broken.

To avoid people trying to load it while it's down, shall we blank this template? Enhancing999 (talk) 16:08, 3 October 2023 (UTC)

I commented out the mention (Template:LargeImage/en) and link of ZoomViewer (Template:LargeImage/layout). Enhancing999 (talk) 08:39, 4 October 2023 (UTC)

Hi @Enhancing999, the tool should be working again. See phab:T343796#9536611. -- Christoph Jauera (WMDE) (talk) 10:56, 13 February 2024 (UTC)