Last modified: 2005-06-14 15:55:51 UTC
http://www.flickr.com/photo_exif.gne?id=4877316 quote "Almost all new digital cameras save JPEG (jpg) files with EXIF (Exchangeable Image File) data. ...." http://www.flickr.com/photo_exif.gne?id=4877316 We need this badly! It is f****** great! --~~~~
Who can progam this ? I am interested. It would be nice to have such information on the Image wiki page automatically.
There are PHP classes for this already according to Erik. It "just" needs to be implemented. greetings Paddy
this is how it could look: http://commons.wikimedia.org/wiki/Image:Kostel_Panny_Marie_Snezne_01_2003-12-22.jpg
This is generally useful but we need to make sure that we don't just dump information on the image description page that's redundant or difficult to interpret. I'll refer to the mock-up at [[Commons:Image:Kostel Panny Marie Snezne 01 2003-12-22.jpg]]: Exposure date ("Date and time (original)") is clearly useful, but ("Date and time (digitized)") should only be included if it differs from the exposure date by more than a few seconds. However, this is only meaningful if the correct date was set on the camera. If not, there is not point in displaying this EXIF field. So there must be a way to selectively override the EXIF information. Exposure and aperture together don't tell us much about the light situation on location unless we also know the ISO sensitivity setting of the camera. Exposure time is usually only interesting for very long or very short exposures, e.g. to show movement or stop movement. Aperture in and of itself is pretty meaningless as far as depth-of-field is concerned if we don't know the image diagonal, i.e., the sensor size in this case. In 35mm format, f/2.8 would give a fairly shallow depth-of-field, but in digital cameras with much smaller sensors, the DoF may be acceptable. Likewise for focal length: 7.3mm doesn't mean anything unless one knows the sensor size. A 7.3mm lens on a 35mm camera would be among the widest fish-eye lenses in history, but may give a moderately wide view on a small digital camera. It's customary to give the 35mm equivalent focal length, since that is a fixed format that lots of people are familiar with. "X-Resolution" and "Y-Resolution" are meaningless: the values of 72 dpi clearly don't indicate the resolution/size of the image sensor. If I print that image (1632 x 2448) on 8" by 12" paper, this corresponds to a resolution of 204dpi. If I make a smaller print, the same image will appear in a higher resolution. "Exposure program: normal" and "Metering mode: average" are useful during critiques, but are hard to interpret if one doesn't know the other options the camera supports. In other words, someone may suggest to the photographer, "could you try shooting this in aperture priority mode with spot metering on the building wall", but not every visitor to the image description page might care about this information. In other words, there should be a way to selectively display some of the EXIF fields, but not others. "Color Space: sRGB" is only useful if the color space is *not* sRGB, which is clearly the de facto standard on the web and, I believe, also a W3C recommendation. "Compression: JPEG" is redundant, unless it's augmented with other information about the exact JPEG settings, such as image quality, smoothing, chroma subsampling, etc. "Flash: Flash fired" is worded or phrased in a repetitive and redundant way or fashion. It's also unreliable. On my own camera, "flash fired" defaults to "false" if I use an external flash. I guess the point I'm getting to is this: we don't want to display all EXIF fields by default for every image. Instead, the photographer should choose which ones to display on the image description page. Perhaps one way to achieve this would be this: 1. Photographer uploads image with EXIF data. 2. Mediawiki generates a default image description page with all EXIF data in table format, followed by the upload comment. 3. Photographer edits image description page, removing any unnecessary rows of the table.
(In reply to comment #3) > this is how it could look: > http://commons.wikimedia.org/wiki/Image:Kostel_Panny_Marie_Snezne_01_2003-12-22.jpg It's okay, but I propose to use - by default - a very small font for this information, so that the resulting table is tiny and compact.
A developer is needed - I guess, this EXIF data extract & display could be implemented very quickly, couldn't it ? 1 night work and: ready
Created attachment 416 [details] Sample exif data output from exif_read_data() I did some superficial tests for this, we can use the new img_type field timstarling implemented to determine the type of image it is, and then use exif_read_data() to return an associative array of exif data we can use. However after that it becomes tricky, should a new field for image metadata be created in the database? It looks like just generating it on the fly, therefor going through the same cache mechanism as regular pages, might not be so expensive, it took around 0.1 seconds to extract image metadata from the images I was using for testing. Once that's solved we'll want to format it nicely, we could choose a small subset of exif tags to whitelist such as camera make, time, exp. time and so on or just dump them all on the page (which could get ugly).
Added to CVS HEAD (1.5 pre-alpha)
The implementation of this in HEAD isn't quite working as it should be: * You added a img_exif field to the image table but didn't make an update to the schema (or a db patch) * Exif data is displayed even on files that are not images at all, such as Ogg Vorbis files, you should check the img_field field before you attempt to run the exif functions on an image. * The exifReader.inc you checked in is *huge* (1500 lines), we're just trying to get an associative array of exif data, it would be much better to use internal php functions for this, namely exif_read_data(), a basic implementation using that function is: if ( $exif = exif_read_data('img.jpeg') ) { [.. do stuff with the $exit array ..] } * Obviously just doing the above won't do since that would still give us the raw thumbnail, but it's still going to be alot smaller than *1500 lines* (unless there's something fancy going on in there which I haven't seen yet)
I've begun working on an implementation of this that uses internal php functions and doesn't save exif data for non-jpeg and tiff files.
When I look to the example on testwiki http://test.leuksman.com/index.php/Image:Test1137.jpg , I wonder why I cannot find the (EXIF) DATE and TIME when the photo was taken. Did I overlook something ? I think, that date & time of the image are useful pieces of information and should be shown as well. Or do you have data security and privacy based objections ?
It's not included currently, I'm rewriting the code, see bug 1947.
The code currently generates: <table class="metadata" align="right" width="250px"> can I suggest this be changed to <table class="metadata"> as the align property is deprecated in xhtml. and the following added to .metadata in the stylesheet: .metadata { ... float: right; clear: right; width: 20em; /* or some suitable width, but defined in em's which are relative to font size */ }
