Page MenuHomePhabricator

MediaWiki api doesn't serve EXIF GPSAltitude (and other tags) as decimals
Open, MediumPublic

Description

Author: neilk

Description:
If you upload an image with an EXIF GPSAltitude, and then fetch imageinfo via the API, you just get the difficult-to-work-with "rational" value, such as "9395/128". Many other fields, such as FocalLength, GPSTimestamp, etc. are displayed as rationals.

However GPSLatitude and GPSLongitude are shown with the expected "decimal" values.

Example: do this API query on test.wikipedia.org.

http://test.wikipedia.org/w/api.php?action=query&titles=File%3ATest_rationals%2Ejpg&prop=imageinfo&iiprop=metadata

A sample result is attached to this bug.

You can also import that file into your own wiki to do testing.

The Exif module that handles bitmaps seems to have the fields tagged correctly as Exif::RATIONAL, so I'm not sure exactly what is going wrong; whether it's when the file is uploaded or how we render results in the API.


Version: 1.18.x
Severity: normal

Details

Reference
bz32410

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:04 AM
bzimport set Reference to bz32410.

neilk wrote:

Sample API results showing rationals where decimals expected

attachment url.txt ignored as obsolete

neilk wrote:

Sample API results showing rationals where decimals expected (JSON)

Attached:

This is the expected behaviour. (Mostly because that's the way its been forever and ever. It would perhaps make sense to convert the rationals to decimals before storing in db, or even convert it just for api output). GPSLatitude is different just because the array of three values is just plain annoying to deal with ;)

  • Bug 32608 has been marked as a duplicate of this bug. ***
  • Bug 35015 has been marked as a duplicate of this bug. ***

I submitted gerrit change 20288 which changes the behaviour just for GPSAltitude, since some of my other code was assuming it was a normal floating point number, which caused totally wrong displays when the altitude was below sea level.

I still feel that things which use the image metadata from MediaWiki should not make assumptions as to if the data is a rational number or a normal real number. In the future I do think it should probably be changed to convert all those fields (except maybe shutter speed) [converting them would be a mild breaking change in the api, but i doubt anyone would care]. However, even if that is done, anything using the image metadata from mediawiki would still have to support both rational numbers and normal decimal numbers, since the metadata from files stays cached for a long time (years).

ghouston wrote:

The upload wizard fails for every geocoded file that I upload, unless I manually change the Altitude field from 0/1 to 0.

This field is hidden by default in the "Add categories and more information ..." section, and if you don't open that section the upload simply fails without explaining what the problem is.

TheDJ added a comment.Aug 22 2012, 9:05 AM

@Gary, for the UW specific part, I filed bug 39553

(In reply to comment #6)

I submitted Gerrit change #20288 which changes the behaviour just for

Status Merged, bug maybe resolved

Restricted Application added subscribers: Steinsplitter, Matanya, Aklapper. · View Herald TranscriptJul 31 2015, 1:31 PM

Honestly, I didn't really think its a bug in the first place.

Exif tags that are "rationals" according to the spec (with exception to lat/long) are still served as rational numbers afaik

Jdforrester-WMF moved this task from Untriaged to Backlog on the Multimedia board.Sep 4 2015, 6:32 PM
Bawolff removed Bawolff as the assignee of this task.Nov 24 2015, 9:54 PM

unasigning from self.

I don't have plans to work on this in the near or medium term future. I have mixed opinions on if this is even a bug or not (But with some time/hindsight, I lean more towards this is a a bug then I used to).