Who can progam this ? I am interested. It would be nice to have such information
on the Image wiki page automatically.

paddyez wrote:

There are PHP classes for this already according to Erik. It "just" needs to be
implemented. greetings Paddy

paddyez wrote:

this is how it could look:
http://commons.wikimedia.org/wiki/Image:Kostel_Panny_Marie_Snezne_01_2003-12-22.jpg

mark_sweep wrote:

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

avarab wrote:

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).

Attached:

Added to CVS HEAD (1.5 pre-alpha)

avarab wrote:

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)

avarab wrote:

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 ?

avarab wrote:

It's not included currently, I'm rewriting the code, see bug 1947.

ejsanders wrote:

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 */
}