Last modified: 2005-06-14 15:55:51 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 1555 - EXIF data
EXIF data
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
All All
: Normal enhancement with 7 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
Blocks: 657
  Show dependency treegraph
Reported: 2005-02-18 00:40 UTC by Patrick-Emil Zörner
Modified: 2005-06-14 15:55 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

Sample exif data output from exif_read_data() (7.95 KB, text/plain)
2005-04-11 21:30 UTC, Ævar Arnfjörð Bjarmason

Description Patrick-Emil Zörner 2005-02-18 00:40:45 UTC

quote "Almost all new digital cameras save JPEG (jpg) files with EXIF
(Exchangeable Image File) data. ...."

We need this badly! It is f****** great! --~~~~
Comment 1 T. Gries 2005-02-18 22:23:03 UTC
Who can progam this ? I am interested. It would be nice to have such information
on the Image wiki page automatically.
Comment 2 Patrick-Emil Zörner 2005-02-19 03:11:12 UTC
There are PHP classes for this already according to Erik. It "just" needs to be
implemented. greetings Paddy
Comment 3 Patrick-Emil Zörner 2005-02-19 21:45:02 UTC
this is how it could look:
Comment 4 mark_sweep 2005-02-19 23:37:42 UTC
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.
Comment 5 T. Gries 2005-02-19 23:40:57 UTC
(In reply to comment #3)
> this is how it could look:

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.
Comment 6 T. Gries 2005-02-19 23:46:19 UTC
A developer is needed - I guess, this EXIF data extract & display could be
implemented very quickly, couldn't it ? 1 night work and: ready 
Comment 7 Ævar Arnfjörð Bjarmason 2005-04-11 21:30:49 UTC
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).
Comment 8 Magnus Manske 2005-04-21 13:59:31 UTC
Added to CVS HEAD (1.5 pre-alpha)
Comment 9 Ævar Arnfjörð Bjarmason 2005-04-21 14:24:13 UTC
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 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)
Comment 10 Ævar Arnfjörð Bjarmason 2005-04-21 18:12:18 UTC
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.
Comment 11 T. Gries 2005-04-29 19:08:32 UTC
When I look to the example on testwiki , 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 ?
Comment 12 Ævar Arnfjörð Bjarmason 2005-04-29 19:10:01 UTC
It's not included currently, I'm rewriting the code, see bug 1947.
Comment 13 ejsanders 2005-05-17 16:32:23 UTC
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:
 float: right;
 clear: right;
 width: 20em; /* or some suitable width, but defined in em's which are relative
to font size */

Note You need to log in before you can comment on or make changes to this bug.