Extension talk:MultimediaViewer

Jump to navigation Jump to search

About this board

Lordhelpus (talkcontribs)

Does MultimediaViewer support WebP images? If so, what is the process to enable support? In my current implementation of MultimediaViewer WebP images are not displayed, and are skipped in the "Show Next Image"/"Show Previous Image" interface as seen in this example ( blazblue.wiki/index.php?search=Alternative+Dark+War+Icon&title=Special%3ASearch&profile=images&fulltext=1 )

Reply to "WebP Support"
Maiden taiwan (talkcontribs)

Does MultimediaViewer log detailed error information anywhere? I am trying to debug a problem where MultimediaViewer can't display any images. It displays a black error screen,

"Sorry, the file cannot be displayed. There seems to be a technical issue. You can retry if it persists. Error: Unknown_operation."

When this error is displayed, the usual buttons for "Download this file" and "Share and embed this file" link to https://name-of-wiki.com/w/null.

When MultimediaViewer is disabled, images display perfectly as File:NameOfImage and Media:NameOfImage.

This is MediaWiki 1.35.0. Thanks for any insights.

Maiden taiwan (talkcontribs)

The apache error log shows no error message.

Maiden taiwan (talkcontribs)

Upgraded to MW 1.35.1. No change.

Is this extension still maintained? Is this the right place to get help?

Reply to "Error: Unknown_operation"

Does MultimediaViewer work on private wiki?

11
Seanchen (talkcontribs)
Tgr (WMF) (talkcontribs)

It should work fine, If it doesn't, please file a bug with the details.

Seanchen (talkcontribs)

@Tgr thanks for the quick reply!

Here are some more details about this issue, could you help take a look to see if you have any clue.

I am working on the MediaWiki version 1.26.2 and download MultimediaViewer at version 0.3.0.

I did set up the img_auth.php to protect the access to media files. As long as user logged in, user could view the media file without problem. For example: http://dev.example.com/wiki/img_auth.php/6/69/Denmark.png. But when logged in user try to view the same image on MultimediaViewer, we got this massage:

There seems to be a technical issue. You can retry or report the issue if it persists. Error: could not load image from http://dev.example.com/wiki/img_auth.php/6/69/Denmark.png

And I could see failed to load resource error on Chrome console:

Failed to load resource: the server responded with a status of 403 (Forbidden)

It might have something to do with my Ngnix's configuration. I will double check...

Is there any configuration on MultimediaViewer related to this?

If you still think it is a issue, I will file a bug for it.

thanks a lot,

Sean

Tgr (WMF) (talkcontribs)

Disabling $wgMediaViewerUseThumbnailGuessing might help, but it should not be necessary, and it's the default anyway.

Might be a problem with how MediaViewer uses CORS. Could you try to edit resources/mmv/provider/mmv.provider.Image.js to change imagePreloadingSupported to always return false, and see if that fixes it?

Nelmonk (talkcontribs)

I had the same issue as @Seanchen, and set to false as follows (which solved the problem):


if ( !this.cache[ cacheKey ] ) {

if ( this.imagePreloadingSupported() ) {

rawGet = provider.rawGet.bind( provider, url, false );

this.cache[ cacheKey ] = this.performance.record( 'image', url, extraStatsDeferred ).then( rawGet, rawGet );

} else {

start = ( new Date() ).getTime();

this.cache[ cacheKey ] = this.rawGet( url );

this.cache[ cacheKey ].always( function () {

provider.performance.recordEntry( 'image', ( new Date() ).getTime() - start, url, undefined, extraStatsDeferred );

} );

Seanchen (talkcontribs)

disabling $wgMediaViewerUseThumbnailGuessing does help.

set imagePreloadingSupported to false fixed it!

Also I did test on Firefox. Everything is working on Firefox without any code change.

it seems like Chrome and Firefox handle CORS slightly different!

let me know if you want me file a bug for this.

thanks,

Sean

Subfader (talkcontribs)

Thanks. Had the same problem. Incorrect CORS error on working 404 handler (images are on subdomain).

Returning imagePreloadingSupported false fixed it. $wgMediaViewerUseThumbnailGuessing could stay true.

MW 1.25 --Subfader (talk) 11:39, 4 November 2017 (UTC)

Tgr (WMF) (talkcontribs)

Please do. The bug would probably affect Firefox too, if your images were on a separate domain. MV sets cors="anonymous" on the images for various hacky reasons, for private wikis that should probably be cors="use-credentials" instead.

Seanchen (talkcontribs)
80.128.155.247 (talkcontribs)

This is still a relevant help for the latest LTS-MediaWiki (1.31.2).

Thanks for this workaround. Setting <pre>imagePreloadungSupported</pre> to <pre>false</pre> helped a lot and fixed my problem.

Jesperjoachims (talkcontribs)

Hi there,

Yes it also fixed my problem (MediaWiki-1.34.1). Thanks for that!

Reply to "Does MultimediaViewer work on private wiki?"

missing /images/ tag in download links

1
Oierla1 (talkcontribs)

Recently added this in .htaccess file so that all the visits would go to https instead of http

RewriteBase /

RewriteCond %{SERVER_PORT} 80

RewriteRule ^(.*)$ https ://www.webname.com/$1 [R,L]


Since then the download and full size links in MultimediaViewer are messed up. I keep getting these links:

http: //www.webname.com/images/f/f8/filename.jpg?download

and the system changes those links to these, with the /images/ tag missing, so nothing shows up

https: //www.webname.com/f/f8/filename.jpg?download

Any way to solve this please?

Reply to "missing /images/ tag in download links"

Link to an image in subdirectory

1
Ievgen D (talkcontribs)

How are file links passed to MultimediaViewer?

I'm going to use private wiki as photo library. Pictures can be taken from different cameras, so file names across the whole library may be not unique. Storing them in different directories is the only acceptable solution. Renaming is not considered due to amount of files. Also my pictures and pictures shared with me by others should be in different directories. So my decision is to copy files to images/Photo/XXXX/ subdirectory, where XXXX is a sequence number, then to run modified maintenance/importImages.php script to create corresponding DB records. Also I had to modify some scripts to replace '/' with '%2F' for correct processing in links. Now everything works fine except MultimediaViewer. The latter also works fine from a file page via 'Open in MultimediaViewer' button, but not from a standard article page. Button on a file page generates link e.g. wiki/index.php/File:Photo/00003/DSC_3201.JPG#/media/File:Photo%2F00003%2FDSC_3201.JPG, which is correct. When I click on thumbnail on article page the link generated gets wrong: wiki/index.php/Photo/00003/3201#/media/File:DSC_3201.JPG, missing 'Photo%2F00003%2F' part of subfolder and causing file not found (404) error.

I can't find out how this link is generated. I tried to review source code of both page types but with no result. I can't see neither 'Open in MultimediaViewer' button in the source of a file page nor incorrect links or '#/media' keyword in the source of an article page. Also I tried to search '#/media' substring in contents of all files in wiki/ subdirectories, found 3 files but without explicit correlation with the url passed (or generated).

Could you please help?

Reply to "Link to an image in subdirectory"
Amire80 (talkcontribs)
Neil Shah-Quinn (WMF) (talkcontribs)

Hey @Amire80, good question! When a user opens an image in MultimediaViewer, the browser makes a request to upload.wikimedia.org for a larger image and some requests to the Action API for image metadata. According to the pageview definition, none of those requests count as pageviews. In particular, they fail the test of their URLs containing "a 'content' directory (mainly /wiki/, but also /zh-hant/ or another language variant directory)".

On the other hand, the request to upload.wikimedia.org would be counted in the Mediacounts dataset. That dataset has been available internally for some time, and the Analytics team has just started doing public releases.

Amire80 (talkcontribs)

Thanks!

The reason I'm asking is that a GLAM institution asked me how can they check how many of the images they upload are actually viewed, and they are interested in both file description page views and Multimedia Viewer views, which makes a lot of sense.

Do you have an idea where can they get it? The mediacounts page, to which you linked l, doesn't make it entirely clear where can one get it publicly, but maybe I'm missing something.

I'd actually say that it should be included in the same dataset as the usual pageviews, perhaps with some properties that indicate a different medium, because most people who upload images and want to know how often are they used, probably want to get info about all pageviews.

Neil Shah-Quinn (WMF) (talkcontribs)

Does the availability section of the mediacounts page answer your question? It says the dataset is publicly available as daily TSV dumps, and privately available in Hive. Unfortunately, that means it will be very hard for that institution to get an answer to their question; I think Analytics is working on a public API which will make it possible to build something similar to the pageviews analysis tool, but I don't know when it will arrive.

Amire80 (talkcontribs)

OK, that's a beginning :)

Thanks!

Neil Shah-Quinn (WMF) (talkcontribs)

You're welcome!

And if you're just concerned about giving this institution a one-time answer, you could fairly easily run a Hive query and give them the results; let me know if you need any advice about that. But if you're more concerned about the general issue of GLAMs having access to media view data, of course that wouldn't scale.

Reply to "Metrics"

Thumbnail guessing on REL1_31

1
Kghbln (talkcontribs)

After upgading from REL1_27 to REL1_31 I realized that $wgMediaViewerUseThumbnailGuessing = true; does no longer work. The other setup especially for the 404 handler did not change. Either the smallest resolution is picked for up-scaling of the image resulting in a very pixeled view or alternatively the image is not being scaled at all resulting in a tiny thumb in the view. After changing the setting back to the default false everything works again. This happened for several wikis. On REL1_27 everything was cool.

Reply to "Thumbnail guessing on REL1_31"
Mjb294 (talkcontribs)

Is it possible to use this extension alongside the ImageMap extension? I would love if you could click on the thumbnail to bring up MultimediaViewer and still have the option of clicking on different parts of the image which have been mapped to link to different pages. If this isn't possible at all does anyone know of any other extensions which could do something similar?

DSquirrelGM (talkcontribs)

There's no real need to use an extension for this, since you can embed absolute-positioned divs or spans along with the image itself inside a relative-positioned div to define linked areas. Specifically using normal link syntax with the positioned structures inside them where you'd normally have the link text.

Tacsipacsi (talkcontribs)

This solution has two problems. First, absolute positioning is awkward and far less flexible than imagemaps (imagemaps can have links of virtually any shape, while absolute positioning is even more awkward if you want to use any shape other than rectangles, if possible at all). Second, they don’t work with MultimediaViewer, either.

Reply to "ImageMap"
Summary by 机智的小鱼君

It’s because of browser’s cache.

机智的小鱼君 (talkcontribs)

I am changing my site to https protocol.Then MediaViewer crashed,and display “could not load image from http://foo.bar”.

That’s strange.Can somebody teach me how to solve this?($wgServer has been modified)

机智的小鱼君 (talkcontribs)
机智的小鱼君 (talkcontribs)

Sorry! That’s Cache !! All things right !!!

Jens Lallensack (talkcontribs)

Dear all – I'm writing on behalf of the WikiProject Dinosaurs in the English Wikipedia. We were intrigued to find out the Media Player now supports stl 3D files. For our topic (dinosaurs), we are describing complex bone morphologies on a regular basis. 3D models would be a very significant improvement to our articles, making it much easier for readers to comprehend what the article text tries to describe. We encountered one problem with the starting position though, and furthermore would like to file a wish.

1) The starting position in which the model is shown (both in the thumbnail and in the 3D window) is very different from that of external viewers (tested with MeshLab). Because of this, we are unable to rotate the objects into their proper orientation (e.g., side view). When I change orientation using MeshLab and re-upload the file, the orientation shown by MediaViewer changes as well, but just in a different, and seemingly arbitrary direction.

2) It would be of even more value to be able to upload models with vertex colors or, better, textures, which are possible when using the format PLY. Without color, it is very difficult for readers to recognize the bones shown. PLY would require two files for one model: A mesh file and a texture file (usually .jpg). While .stl files are the standard format for, e.g., CT data, PLY is commonly used for photogrammetry models, which are based on photos and thus naturally will include texture. Photogrammetry is an easy and cheap method that (in contrast to CT data) can be easily employed by Wikipedia authors themselves to build models for Wikipedia, provided they have access to the objects. I myself already have a bunch of self-made models, all including texture files, that would be of great use for our articles. For these reasons, we think that the support of textured PLY files would be an addition well worth the effort.

Files tested:

File:Massospondylus_skull_BP-1-5241_3D_scan.stl File:Aquilops cranium scan.stl

Reply to "3D view: bug and wishes"