Last modified: 2014-05-28 06:21:59 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T67475, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 65475 - Resized raster image does not succeed metadata of the original file
Resized raster image does not succeed metadata of the original file
Status: NEW
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
unspecified
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks: 41371
  Show dependency treegraph
 
Reported: 2014-05-19 09:23 UTC by Thomash Lee
Modified: 2014-05-28 06:21 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Thomash Lee 2014-05-19 09:23:07 UTC
When the image file is resized or rendered to a raster image (from vector source) by wiki software, the metadata generally does not get carried over even if the original file contains any. While I understand there is some major argument of how metadata should be added on Wikimedia platform, I think we at least should transfer the original metadata to the resized raster render instead of leaving the metadata fields totally empty.

After the change of Wikimedia that the file description page no longer provides original size preview if the width of the original raster image is too long, the down-scaled version is always the one being shown, which means readers are more likely to have downloaded the metadata-less version because the "original file" link isn't that obvious to the user that it is actually different than the preview image in many ways.
Comment 1 Andre Klapper 2014-05-20 09:14:41 UTC
Thanks for taking the time to report this!

What would be steps to follow if I wanted to reproduce? Any testcase?
Comment 2 Thomash Lee 2014-05-20 16:06:50 UTC
(In reply to Andre Klapper from comment #1)
> Thanks for taking the time to report this!
> 
> What would be steps to follow if I wanted to reproduce? Any testcase?

Steps to reproduce:
1) Access the description page of any oversized PNG file with metadata at Commons like File:FutureMTRNetworkAfterMerger.png
2) Download both the original file and the resized preview.
3) Use any application capable of reading Exif/XMP like ExifTool to read both version of the image.
4) Compare the metadata between the 2 files
5) The resized file contains fewer metadata than the original file.

Expected: resized image should contain all metadata from the original file.
Comment 3 Bawolff (Brian Wolff) 2014-05-26 16:40:34 UTC
I dont think thats the expected result. Lots of useless crap in the metadata.

However there are some fields which would be nice to copy over like artist

We also add a field to thumbnailed images to link to the source (but possibly not with vips, so not for really big pngs. Probably also not for svgs).

Im confused about if you are complaining about svgs (vector) images specificly or all files. You talk about vector formats in comment 0 but pngs (raster) in comment 2.
Comment 4 Bawolff (Brian Wolff) 2014-05-26 17:10:15 UTC
> 
> After the change of Wikimedia that the file description page no longer
> provides original size preview if the width of the original raster image is
> too long, the down-scaled version is always the one being shown.

That's incorrect, the situation is not new. This is the way its always been. We show the original image asset where possible, but we're not display huge files inline on the image description page. Some of those original image files are hundreds of megabytes big. There's even a tiff file which is 1 GB big.
Comment 5 Thomash Lee 2014-05-28 06:21:59 UTC
There is already the discussion 17503 about generating metadata by checking licensing/author info or information template from the media description page, but the progress is disappointingly slow. Rubbish or not, it's still better than containing no metadata at all in the resized file. Please prove that metadata is ever the culprit of oversized media file.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links