Commons talk:Exif

A mentioning on how to add meta data to other formats than jpg would also be useful, specifically for people creating complex svg/png diagrams. /Lokal_Profil 13:35, 16 January 2007 (UTC)

Audio and Video metadata

How about the metadata in OGG files? There are lots of media files without correct metadata. --Fajro (talk) 17:28, 14 October 2008 (UTC)

vanity?

I think somebody wrote this who is not an artist himself. Did not Michelangelo sign his work, too? Is it not the basic right of a proud artist to sign his or her work? Who steps behind his own work to be neutral? Any artist is biased about his own work - if he or she is not, then they are not proud of their achievement and thus this is probably not the best they could do... And - just to state it here also - I think the exif-solution is not practicable for normal users, because I could not figure it out myself. I think any author who uploads his work with a free licence to commons is giving enough for free already, he should at least have the right to find his or her name in the picture. sidonius (talk) 23:58, 14 February 2009 (UTC)

The point of vanity obfuscates a larger issue; neutrality is not necessarily impacted by indicating the source of an image. Furthermore, embedded meta data is lost on general users who do not have a convenient means of reading this information.

Recommend a serious re-write of the project page. "Reusage of images with these signatures for example for printing purpose gets limited by personal tags like at collage posters and in books" is almost unreadable, not to mention puerile.

Much of the prose surely needs a rewrite. No need to be unpleasant about it; my guess is the authors of the page are well educated in another language than English, so we native speakers should help smooth it properly. The urgency is not great, as it is merely an internal document for contributors to read; not a Wikipedia page for the general public. Wikipedia article authors show our vanity or pride by signing our work in the edit record and talk page, and similarly for our pictures. In addition, I use my initials in the filename. None of this information is ordinarily seen by Wikipedia readers, and that's how it should be. Some readers are particularly studious, and will learn to look at the back pages, for example at the picture description. They will find our name. If our pride needs more than that much food, we are feeding it at the wrong Web site and should seek a vanity publisher. Jim.henderson (talk) 06:02, 3 April 2010 (UTC)

I do not agree. For some it may a matter of pride; for others, it is a matter of ensuring that the source remains readily perceived. This has been made necessary due to rampant plagiarism. One may have the lofty goals of doing things "correctly," but this is in effect akin to wearing blinders to the reality of the Internet.

I'm afraid I have aleady contributed too much to this misplaced discussion. If we were discussing questions of what things ought to be in EXIF and why, it might belong here, but it seems to be more about why Commons:Watermarks should be used and that's where, if anywhere, it would seem to belong. Jim.henderson (talk) 13:38, 4 May 2010 (UTC)

Proposal to include EXIF metadata in resized pictures (bugzilla)

• https://bugzilla.wikimedia.org/show_bug.cgi?id=18871

Teofilo (talk) 20:16, 28 May 2009 (UTC)

The URL of the picture on commons is now included in the "jpeg comment" metadata, in thumbnails generated after 2010-04-09. Teofilo (talk) 15:32, 11 April 2010 (UTC)

Tools showing EXIF metadata on webpages (Firefox add-ons)

• https://addons.mozilla.org/fr/firefox/addon/5673
• https://addons.mozilla.org/fr/firefox/addon/3905

Teofilo (talk) 15:28, 11 April 2010 (UTC)

Title

May I move this a new title (e.g. "Commons:EXIF"). It already redirects here. This could include what I recently learned at VP (COM:VP#EXIF searching) -- User:Docu at 17:21, 26 September 2009 (UTC)

Related GSoC project proposal

There is one at mw:User:Bawolff/GSoC2010 titled "Improve metadata support for uploaded media in mediawiki by displaying embedded IPTC and XMP metadata". Interesting! -- User:Docu at 12:21, 9 April 2010 (UTC)

What is GSoC ? Teofilo (talk) 15:26, 11 April 2010 (UTC)

GSoC = Google summer of code. Basically Google pays computer science students ~$5000 to make improvements to various open source projects (including mediawiki) over the summer. See mw:Summer of Code 2010 and w:Google summer of code for more information. For my project, I plan to improve mediawiki's support for image metadata as docu mentioned so that it has better exif support, as well as iptc and xmp hopefully. Bawolff (talk) 23:16, 12 July 2010 (UTC)

Canon link in Metadata table

When a photo is taken with a Canon camera, the link in the metadata "Camera manufacturer" field goes to Canon which is a disambiguation page. Is it possible to have the links point directly to Canon (company)? - Kollision (talk) 04:10, 4 February 2011 (UTC)

The link is defined in MediaWiki:Exif-make-value and Template:Exif-make-value it calls. Parser functions based on $1 in there don't seem to work. You'd need to file a feature request/bug in Bugzilla: to have that fixed. It looks like it worked sometimes in the past.

I had done one for categorization through that (see Bugzilla:21795) --  Docu  at 07:48, 4 February 2011 (UTC)

Work around to the parser func not working issue is feed it to a helper template (aka do {{foo|$1}}) and then process the value inside the helper template. (I'm basing this statement off of n:MediaWiki_talk:Movepage-moved#New_syntax_and_tweaks. I haven't tested any of that recently). Bawolff (talk) 12:57, 15 June 2012 (UTC)

Seconds

I would like also seconds in the EXIF metadata listing at the file page. A photographer can walk ca. 100 meters within 1 minute. It is too rough for analysis of location or order of a sequence of photographs. --ŠJů (talk) 20:04, 5 December 2011 (UTC)

At the moment it just uses the default date formatting in your prefs (which strips seconds on en). Perhaps we should include the "2012-05-21T18:31:37" format of the date as a tooltip. Note if you change your preferred date format in special:preferences to one that includes seconds, you will see seconds on the image description page. You can also retrieve the full timestamp (with seconds) via the API. Bawolff (talk) 13:03, 15 June 2012 (UTC)

Privacy

Are serial numbers stripped from EXIF data? This has been brought up as a privacy issue on another talk page. I made a sample image here that we are trying to test with. File:EXIF Canon 500D .JPG--Canoe1967 (talk) 17:38, 10 June 2012 (UTC)

No. No privacy related data is stripped (Also of concern is GPS data (bugzilla:20326, and people accidentally listing their full name in author field when they do not intend to). Bawolff (talk) 12:58, 15 June 2012 (UTC)

Thanks. I read both and it does seem to be an issue with some. Two other questions arose. Is it technically possible to have only certain data removed as an option on upload? And do we want to make it too easy to remove any or all data because much of it is very useful for the file? Meaning no EXIF data on all files would really suck. A warning template to all the upload software was also mentioned and whether to add a link to decent EXIF editors to the warnings.--Canoe1967 (talk) 20:41, 15 June 2012 (UTC)

Yes its possible, but it involves someone putting the work in to actually do it (which is a bit more than a one line change). MediaWiki's current exif support is read only, so someone would have to either make an exif writing program, or we could shell out to exiftool. I think we would want to provide the option to remove GPS data as a start (Or even an option to make GPS data "vauge", say to an accuracy of 100km instead of an accuracy of 10m). Other identifying fields are very rare (like name of author), and usually only there if someone specificly put them there. Maybe we should ask about removing serial number fields as well, since that's really of no value to us. I see no reason to remove fields like f-value or shutter speed. Bawolff (talk) 20:01, 16 June 2012 (UTC)

That sounds too much like un-needed work. We may just end up with a warning template then. I have never heard of anyone wanting to have a speedy delete after upload for GPS, ser.# etc. I am willing to reslove this section for now, since the main questions were answered. I don't know which forum the template add-on or exiftools should be discussed in. Possibly this one, but I am not interested in starting it. Thank you very much for your help, Bawolff.

This section is resolved and can be archived. If you disagree, replace this template with your comment. --Canoe1967 (talk) 21:27, 16 June 2012 (UTC)

I was actually involved once in a request relating to "oversighting" someone's name out of exif, so occasionally stuff does get posted that people don't want, but i'm pretty sure its very rare. Glad I could help. Bawolff (talk) 16:08, 18 June 2012 (UTC)

I need to request to have some metadata removed, do you know where I should make such a request?--Craigboy (talk) 08:59, 3 March 2014 (UTC)

If you speak about metadata violationg your privacy, please see Commons:Oversight, last section for the email address. Raymond 11:15, 3 March 2014 (UTC)

Qqq

Just as a note most of the things MediaWiki extracts, and how it extracts them are documented as Qqq messages (ex: translatewiki:MediaWiki:Exif-artist/qqq). I feel like that may be useful to someone at some point, but wasn't sure if it was appropriate information for this page. Bawolff (talk) 13:41, 15 June 2012 (UTC)

I see no reason we can't add it to the article. You could either copy/paste the text, link it, or both. I couldn't understand most of it. Translate to more layman terms?--Canoe1967 (talk) 16:20, 14 July 2012 (UTC)

Well I was the one who wrote it in the first place, so my fault its overly technical ;). Bawolff (talk) 20:26, 23 July 2012 (UTC)

SVG title and desc

Currently in the presentation on the preview page of so called metadata taken from title and desc of SVG images, the title is described as 'Short title' and desc is described as 'Image title'. This is wrong. The title of the root svg element is simply the title of the SVG document. If an SVG has no such element, it has no title - respectively the title of the topmost element with a title is considered as a document title, what may matter for example, if there is a language switch in the document. Whether the title is short or not is the problem of the author. The desc element of the root svg element is simply a description for the complete SVG document and no 'Image title'. This can be used as alternative text for the image, but may contain more information about the usage as well, especially if the document is interactive.

Further - the data for width and height are wrong, if the root svg element contains no such attributes, respectively the units are not pixels (for example percentage or cm, mm etc).

Can anybody fix these bugs? Doktorchen (talk) 12:08, 14 August 2012 (UTC)

We are currently considering the svg desc tag to describe the same sort of information as the Exif ImageDescription field does in JPEG files or the dublin core "description" field does in XMP metadata. To clarify, do you think these fields represent different things, and should use different labels, or do you think they both represent similar information, and both their labels should be changed. Similarly we are treating the svg <title> to be similar to the information contained in iptc-iim's 2:05 object name property for jpeg images, as well as similar to the dublin core "title" attribute in XMP, and the PNG "title" textual chunk. Again, to clarify, do you think these represent different things and should have different labels, or do you think they all represent the same thing, and are all mislabeled.

As for the Width/Height. I assume you mean in the line directly under the image (since the metadata box currently doesn't list units). We convert whatever unit is specified into pixels (Pixels is what we need to deal with, as we need to render the image in a fixed size using pixels.) (For relative units, we consider 1em to 16px and 1ex to 12px on the basis we need an absolute measurement of some sort at the end of the day).

The width/height in the metadata box should perhaps use the original units. Bawolff (talk) 14:22, 16 August 2012 (UTC)

p.s. In regards to lang switches for the image description - I would love to support that, but at the moment we don't (Currently we do support slightly similar features in PNG images, and in XMP metadata). p.s. Have you seen the recent efforts involving support for translating svgs inside mediawiki File:TranslateSvg.ogv (off topic to the current conversation, but thought you might be interested). Bawolff (talk) 14:52, 16 August 2012 (UTC)

I never read a specification of JFIF/JPEG EXIF data, but DCMI I know. For example http://purl.org/dc/terms/title and http://purl.org/dc/terms/description

In SVG it is not defined in detail, what the content of title or desc is and DCMI does not define this as well in detail. But apart from the multi-language problem the title element with the root svg element as direct parent is intended to describe the same entity than the DCMI title property or element. Usually one will set the same content for both, if RDF/DCMI is used in metadata about such an SVG document. (Note that in SVG it is allowed to use other XML formats to structure the content of title and desc - but what is not recommended for the title of the root svg element). Therefore I think, this entity can be described both for DCMI and SVG as 'title' and has the same meaning.

I think, as a first approximation it is ok to use 'description' as well for what the desc element of the root svg may contain. Because DCMI does not describe in Detail, what the property or element 'description' should contain, it looks like a good choice to call all these entities 'description'. If EXIF has something like 'ImageDescription' it sounds reasonable, that it means the same as the DCMI description belonging to the RDF construction 'about' such an image (but I never read something about JFIF/JPEG EXIF data, just guessing here).

Because in SVG almost every element can have title and desc, it is important to get them for the root svg. Only these can be interpreted to represent title and description of the whole SVG document. The complete set of all title and desc and other text can be used 'somehow' to generate a text alternative of the image. Usually it is a good idea for document authors to create the document in such a way, that already root svg elements title and desc together result in a meaningful text alternative. If this appears on the preview page with correct naming 'title' and 'description', this might help authors to improve the quality of their SVG documents (what is of course very optimistic ;o)

width and height in the metadata section - obviously if it describes the SVG document and not the PNG preview on top, it should mention what is written in the SVG document and not what applies (maybe) for the PNG preview. By the way - if the SVG documents root svg element has not width or height attribute, the default for the not noted attribute is '100%' and not '512'? (or less). For em, ex, cm etc one needs only a conversion to px for the PNG preview, else the result of such a conversion is not meaningful for the SVG document itself and represents no metadata or information about the SVG document at all, only maybe about the generated PNG preview.

title and desc in multiple languages - well this was discussed in the W3C SVG mailing list and I contributed to this discussion. Up to now there is no instruction, how to create or extract such SVG documents. Obviously one can use the switch element to select a language, but typical viewers will not extract the information correctly, if this is done for title and desc of the root svg. Technically the title and desc belong to the switch and not to the root svg, if this is done. Because there is no text about this in current SVG recommendations, one cannot expect, that the viewers do is as it would be useful. But of course, it there are people starting new discussions in the W3C SVG mailing list, there is a good chance, that something is done in SVG 2 about this ;o)

Except for root svgs title and desc, one can simply write text in multiple languages directly in one file, using the switch element to chose the right version for the reader. This means, you need only one file for all languages, not for each language one file.

Example: interactive map - this contains the result from the previous discussion in the W3C SVG mailing list as well, additionally RDFa attributes and role to help to address the information correctly - of course nevertheless the metadata on the preview page here does not manage to extract this information as other viewers too - the usual problem with RDF(a) and metadata ;o)

Doktorchen (talk) 16:26, 16 August 2012 (UTC)

I believe we only extract the root title/desc for this purpose. I've submitted some code to use the svg specified units in the metadata table (while still keeping the px units in the subtitle under the displayed image on the description page). If no one finds any issues with the code, it will probably appear on commons in the next 2-3 weeks. As for the multilanguage thing - I would like to wait until that makes it to an official spec before implementing support for such a feature. Slightly off topic, but since you said you're familar with DCMI - what does the "scope" property mean, I've never been able to find an explanation I understood? Bawolff (talk) 21:13, 22 August 2012 (UTC)

Ok - the multilanguage example only shows, that one will not necessarily get everything with a simple approach, as one can imagine, that several author will provide more relevant metadata with RDF in the metadata element. Obviously this is far more complex to extract as well, because the script or program may have to know lots of vocabluraries from different namespaces to get (completely), what the author means ;o) My intention with this comment was only to get the wording here corrected, not to start a larger project to interprete metadata in SVG or RDF in general ;o) Without understanding, one could only provide pairs of predicate/property and object/value, but even this can get more complex, if the content of elements are not only literals but other elements. And one has to find the subject - often provided with the attribute 'about' from RDF - possibly this points only to a fragment or even to another document ;o)

About 'scope' - from which namespace did you get that? I cannot find it on DCMI (elements or terms, link see above) - maybe another namespace? Or did you mean 'subject' or 'type'? At least the wording sounds similar.

Doktorchen (talk) 13:04, 23 August 2012 (UTC)

In regards to "scope". I'm not sure why I called it that, but I actually meant "coverage". However googling, the definition doesn't seem all that confusing. The width and height in the metadata box (not the part under the image) should now use the svg's units for width/height. Bawolff (talk) 22:01, 26 October 2012 (UTC)

Commons:Metadata redirects here

But I think there is more to medadata than EXIF (for example, do DJVu have EXIF?). I think we should have a separate (disambig) page, for now it could also link to Commons:Machine-readable data, instead of a redirect here. --Piotr Konieczny aka Prokonsul Piotrus ^Talk 21:40, 13 September 2012 (UTC)

•  Agree --Jarekt (talk) 12:40, 17 September 2012 (UTC)
  • I've created the disambig. --Piotr Konieczny aka Prokonsul Piotrus ^Talk 20:52, 20 September 2012 (UTC)
• Note, this page is already about more than EXIF since I added a bit about metadata stuff that MediaWiki can extract which is not EXIF data. DjVu files can have metadata, which is similar to the native metadata of PDF files, as well as supporting XMP. However, MediaWiki at the moment does not support displaying such information for DjVu files. Bawolff (talk) 21:49, 26 October 2012 (UTC)

EXIF vs. Exif

The Japan Electronics and Information Technology Industries Association standards document for Exchangeable image file format (JEITA CP-3451) doesn't use "EXIF" anywhere; it consistently renders it as "Exif". The article should be moved to "Exif" and all references to "EXIF" should be changed to "Exif". I know it's quirky and counter-intuitive; I wouldn't have done it that way, but that's the way the official standard is written. — Quicksilver^@ 18:41, 23 November 2012 (UTC)

Watermarks

In the article it says: "As in books, we always have the copyright information in the image caption or at the end of the book and thus a signature in the image would produce redundancy in page layout and be unfair compared to the article author's credit." While it is true that watermarks are very likely to keep re-users from using such pictures, they actually prevent people from stealing your pictures. Not only do re-users like magazines or newspapers normally remove exif information, they also ignore it in the first place. If pictures are credited at all, they are only credited to "Wikipedia". People simply don't know about Wikipedia's copyright rules, or chose to ignore them. That's why I never would upload one of my pictures to Wikipedia Commons, and anybody who does should know that they help to destroy photography as a viable job because it makes people think they can exploit other's work for free. Vicki Reitta (talk) 08:54, 9 September 2013 (UTC)

Visible watermarks can be also be easily removed or cropped, just like author and license information in EXIF. I agree that reusers often ignore license requirements of our images. That is unfortunate. As someone who uploads a lot of images to Commons I realize that by doing so I might be "destroy[ing] photography as a viable job". That also is quite unfortunate, but I guess it is also true if one uploads to flickr, panoramio, gettyimages, etc. since people can steal images from those websites as well. I remember once I got up early when camping in Joshua Tree National Park to set up a "perfect" morning light photo of a cliff. I carefully picked a spot, where I was soon joined by a little lady with a very big camera. We both took very similar photographs, and while chatting afterwards I mentioned that I am an amateur uploading most of my photographs to Wikipedia to be distributed for free, and she mentioned that she is trying to make a living as a full time photographer selling photos. It is unfortunate that my hobby competes with her ability to make a living. One possible solution to a professional photographer is to distribute only medium resolution photographs through Commons and leave a link to your website where you sell full size photographs. Unfortunately medium resolution photographs are often not eligible for quality badges or featured pictures. --Jarekt (talk) 17:57, 9 September 2013 (UTC)

So what to do with a user, such as ThePanhead, who uploads photos with digital watermarks and then reverts to those versions when the watermarks are cropped-out? Walter Görlitz (talk) 07:12, 4 February 2014 (UTC)

Better wait till we get some solid opinion. Jee 07:18, 4 February 2014 (UTC)

"'One possible solution to a professional photographer is to distribute only medium resolution photographs through Commons and leave a link to your website where you sell full size photographs. - Jarekt" Jarekt, it is dangerous to make such an advice now. Jee 07:22, 4 February 2014 (UTC)

Links

When having the default settings to "English", Camera manufacturer and Camera model is linked to the respective en.wikipedia article. When having the default settings to "Deutsch" the Metadata entries are not clickable. I would love to have this feature though, it would be nice if the Metadata with German language settings will correspond with de.wikipedia... Is there a specific reason for this configuration? --Gereon K. (talk) 23:14, 16 March 2016 (UTC)

Solved by Didym. --Gereon K. (talk) 21:09, 19 March 2016 (UTC)

Suppressing EXIF data

For medical images we need simple techniques to suppress / hide EXIF data. For a picture of a sore throat it does not matter the geolocation or the exact date and time the image was taken. We should at least be able to restrict this to admins. Doc James (talk · contribs · email) 18:48, 1 May 2019 (UTC)

On Windows, try Metability QuickFix - see https://www.youtube.com/watch?v=LeM-OyTZiDs for instructions. --RexxS (talk) 19:05, 1 May 2019 (UTC)

Delete if no EXIF?

Can someone please point me to the Commons policy which supports "Media without EXIF may be deleted" ? Thanks, Andy Dingley (talk) 15:27, 31 July 2019 (UTC)

How about photos taken with phones?

Will they have metadata too? --Piotr Konieczny aka Prokonsul Piotrus ^Talk 00:40, 7 October 2020 (UTC)

Discussion on redirects from EXIF data taking place at en:Wikipedia:Administrators' noticeboard

Not sure if anyone watches this page or cares about these links, but there is a discussion going on at en:Wikipedia:Administrators' noticeboard#Request to create redirect page at Matplotlib version3.3.3, https://matplotlib.org/ regarding the redirects created for links found in the EXIF metadata on Commons file pages. I requested an admin make a redirect that I could not because it had a url in the name, and I am being met with a surprising amount of opposition and even one call to delete all existing redirects from file metadata links (1277 total as of now). I am truly surprised at this and don't understand the reason why there is so much push-back for what I thought was an innocuous request to make a harmless and helpful redirect. If anyone has an opinion on these Wikipedia redirects for the EXIF metadata links found on Commons file pages, please weigh in on this discussion. Thanks. --Yarnalgo (talk) 17:25, 7 June 2021 (UTC)

Edit EXIF data of already uploaded images

Is there a way to edit the EXIF data of already uploaded TIFF images? It has been brought to my attention that some images I have uploaded have Copyright and Author fields set by the scanner that produced the images. These values are not correct so I need to change or remove them. --Nils.Weinander-RA (talk) 11:38, 5 November 2021 (UTC)

@Nils.Weinander-RA Sadly this is not possible. You have to fix the EXIF data locally on your computer an re-upload over the existing image. If there are private, sensitive data in the previous version you can ask for Commons:Oversight. Raymond 11:49, 5 November 2021 (UTC)

@Raymond Thanks! Local fix and re-upload is fine. The data is neither private nor sensitive, just incorrect. I'll just have to look into how to upload to replace an image. --Nils.Weinander-RA (talk)

@Raymond I tried replacing a file with a new version with cleaned EXIF but ran into another problem. The upload to replace file sets a limit of 100 MB file size which isn't the case with the upload wizard and all the files I need to replace are >100 MB TIFFs. Is there any way around this? --Nils.Weinander-RA (talk) 14:58, 8 November 2021 (UTC)

@Nils.Weinander-RA: You can use the chunked upload script, which allows (theoretically) uploads up to 4 GB. Regards, Yann (talk) 16:16, 8 November 2021 (UTC)

@Yann Thanks! Works fine! --Nils.Weinander-RA (talk) 10:25, 9 November 2021 (UTC)

how include all ccbysa licenses on jpg file

exiftool howto section: setting the description, artist,.. is given. i am particular interested to copy and paste copyright text as it is using exif editor (gui) (on my mobile app)? or should i replace backslash with new line? is it also update -XMP-cc:License also? can i add ccbysa versions 1,2,2.5 and 3?

"This work is licensed under the Creative Commons Attribution ShareAlike 4.0 International License. To view a copy of this license, visit https://creativecommons.org/licenses/by-sa/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042 USA." -XMP-cc:License="https://creativecommons.org/licenses/by-sa/4.0/" Ping aggy (talk) 14:19, 29 April 2022 (UTC)

i found a way to include all:

exiftool -ImageDescription="This is an example image" -Artist="Artist's name" \

-Copyright="This work is licensed under the Creative Commons Attribution ShareAlike 1.0 Generic, 2.0 Generic, 2.5 Generic, 3.0 Unported and 4.0 International License. \
To view a copy of this license, visit https://creativecommons.org/licenses/by-sa/1.0/deed, https://creativecommons.org/licenses/by-sa/2.0/deed, https://creativecommons.org/licenses/by-sa/2.5/deed, https://creativecommons.org/licenses/by-sa/3.0/deed,  https://creativecommons.org/licenses/by-sa/4.0/deed, or send a \
letter to Creative Commons, PO Box 1866, Mountain View, CA 94042 USA." \

-XMP-cc:License="https://creativecommons.org/licenses/by-sa/1.0/ https://creativecommons.org/licenses/by-sa/2.0/ https://creativecommons.org/licenses/by-sa/2.5/ https://creativecommons.org/licenses/by-sa/3.0/ https://creativecommons.org/licenses/by-sa/4.0/" /path to ur jpg file i hope it will help. Ping aggy (talk) 05:16, 2 May 2022 (UTC)

Newer airplanes that block GPS signals

Note newer planes with tinted windows like w:Dreamliner block GPS signals, so one will need to visit e.g., w:FlightAware within a week after one's flight (or pay), to get the .kml tracks, and then use w:gpsbabel to make one second interval kml tracks, and then use w:exiftool -geotag to finally get the correct tags back on the images one has taken on such planes, before uploading them to Commons! Jidanni (talk) 09:51, 12 January 2023 (UTC)

Exiftools command examples

I am a bit puzzled by the Exiftools example "asserting normal copyright":

-Artist="Camera owner, John Smith; Photographer, Michael Brown; Image creator, Ken James" \
-Copyright="Copyright, John Smith, 1988. All rights reserved."

What is the "image creator's role"? Why is is the camera owner mentioned in the Artist tag? How often does a private camera owner get the copyright? I am afraid this example may strengthen misconceptions about the camera owner's right to images, such as in the typical "Here's my camera, please take a photo of us" situation, where the copyright stays with the stranger, and the photo thus is unusable for anything but "private" or "fair" use. (Ironically even for intended signpost use: the press may use other's images, but not if the image was intended for the press).

–LPfi (talk) 08:31, 2 May 2023 (UTC)