-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I have added the PHP EXIF data reader from [1] to CVS HEAD. EXIF data display is now turned on by default on the image page. The PHP class I used is independent of the EXIF PHP library, which would otherwise have to be linked in (recompile/won't run everywhere).
I have patched the class to some degree to suppress error messages, and to prevent showing bogus EXIF data where none exists.
As I recall, automatic EXIF data display has been on the "wanted feature" list for quite some time. So, rejoice! ;-)
Magnus
[1] http://www.vinayras.com/project/phpexifrw.php
Magnus Manske wrote:
I have added the PHP EXIF data reader from [1] to CVS HEAD. EXIF data display is now turned on by default on the image page. The PHP class I used is independent of the EXIF PHP library, which would otherwise have to be linked in (recompile/won't run everywhere).
I have patched the class to some degree to suppress error messages, and to prevent showing bogus EXIF data where none exists.
As I recall, automatic EXIF data display has been on the "wanted feature" list for quite some time. So, rejoice! ;-)
Would you consider putting that information into the database? A metadata blob would do the trick, with some method to distinguish values set by various extensions. Your patch won't work for apaches which have no access to the commons filesystem, which is how we intend to set up the Yahoo/Belnet/Kennisnet apaches. Image::getImagePath() will return false.
-- Tim Starling
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tim Starling schrieb:
Magnus Manske wrote:
I have added the PHP EXIF data reader from [1] to CVS HEAD. EXIF data display is now turned on by default on the image page. The PHP class I used is independent of the EXIF PHP library, which would otherwise have to be linked in (recompile/won't run everywhere).
I have patched the class to some degree to suppress error messages, and to prevent showing bogus EXIF data where none exists.
As I recall, automatic EXIF data display has been on the "wanted feature" list for quite some time. So, rejoice! ;-)
Would you consider putting that information into the database? A metadata blob would do the trick, with some method to distinguish values set by various extensions. Your patch won't work for apaches which have no access to the commons filesystem, which is how we intend to set up the Yahoo/Belnet/Kennisnet apaches. Image::getImagePath() will return false.
Can do. How about img_metadata, with XML? We could add more EXIF data or other metadata about the image there. Or would that be too slow to parse?
Another way would be to keep it as it is, and add a special mode to ImagePage.php, which would return the EXIF table in plain text; that could be read in by the "calling" wikipedia.
Now that I think of it: Why not include the EXIF data in the Special:Export XML for the image description page? That way, we could display EXIF data, image comment, (last) author of the description page etc. in the "calling" wikipedia, which is a wanted feature anyway.
Magnus
Magnus Manske wrote:
Can do. How about img_metadata, with XML? We could add more EXIF data or other metadata about the image there. Or would that be too slow to parse?
I lean towards serialized PHP objects or arrays for this kind of storage, but you can suit yourself. XML is good for exchanging data across a variety of systems, an application which has never excited me very much.
Another way would be to keep it as it is, and add a special mode to ImagePage.php, which would return the EXIF table in plain text; that could be read in by the "calling" wikipedia.
Now that I think of it: Why not include the EXIF data in the Special:Export XML for the image description page? That way, we could display EXIF data, image comment, (last) author of the description page etc. in the "calling" wikipedia, which is a wanted feature anyway.
The problem with using Special:Export or action=raw for this purpose is that the wikitext in the description page must be parsed in the context of the commons wiki. Templates must be available and namespaces must be correct. My idea for addressing this is to introduce an action=render which outputs an HTML fragment suitable for incorporation into the parser output. This would also be handy for interwiki transclusion, although it would restrict the feature to trusted sites for security reasons.
The current plan for transmitting commons metadata is to use MySQL to replicate the data to a local slave DB. This allows the apache to serve requests without waiting for a 100-200ms propagation delay.
-- Tim Starling
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tim Starling schrieb:
Magnus Manske wrote:
Can do. How about img_metadata, with XML? We could add more EXIF data or other metadata about the image there. Or would that be too slow to parse?
I lean towards serialized PHP objects or arrays for this kind of storage, but you can suit yourself. XML is good for exchanging data across a variety of systems, an application which has never excited me very much.
OK, img_exif is in, as a serialized array. Don't forget to update your image table! :-)
I will add a function to update the img_exif field if it is empty, when viewing an image; that way, all exiting images will get updated automatically, in time.
Magnus
On 4/21/05, Magnus Manske magnus.manske@web.de wrote:
Can do. How about img_metadata, with XML? We could add more EXIF data or other metadata about the image there. Or would that be too slow to parse?
Might I suggest file_metadata, we don't want to get stuck with img for files again. I could see how metadata for other files might be useful. Just have one of the fields be the type of file.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dori schrieb:
On 4/21/05, Magnus Manske magnus.manske@web.de wrote:
Can do. How about img_metadata, with XML? We could add more EXIF data or other metadata about the image there. Or would that be too slow to parse?
Might I suggest file_metadata, we don't want to get stuck with img for files again. I could see how metadata for other files might be useful. Just have one of the fields be the type of file.
It is img_exif now.
Magnus
Dori wrote:
On 4/21/05, Magnus Manske magnus.manske@web.de wrote:
Can do. How about img_metadata, with XML? We could add more EXIF data or other metadata about the image there. Or would that be too slow to parse?
Might I suggest file_metadata, we don't want to get stuck with img for files again. I could see how metadata for other files might be useful. Just have one of the fields be the type of file.
The table is called "image", all field names in that table are prefixed with img_, that's how it's been since phase3 was written. We're already stuck with it, it's too late.
-- Tim Starling
Magnus Manske (magnus.manske@web.de) [050421 19:27]:
I have added the PHP EXIF data reader from [1] to CVS HEAD. EXIF data display is now turned on by default on the image page. The PHP class I used is independent of the EXIF PHP library, which would otherwise have to be linked in (recompile/won't run everywhere).
Cool :-) I assume the resulting data will be editable?
- d.
David Gerard said:
Magnus Manske (magnus.manske@web.de) [050421 19:27]:
I have added the PHP EXIF data reader from [1] to CVS HEAD. EXIF data display is now turned on by default on the image page. The PHP class I used is independent of the EXIF PHP library, which would otherwise have to be linked in (recompile/won't run everywhere).
Cool :-) I assume the resulting data will be editable?
If it is, I hope a history is preserved. The EXIF data is an integral part of the copyrighted data in the image, and editing the EXIF could obscure information relating to ownership.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tony Sidaway schrieb:
David Gerard said:
Magnus Manske (magnus.manske@web.de) [050421 19:27]:
I have added the PHP EXIF data reader from [1] to CVS HEAD. EXIF data display is now turned on by default on the image page. The PHP class I used is independent of the EXIF PHP library, which would otherwise have to be linked in (recompile/won't run everywhere).
Cool :-) I assume the resulting data will be editable?
If it is, I hope a history is preserved. The EXIF data is an integral part of the copyrighted data in the image, and editing the EXIF could obscure information relating to ownership.
Neither, for good reasons :-)
The EXIF data is part of the image file. It is generated at the moment the photo is made. I'm just extracting it from there.
There's no point editing EXIF data for us; the only field one should edit would be the description and, well, we can already do that :-)
I do not store the history in the old image table, as it can be retrieved from the image itself.
Magnus
Magnus Manske (magnus.manske@web.de) [050421 22:23]:
The EXIF data is part of the image file. It is generated at the moment the photo is made. I'm just extracting it from there. There's no point editing EXIF data for us; the only field one should edit would be the description and, well, we can already do that :-) I do not store the history in the old image table, as it can be retrieved from the image itself.
Oh yes. Duh. *blush*
- d.
Hello Magnus,
Thursday, April 21, 2005, 12:27:35 PM, you wrote:
I have added the PHP EXIF data reader from [1] to CVS HEAD. EXIF data display is now turned on by default on the image page. The PHP class I used is independent of the EXIF PHP library, which would otherwise have to be linked in (recompile/won't run everywhere).
could you post the link to any image with EXIF just to see what it looks like?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
monk@zoomcon.com schrieb:
Hello Magnus,
Thursday, April 21, 2005, 12:27:35 PM, you wrote:
I have added the PHP EXIF data reader from [1] to CVS HEAD. EXIF data display is now turned on by default on the image page. The PHP class I used is independent of the EXIF PHP library, which would otherwise have to be linked in (recompile/won't run everywhere).
could you post the link to any image with EXIF just to see what it looks like?
Most images made with digital cameras have EXIF data. Try this one:
http://commons.wikimedia.org/wiki/Image:Town_hall%2C_Reims%2C_France_2004-11...
You can see a demo screenshot with EXIF data here:
http://magnusmanske.de/wikipedia/EXIF-screenshot.png
Magnus
"Magnus Manske" magnus.manske@web.de wrote in message news:42679D04.2060805@web.de...
monk@zoomcon.com schrieb:
could you post the link to any image with EXIF just to see what it looks like?
http://commons.wikimedia.org/wiki/Image:Town_hall%2C_Reims%2C_France_2004-11...
What am I looking for? I'm getting nothing like your screen shot: it just looks like an normal image page.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Phil Boswell schrieb:
"Magnus Manske" magnus.manske@web.de wrote in message news:42679D04.2060805@web.de...
monk@zoomcon.com schrieb:
could you post the link to any image with EXIF just to see what it looks like?
http://commons.wikimedia.org/wiki/Image:Town_hall%2C_Reims%2C_France_2004-11...
What am I looking for? I'm getting nothing like your screen shot: it just looks like an normal image page.
That's because the EXIF code is in CVS HEAD (aka MediaWiki 1.5 pre-beta), while commons is running 1.4.x
If you want to play, you'll have to setup a CVS HEAD snapshot on your own server, or wait for Brion to finally, *finally* (see a pattern here?) setup a demo site :-)
Magnus
Magnus Manske wrote:
Phil Boswell schrieb:
What am I looking for? I'm getting nothing like your screen shot: it just looks like an normal image page.
If you want to play, you'll have to setup a CVS HEAD snapshot on your own server, or wait for Brion to finally, *finally* (see a pattern here?) setup a demo site :-)
Here ya go: http://test.leuksman.com/index.php/Image:Town_hall%2C_Reims%2C_France_2004-1...
Might want to change the alignment on the table cells. Localized, NonCamelCase item names might be nice too though that'll be some work. I'm uncertain about the right-floating table; it's awfully big and seems to weigh kind of strangely.
-- brion vibber (brion @ pobox.com)
On 4/21/05, Brion Vibber brion@pobox.com wrote:
Magnus Manske wrote:
Phil Boswell schrieb:
What am I looking for? I'm getting nothing like your screen shot: it
just
looks like an normal image page.
If you want to play, you'll have to setup a CVS HEAD snapshot on your own server, or wait for Brion to finally, *finally* (see a pattern here?) setup a demo site :-)
Here ya go:
http://test.leuksman.com/index.php/Image:Town_hall%2C_Reims%2C_France_2004-1...
Might want to change the alignment on the table cells. Localized, NonCamelCase item names might be nice too though that'll be some work. I'm uncertain about the right-floating table; it's awfully big and seems to weigh kind of strangely.
It's be nice if it could collapseable like the TOC, and be collapsed by default. It'd also be nice to gather some stats on the camera models used, if some are more likely to produce featured pictures, etc.
It's be nice if it could collapseable like the TOC, and be collapsed by default. It'd also be nice to gather some stats on the camera models used, if some are more likely to produce featured pictures, etc.
It would be nice if the look didn't suck in general.
When Magnus initially added the support he made the table appear before the image and aligned it to the right, this had the negative side-effect of having a huge table before the image (as opposed to floating beside the image) when the image was too big to fit the table beside it, so I moved it. It would be nice if we could have the middle ground of beside the image if it fits and below it (not above) if it doesn't.
Regarding statistics that wouldn't be practically possible (fast) unless we added a new table named image_metadata and had a seperate field for each valid EXIF tag (of which there are alot), then we could add an advanced Image search.
An advanced search, using EXIF data, could be nice---especially for the photos that have GPS EXIF data (not many, but they're getting more common). Maybe have a field for the commonly-used EXIF tags, and shove anything strange into a field at the end. They're displayed, but can't be used in searches.
On 22 Aib 2005, at 20:22, Ævar Arnfjörð Bjarmason wrote:
It's be nice if it could collapseable like the TOC, and be collapsed by default. It'd also be nice to gather some stats on the camera models used, if some are more likely to produce featured pictures, etc.
It would be nice if the look didn't suck in general.
When Magnus initially added the support he made the table appear before the image and aligned it to the right, this had the negative side-effect of having a huge table before the image (as opposed to floating beside the image) when the image was too big to fit the table beside it, so I moved it. It would be nice if we could have the middle ground of beside the image if it fits and below it (not above) if it doesn't.
Regarding statistics that wouldn't be practically possible (fast) unless we added a new table named image_metadata and had a seperate field for each valid EXIF tag (of which there are alot), then we could add an advanced Image search. _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On 4/23/05, Patrick Collison patrick@collison.ie wrote:
An advanced search, using EXIF data, could be nice---especially for the photos that have GPS EXIF data (not many, but they're getting more common). Maybe have a field for the commonly-used EXIF tags, and shove anything strange into a field at the end. They're displayed, but can't be used in searches.
There are 116 valid exif fields in version 2.2 of the standard, we probably only want to index 103 of those, but that still leaves alot of fields.
Could you point me to an image (or images) with GPS metadata? I'm currently improving our GPS EXIF support of which we have none.
A quick Googling turned up the picture at http://www.danger- island.com/~dav/writeon/hiptop_images/default/ 2003-05-24_115510_28166_0.jpg.
On 23 Aib 2005, at 20:21, Ævar Arnfjörð Bjarmason wrote:
On 4/23/05, Patrick Collison patrick@collison.ie wrote:
An advanced search, using EXIF data, could be nice---especially for the photos that have GPS EXIF data (not many, but they're getting more common). Maybe have a field for the commonly-used EXIF tags, and shove anything strange into a field at the end. They're displayed, but can't be used in searches.
There are 116 valid exif fields in version 2.2 of the standard, we probably only want to index 103 of those, but that still leaves alot of fields.
Could you point me to an image (or images) with GPS metadata? I'm currently improving our GPS EXIF support of which we have none. _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ævar Arnfjörð Bjarmason schrieb:
It's be nice if it could collapseable like the TOC, and be collapsed by default. It'd also be nice to gather some stats on the camera models used, if some are more likely to produce featured pictures, etc.
It would be nice if the look didn't suck in general.
When Magnus initially added the support he made the table appear before the image and aligned it to the right, this had the negative side-effect of having a huge table before the image (as opposed to floating beside the image) when the image was too big to fit the table beside it, so I moved it. It would be nice if we could have the middle ground of beside the image if it fits and below it (not above) if it doesn't.
We could always limit the table width, and then make the user set the maximum image preview width in his preferences manually :-]
Regarding statistics that wouldn't be practically possible (fast) unless we added a new table named image_metadata and had a seperate field for each valid EXIF tag (of which there are alot), then we could add an advanced Image search.
IMHO the chances for someone desperately needing to search for all images taken with a specific camera model or similar are pretty slim. The vast majority of people will search for names (places, people), types/context (beach, church, person) etc.
For doing some statistics, a dozen new fields or so might be overkill. A statics-gathering task could run once a week or so, reading each and every entry and doing statistics internally, then sum them up on a single page.
If, for some reason, there's pressing need for fast searching of EXIF data, maybe a new table (exif_image_id,exif_key,exif_value) would be in order; that way, we can store all keys flexible (as a string), without having to create a new field for every single key (and update and maintain these, if the standard changes).
Magnus
Magnus Manske schrieb:
You can see a demo screenshot with EXIF data here:
I don't know the EXIF format, but "flashUsed" is shown twice (numerically and as string). Maybe this is a minor glitch within the used code. I'm sure people would report that as Wikipedia bug shortly after releasing this feature :)
Ciao, Michael.
On Thursday, April 21, 2005 6:51 PM, Michael Keppler Michael.Keppler@gmx.de wrote:
Magnus Manske schrieb:
You can see a demo screenshot with EXIF data here:
I don't know the EXIF format, but "flashUsed" is shown twice (numerically and as string). Maybe this is a minor glitch within the used code. I'm sure people would report that as Wikipedia bug shortly after releasing this feature :)
Actually, it's "FlashUsed" -> 0 and "flashUsed" -> "No". The EXIF data is essentially free-form, decided by the manufacturer of the camera (though it can be edited after capture with some tools too, of course).
The main problem is that a lot of cameras use quite odd names for some of their fields, that there are very few bits of EXIF data that are actually particularly useful, and that a lot of the more useful ones are in fact not generated (I'm thinking of the standard names for GPS co-ordinates - automagical location-generation would be terribly cool, though a bit of a privacy risk for users, of course).
I'm interested to see what Magnus will decide to do with the data.
Yours,
On Thursday 21 April 2005 11:27, Magnus Manske wrote:
I have added the PHP EXIF data reader from [1] to CVS HEAD. EXIF data display is now turned on by default on the image page. The PHP class I used is independent of the EXIF PHP library, which would otherwise have to be linked in (recompile/won't run everywhere).
having metadata like this would be nice to have for all kinds of files, not only images.
daniel
Just came across this thread.
After Magnus initially wrote the Exif support I rewrote the Exif parsing part of it using php's internal exif libaries, the old code was 1500 lines and we're doing the same thing in ~100 lines now, that rewrite is already live on the testwiki.
It still needs a bit of spit & polish (which I'm working on, see http://bugzilla.wikimedia.org/show_bug.cgi?id=1947)
You might also be interested in the Ogg metadata bug: http://bugzilla.wikimedia.org/show_bug.cgi?id=1948
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ævar Arnfjörð Bjarmason schrieb:
Just came across this thread.
After Magnus initially wrote the Exif support I rewrote the Exif parsing part of it using php's internal exif libaries, the old code was 1500 lines and we're doing the same thing in ~100 lines now, that rewrite is already live on the testwiki.
Well, I'd like to take credit, but I just found the EXIF include file (LGPL) on the web.
Also, I was well aware of the internal PHP function for that purpose, but also that it was introduced in PHP 4.2. Not to leaveolder installations (and the default Windows installation, which has EXIF support turned off) "in the dark" was the sole purpose to use the include file.
Anyway, it's gone now.
Magnus
wikitech-l@lists.wikimedia.org