Last modified: 2014-05-23 16:18:51 UTC
A discussion took place on Wikimedia Commons' Village Pump on 19 May 2009 on how to best respond to the pressure from photographers wanting their names to be credited on article pages (1). It was suggested that instead of (or in addition to) crediting photographers on article pages, we should make our best efforts to keep the copyright EXIF metadata when available. It was understood that the underlying reason for excluding EXIF data from resized pictures and thumbnails until now, was the concern that sometimes cameras add an overwhelmingly heavy amount of EXIF metadata. Our conclusion is that some sort of compromise has to be reached between these two concerns, by including at least some EXIF metatada, if not all of them. A) Perhaps, really small thumbnails like those used in categories, (that means 120px or smaller) might be allowed to remain void of metadata, while larger thumbnails or resized pictures would compulsorily include at least the most useful metadata. B) The most useful metadata which should be included in most resized pictures and thumbnails should be : **ImageDescription, **Copyright, **DateTimeOriginal, **DateTime, **GPSLatitudeRef, **GPSLatitude, **GPSLongitudeRef, **GPSLongitude, **GPSAltitudeRef, **GPSAltitude, **IPTC:Credit, **IPTC:CopyrightNotice, and **IPTC:Byline. C) The message at the bottom of description pages (is it a [[Mediawiki:]] message ? I have not been able to find which) should be reworded with a less ambiguous wording. When a user reads "This file contains additional information (...) ", he remains clueless on whether that means the original file, or the resized 800px preview present on the description page, or both. (1) [[COM:VP#Crediting photographers in article pages]]
Erratum : the link to the discussion is [[:Commons:COM:VP#Crediting photographers in article pages]] .
Again (full URL) : http://commons.wikimedia.org/wiki/COM:VP#Crediting_photographers_in_article_pages
It was also suggested to set UserComment and IPTC:SpecialInstructions to "For more information, see <url of file description page>".
See also bug 3361 ("Image author, description, and copyright data saved in EXIF fields") and bug 657 ("Pull copyright metadata from files on upload") for related issues.
Agreed, whitelisting metadata to pass through to resized output would be handy here... PHP's exif support doesn't appear to include writing metadata, though, so we might need to add new code to copy the info or find a way to do it via ImageMagick. The same would be needed to implement bug 3361, which would add new metadata to files based on info from the wiki.
A similar discussion (same request from flickr users to the flickr developers) took place at http://www.flickr.com/photos/x180/3196541234/
See also bug 19791 (In reply to comment #2) > Again (full URL) : > http://commons.wikimedia.org/wiki/COM:VP#Crediting_photographers_in_article_pages > A patch for this is in bug 19791
*** This bug has been marked as a duplicate of bug 19791 ***
This bug has been marked as "RESOLVED FIXED", as a duplicate of bug 19791 . However, I checked with file http://upload.wikimedia.org/wikipedia/commons/thumb/f/fd/Glorious_First_of_June%2C_1_June_1794_%28Monument_to_the_Republic%29_2010-03-23_05.jpg/640px-Glorious_First_of_June%2C_1_June_1794_%28Monument_to_the_Republic%29_2010-03-23_05.jpg which is a jpg file. And I don't see anything in the Exif of this 640px thumbnail. Perhaps the patch provided at bug 19791 is wonderful for png files, but I am afraid it does not solve the problem for jpg files. May I know which field of the Exif metadata is supposed to be filled ?
(In reply to comment #9) > Perhaps the patch provided at bug 19791 is wonderful for png files, but I am > afraid it does not solve the problem for jpg files. > > May I know which field of the Exif metadata is supposed to be filled ? The patch from bug 19791 added the URl of the file source (http://commons.wikimedia.org/wiki/File:Foo.jpg) into the comment field, not into EXIF. It's a kind of workaround until we can have EXIF in the thumbs. Hint: Works only for thumbs generated from 2009-04-09, not for already cached thumbs. Therefore the current bug should be furthermore keep open.
I uploaded the file, and the corresponding thumbnail at http://upload.wikimedia.org/wikipedia/commons/thumb/f/fd/Glorious_First_of_June%2C_1_June_1794_%28Monument_to_the_Republic%29_2010-03-23_05.jpg/640px-Glorious_First_of_June%2C_1_June_1794_%28Monument_to_the_Republic%29_2010-03-23_05.jpg was generated in 2010. However I don't see anything in the "comment" field either. My picture viewing software is [[IrfanView]], and I checked the "comment" button close to the "IPTC info" button, at the bottom in the "image information" menu. I aslo have the Fxlf extension installed on Firefox, and that detects nothing.
(In reply to comment #11) > I uploaded the file, and the corresponding thumbnail at > > http://upload.wikimedia.org/wikipedia/commons/thumb/f/fd/Glorious_First_of_June%2C_1_June_1794_%28Monument_to_the_Republic%29_2010-03-23_05.jpg/640px-Glorious_First_of_June%2C_1_June_1794_%28Monument_to_the_Republic%29_2010-03-23_05.jpg > > was generated in 2010. However I don't see anything in the "comment" field > either. > > My picture viewing software is [[IrfanView]], and I checked the "comment" > button close to the "IPTC info" button, at the bottom in the "image > information" menu. > > I aslo have the Fxlf extension installed on Firefox, and that detects nothing. As I wrote: Works only for thumbs generated since 2009-04-09, not for already cached thumbs. Yours was generated 2010-03-25.
Sorry, perhaps my English reading capacity is not perfect, but according to Merriam Webster dictionary, http://www.merriam-webster.com/dictionary/since , "since" means "from a definite past time until now" and I would have thought that when you say "since 2009-04-09" you mean between April 2009 and now. Now we are in April 2010 aren't we ? My file was uploaded in March 2010. Isn't March 2010 somewhere between April 2009 and April 2010 ? Is my file too old or too new ? Conversely, could you provide another example of existing file whose thumbnails are filled with the new comment ?
I just tried it on http://upload.wikimedia.org/wikipedia/commons/thumb/4/46/Torbj%C3%B8rn_R%C3%B8e_Isaksen_-_2010-04-10_at_11-08-52_(1).jpg/120px-Torbj%C3%B8rn_R%C3%B8e_Isaksen_-_2010-04-10_at_11-08-52_(1).jpg Here's the comment field according to exiftool: Comment: File source: http://commons.wikimedia.org/wiki/File:TorbjJPEG3%B8rn_RJPEG3%B8e_Isaksen_-_2010-04-10_at_11-08-52_(1).jpg Thus it does put the url in it, on the downside it seems to totally screw over non-ascii characters, replacing %C with JPEG. Is %C replaced with the file type somewhere along the line?
apparently so. http://www.imagemagick.org/script/escape.php?ImageMagick=i766ho1om315scce8eh75efjc6
(In reply to comment #13) > Sorry, perhaps my English reading capacity is not perfect, but according to > Merriam Webster dictionary, http://www.merriam-webster.com/dictionary/since , > "since" means "from a definite past time until now" and I would have thought > that when you say "since 2009-04-09" you mean between April 2009 and now. Now > we are in April 2010 aren't we ? My file was uploaded in March 2010. Isn't > March 2010 somewhere between April 2009 and April 2010 ? My apologies. I wrote the wrong year :-( Please read it as "2010-04-09". On this date (yesterday) the software on the WMF servers were updated. And all thumbs generated from this date on have the comment.
for the imagemagick issue, i have opened a new bug 23148
In reply to comment #16 : you're welcome. I think this new comment metadata is a great step forward. Too bad, though, that this metadata is less popular than Exif or IPTC (the Exif viewer add-on in Firefox can't display it https://addons.mozilla.org/fr/firefox/addon/3905 ).
> >C) The message at the bottom of description pages (is it a [[Mediawiki:]] >message ? I have not been able to find which) should be reworded with a less >ambiguous wording. When a user reads "This file contains additional information >(...) ", he remains clueless on whether that means the original file, or the >resized 800px preview present on the description page, or both. This part of the original bug has been ignored. Do you have an alternative sentence that would be more clear - its a very easy fix to change the message if one has an alternative to change it to. ----- The comment feature seems recently to have stopped working. I filed bug 42368 for that.
Bumping! I agree with comment 18. The source in the comment is good (though I had never noticed it… neither Firefox nor Nautilus mentionned it − I had to open the file in GIMP), but it does not replace keeping some EXIF (the ones listed in comment 1 seem reasonable).
I just had a similar request from a museum who are planning a large image donation where they had spent a significant effort making sure that the metadata was also included in the exif tags. For generating their own thumbnails they use a script which first generates the jpg thumbnail with imagemagick and then calls ExifTool to copy the exif data across with exiftool –all= -tagsfromfile SOURCE.TIF –all:all –overwrite_original TARGET.JPG Would something similar be doable here? We might not want to copy all of the fields (or for all sizes of thumbnails) but the ones mentioned above would be good.
(In reply to comment #21) > I just had a similar request from a museum who are planning a large image > donation where they had spent a significant effort making sure that the > metadata was also included in the exif tags. > > For generating their own thumbnails they use a script which first generates > the > jpg thumbnail with imagemagick and then calls ExifTool to copy the exif data > across with > exiftool –all= -tagsfromfile SOURCE.TIF –all:all –overwrite_original > TARGET.JPG > > Would something similar be doable here? We might not want to copy all of the > fields (or for all sizes of thumbnails) but the ones mentioned above would be > good. post processing with either exiftool or exiv2 is a potential solution to this bug (And probably the best way forward. I don't think we want to write our own metadata writer). Would require making sure such a program is available on the server (which might already be the case). ImageMagick also has -caption and -title options we can use without resorting to using another binary. It should probably be investigated what sort of metadata these options produce in the image (The docs are very vague, but testing that should be easy). -label Should also be investigated.
