For a tool that tries to fill in {{Information}} templates on commons based on the current, unstructured text, I have it fill in the "Date" parameter from the EXIF data of the image, if available.
I just thought: How about a new magic word, {{EXIFDATE}}, that would extract EXIF data from the image? It could be used in {{Information}} as a default in case no "Date" parameter is provided.
{{EXIFDATE}} would return blank on namespaces other than "Image:", of course, and for files that have no EXIF data.
There could be {{EXIFTIME}} and {{EXIFTIMEDATE}} as well, but that would be luxus :-)
Shouldn't be too costly for the parser (on image pages, image data will be needed anyway).
Anyone opposed? Anyone willing to code? ;-)
Cheers, Magnus
On 20/08/07, Magnus Manske magnusmanske@googlemail.com wrote:
I just thought: How about a new magic word, {{EXIFDATE}}, that would extract EXIF data from the image? It could be used in {{Information}} as a default in case no "Date" parameter is provided.
Sounds good; couple of comments:
1. Provide for all eligible EXIF data 2. Use parser functions, not "magic words" - this will allow the user to provide the name of the file for which data should be extracted, for example
Rob Church
On 8/20/07, Rob Church robchur@gmail.com wrote:
On 20/08/07, Magnus Manske magnusmanske@googlemail.com wrote:
I just thought: How about a new magic word, {{EXIFDATE}}, that would extract EXIF data from the image? It could be used in {{Information}} as a default in case no "Date" parameter is provided.
Sounds good; couple of comments:
- Provide for all eligible EXIF data
- Use parser functions, not "magic words" - this will allow the user
to provide the name of the file for which data should be extracted, for example
Will do. How about: {{#exif:KEY}} and {{#exif:KEY|IMAGENAME}} ?
The second variant would then work in all namespaces, and the first one only in #6.
Since there is some variance in EXIF keys, I'd suggest some "internal" keys to simplify matters. For example, {{#exif:_DATE}} woule check several common date keys, and take the earliest one it finds.
Aah, the possibilities! [[Category:Taken with {{#exif:MODEL}}]] :-)
Magnus
On 20/08/07, Magnus Manske magnusmanske@googlemail.com wrote:
Will do. How about: {{#exif:KEY}} and {{#exif:KEY|IMAGENAME}} ?
The second variant would then work in all namespaces, and the first one only in #6.
Hmm, I was just poking MediaFunctions, considering doing this, and I have to admit, while it seems more "natural" to have the target first, being able to omit the image name on an image page does seem convenient...hadn't thought of that.
Since there is some variance in EXIF keys, I'd suggest some "internal" keys to simplify matters. For example, {{#exif:_DATE}} woule check several common date keys, and take the earliest one it finds.
This seems sensible, although I'd ditch the underscore and define some magic words for the individual EXIF bits. We might or might not want to provide some accessor for raw data with absolute named values, for the Gregs. ;)
Rob Church
Magnus Manske wrote:
Will do. How about: {{#exif:KEY}} and {{#exif:KEY|IMAGENAME}} ?
The second variant would then work in all namespaces, and the first one only in #6.
Since there is some variance in EXIF keys, I'd suggest some "internal" keys to simplify matters. For example, {{#exif:_DATE}} woule check several common date keys, and take the earliest one it finds.
Aah, the possibilities! [[Category:Taken with {{#exif:MODEL}}]] :-)
This seems a bit short-sighted, since I've been busy lately writing routines to extract and display metadata from Ogg files. Wouldn't it be better to call it something like {{#filemetadata:...}} ? Then the media handlers could provide arbitrary key-value pairs.
-- Tim Starling
On 20/08/07, Tim Starling tstarling@wikimedia.org wrote:
This seems a bit short-sighted, since I've been busy lately writing routines to extract and display metadata from Ogg files. Wouldn't it be better to call it something like {{#filemetadata:...}} ? Then the media handlers could provide arbitrary key-value pairs.
I don't understand whether you're objecting to the function name, which is trivial to change, or how the function actually operates...?
Rob Church
On 8/20/07, Rob Church robchur@gmail.com wrote:
On 20/08/07, Tim Starling tstarling@wikimedia.org wrote:
This seems a bit short-sighted, since I've been busy lately writing routines to extract and display metadata from Ogg files. Wouldn't it be better to call it something like {{#filemetadata:...}} ? Then the media handlers could provide arbitrary key-value pairs.
I don't understand whether you're objecting to the function name, which is trivial to change, or how the function actually operates...?
I think Tim has written PHP functions, but no wiki-based access to them. I want to write access routines for the wiki. So, {{#filemetadata}} sounds great.
Could someone quickly point me to where Tims handlers are defined/used, so I won't have to wade through the entire code? ;-)
(If someone else wants to write the extension, please go ahead; that way, it might actually get used on wikimedia sites!:-)
Magnus
Magnus Manske wrote:
On 8/20/07, Rob Church robchur@gmail.com wrote:
On 20/08/07, Tim Starling tstarling@wikimedia.org wrote:
This seems a bit short-sighted, since I've been busy lately writing routines to extract and display metadata from Ogg files. Wouldn't it be better to call it something like {{#filemetadata:...}} ? Then the media handlers could provide arbitrary key-value pairs.
I don't understand whether you're objecting to the function name, which is trivial to change, or how the function actually operates...?
Just the function name. It's not really that easy to change once it's in use on the wiki, it's easier if we get it right from the outset.
I think Tim has written PHP functions, but no wiki-based access to them. I want to write access routines for the wiki. So, {{#filemetadata}} sounds great.
Could someone quickly point me to where Tims handlers are defined/used, so I won't have to wade through the entire code? ;-)
The media handlers are in the includes/media directory. The new Ogg handler is in extensions/OggHandler. Presumably we would have a metadata accessor in the File object, which passes through to the media handler.
The interface for metadata is not yet finalised, so I wouldn't actually recommend making this work for arbitrary media types just yet. If I were you, I would stick with:
$metadata = $file->getMetadata(); $handler = $file->getHandler(); $metadataType = $handler ? $handler->getMetadataType( $file ) : false; if ( $metadataType != 'exif' ) return 'Media type not supported';
That gives you forwards-compatibility. You can leave the abstraction until I've finished with the media handler work.
-- Tim Starling
On 20/08/07, Tim Starling tstarling@wikimedia.org wrote:
Just the function name. It's not really that easy to change once it's in use on the wiki, it's easier if we get it right from the outset.
Well, no, but I was referring to the development phase.
Rob Church
wikitech-l@lists.wikimedia.org