Page MenuHomePhabricator

EXIF orientation tag use broken in 1.18 - skewed display
Closed, ResolvedPublic

Description

Related to Bug 6672 ("EXIF orientation (rotation information from digital cameras) should be used in images (edit)") is marked as resolved, and they are used.

However, as already noted in bug 6672, there are problems that images are effectively rotated, but the display uses the unrotated length/width, effectively strongly skewing the image. This problem is assumed to be fixed in bug 6672, but at least in 1.18alpha (r95811) it is not.

Two examples uploaded:

http://species-id.net/openmedia/File:Test-tagged-rotation.JPG contains an original Canon-produced EXIF rotation tag and was uploaded unmodified.

It is displayed in portrait mode (YES... it is rotated...), but with the lenght/width settings in landscape mode.

For comparison, the same image without a rotation tag, directly rotated with jpg lossless rotation:

http://species-id.net/openmedia/File:Test-lossless-rotation.JPG

The bug is critical, it breaks using 1.18 on any site that uses images containing EXIF rotation tags.


Version: 1.18.x
Severity: critical

Details

Reference
bz30640

Event Timeline

bzimport raised the priority of this task from to Unbreak Now!.Nov 21 2014, 11:49 PM
bzimport set Reference to bz30640.

Bryan.TongMinh wrote:

r92246 fixes this for trunk, was tagged for 1.18, and then untagged by Sam for some reason without being backported to 1.18. Sam?

(In reply to comment #1)

r92246 fixes this for trunk, was tagged for 1.18, and then untagged by Sam for
some reason without being backported to 1.18. Sam?

To be honest, I have no idea. Retagged

Reedy added a comment.Sep 2 2011, 10:26 AM

(In reply to comment #1)

r92246 fixes this for trunk, was tagged for 1.18, and then untagged by Sam for
some reason without being backported to 1.18. Sam?

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/92246#c21794

That's why. It was originally not in 1.18, but we re-branched 1.18, so it was then included in the new 1.18

If the revision tagged for 1.18 is already in 1.18 due to rebranching, then it either does not fix the bug or a regression was created later.

See the examples given in the first report above. Still present in 1.18alpha (r95907).

Bryan.TongMinh wrote:

Can confirm breakage with this image on trunk as well.

Bryan.TongMinh wrote:

Probably caused by r92279.

Bryan.TongMinh wrote:

Patch that fixes logic errors in normaliseParams

There were some logic errors that the attached patch fixes. For some reason the unit tests were incomplete: they did not detect the errors I introduced in r92279.

I strongly suggest that proper unit tests are written before this is patch is applied. I may or may not have time to do this.

Attached:

I'll write some unit tests either tomorrow or over the weekend.

I made some unit tests and applied Bryan's patch in r96687.

Not yet fixed in 1.18alpha (r96692) this bug is about. Test using links in first report. Please keep open until actually in 1.18.

demon added a comment.Sep 9 2011, 9:11 PM

Bugs are closed when they're committed in trunk.

(Mounting frustration) - How to report bugs in mediawiki 1.18 then? The bug says 1.18, not 1.19alpha. Please, please, please, fix this also in 1.18...

(In reply to comment #12)

(Mounting frustration) - How to report bugs in mediawiki 1.18 then? The bug
says 1.18, not 1.19alpha. Please, please, please, fix this also in 1.18...

We fix bugs in MediaWiki, not bugs in specific versions of Mediawiki (in general. Its slightly different for 1.18 as 1.18 isn't released yet.). r96692 is currently marked for being included in 1.18 (Along with several other revisions). It will most likely be merged into 1.18 soon-ish assuming a reviewer doesn't find something wrong with it. (If you want to know when that happens, just watch the page for r96692. When it gets fixed in 1.18 there will be a follow-up revision listed in that page with a commit summary starting with MFT)

Keep in mind, 1.18 hasn't been officially released yet (not even in beta form), so there's going to bugs...

Re-closing as fixed, since it is fixed in trunk (1.19) (and 1.18 fairly soon).

(In reply to comment #13)

(In reply to comment #12)

(Mounting frustration) - How to report bugs in mediawiki 1.18 then? The bug
says 1.18, not 1.19alpha. Please, please, please, fix this also in 1.18...

We fix bugs in MediaWiki, not bugs in specific versions of Mediawiki (in
general. Its slightly different for 1.18 as 1.18 isn't released yet.). r96692
is currently marked for being included in 1.18 (Along with several other
revisions). It will most likely be merged into 1.18 soon-ish assuming a
reviewer doesn't find something wrong with it. (If you want to know when that
happens, just watch the page for r96692. When it gets fixed in 1.18 there will
be a follow-up revision listed in that page with a commit summary starting with
MFT)
Keep in mind, 1.18 hasn't been officially released yet (not even in beta form),
so there's going to bugs...
Re-closing as fixed, since it is fixed in trunk (1.19) (and 1.18 fairly soon).

Replace every time i said r96692 with r96687

Soonish, provided it is some days, is fine. But not allowing to record bugs in 1.18alpha is not really logical. This is a generic issue, I accept the bug (against all logic: the version says 1.18 and it is broken there) as closed.

We fix bugs in MediaWiki, not bugs in specific versions of Mediawiki

Does this mean, as soon as 1.18 is released, only bugs in the then-1.18wmf will be fixed (this happens all the time for 1.17) but never for 1.18 again?

Most things we found broken in 1.18alpha are the extensions, and I already received the answer that they will not be fixed at all. Searching for a usable mediawiki version is frustrating...

Keep in mind, 1.18 hasn't been officially released yet (not even in beta form),
so there's going to bugs...

I know and we volunteer to help getting it tested, trying to find a usable version of mediawiki. 1.16 does not work anymore with several extensions that we need. If you want others to help you with finding bugs in 1.18, please help those trying to use it.

Soonish, provided it is some days

It would probably be in a couple days.

Does this mean, as soon as 1.18 is released, only bugs in the then-1.18wmf will
be fixed (this happens all the time for 1.17) but never for 1.18 again?

Traditionally it has to be a fairly major bug for there to be a new (minor version) release. For example security issues would result in another 1.18 release. Hopefully the delay between 1.18 and 1.19 will be less to compensate for that. The generally idea of MediaWiki development is that there is one version that is continually improved, and a snapshot is made of it every once and a while that is tested and released.

I know and we volunteer to help getting it tested, trying to find a usable
version of mediawiki. 1.16 does not work anymore with several extensions that
we need. If you want others to help you with finding bugs in 1.18, please help
those trying to use it.

And we're glad you are testing it and reporting bugs :) If there is stuff you think we could do to make tester's lives easier I'd love to hear/discuss. This isn't really the right place to discuss it though, but feel free to send me an email or leave a message on my talk page (or perhaps bring it to a more general forum. I'm not sure which one would be most appropriate though).

Reedy added a comment.Sep 9 2011, 11:22 PM

(In reply to comment #15)

Soonish, provided it is some days, is fine. But not allowing to record bugs in
1.18alpha is not really logical. This is a generic issue, I accept the bug
(against all logic: the version says 1.18 and it is broken there) as closed.

We fix bugs in MediaWiki, not bugs in specific versions of Mediawiki

Does this mean, as soon as 1.18 is released, only bugs in the then-1.18wmf will
be fixed (this happens all the time for 1.17) but never for 1.18 again?
Most things we found broken in 1.18alpha are the extensions, and I already
received the answer that they will not be fixed at all. Searching for a usable
mediawiki version is frustrating...

Keep in mind, 1.18 hasn't been officially released yet (not even in beta form),
so there's going to bugs...

I know and we volunteer to help getting it tested, trying to find a usable
version of mediawiki. 1.16 does not work anymore with several extensions that
we need. If you want others to help you with finding bugs in 1.18, please help
those trying to use it.

I'm not sure where you get the idea that we don't fix bugs in older versions. If they are reported, and a fix is put into trunk, it will be backported. If we don't know it's broken, it can't happen.

For example see http://svn.wikimedia.org/viewvc/mediawiki/branches/REL1_17/phase3/RELEASE-NOTES?revision=96559&view=markup

Many changes since 1.17, not released yet, granted, but they're there.

For security fixes, supported versions will be tested and the fix backported

Anything fixed in 1.17wmf1, will usually have been fixed in trunk first (unless the issue doesn't exist there). Usually revisions will then come into 1.17 when appropriate, but this doesn't always happen. Ask, and someone will do it if it's percieved useful - new features won't be backported

Look at the revision http://www.mediawiki.org/wiki/Special:Code/MediaWiki/96687

It's tagged to be backported to 1.18, so when it's been reviewed, it'll be triaged and very likely merged back again

I'm not sure where you get the idea that we don't fix bugs in older versions.
If they are reported, and a fix is put into trunk, it will be backported.

Many thanks for the discussion! I don't want to go on your nerves, and I probably do, but somehow I feel something is wrong. I assume what Bawolff said: "We fix bugs in MediaWiki, not bugs in specific versions of Mediawiki [...] Its slightly different for 1.18 as 1.18 isn't released yet." is not to be taken literal, right? (I first did.) So bugs are welcome for older versions, they may be fixed, but there is no control of this, because a bug will be closed as soon as it is ok in trunk, is that it?

In this example, if you close specific 1.18-bugs as soon as trunk is fixed, there cannot be any testing whether it indeed is fixed in 1.18, e.g., whether the merger worked or not. I may keep a note independent of the bug report system in my private calendar to check. Those interested in the production or soon-to-be-production, rather than development version would probably all prefer to be able to check once a bugreport is closed. But I readily admit that you probably have good reasons to do it so and that there may simply be no solution that satisfies all. I am project manager, responsible for end-user-functionality, not a developer, as you may guess.

ASIDE: The question why I wondered about fixing 1.17 may be perhaps more related to extensions, while you refer to mw core. To us, the extensions are just as vital as mw core. I see many of problems that we would need having fixed are working ok on the Wikipedias, but not in the 1.17svn we tried.

Reedy added a comment.Sep 10 2011, 1:16 AM

(In reply to comment #18)

I'm not sure where you get the idea that we don't fix bugs in older versions.
If they are reported, and a fix is put into trunk, it will be backported.

Many thanks for the discussion! I don't want to go on your nerves, and I
probably do, but somehow I feel something is wrong. I assume what Bawolff said:
"We fix bugs in MediaWiki, not bugs in specific versions of Mediawiki [...] Its
slightly different for 1.18 as 1.18 isn't released yet." is not to be taken
literal, right? (I first did.) So bugs are welcome for older versions, they may
be fixed, but there is no control of this, because a bug will be closed as soon
as it is ok in trunk, is that it?
In this example, if you close specific 1.18-bugs as soon as trunk is fixed,
there cannot be any testing whether it indeed is fixed in 1.18, e.g., whether
the merger worked or not. I may keep a note independent of the bug report
system in my private calendar to check. Those interested in the production or
soon-to-be-production, rather than development version would probably all
prefer to be able to check once a bugreport is closed. But I readily admit that
you probably have good reasons to do it so and that there may simply be no
solution that satisfies all. I am project manager, responsible for
end-user-functionality, not a developer, as you may guess.
ASIDE: The question why I wondered about fixing 1.17 may be perhaps more
related to extensions, while you refer to mw core. To us, the extensions are
just as vital as mw core. I see many of problems that we would need having
fixed are working ok on the Wikipedias, but not in the 1.17svn we tried.

Any extensions that are used by the WMF are actively maintained, as are a few select others. Most developers will update code in them when they go about deprecating old code and such.

Usually a bug is reported against a specific version, and more often than not, it's still evident in trunk. So trunk is usually the first place it is fixed. It will then depend on the severity of the bug, and somewhat, upto the commiter, as to whether this will make it back into an older version.

The comment about closing 1.18 bugs when fixed in trunk, is usual. Many places do this. Very often a simple backport will fix this in the older version aswell. Granted, this isn't always tested. If the "fix" was backported, and then it was still an issue on the branch, reopening the bug would be feasible.

As 1.18 is going under stabilisation, it is very like to receive any and all applicable bugfixes, but this never happens instantly.

If things aren't tagged for merging to other branches, or similar, please feel free to explicitly ask for it. Usually this will be fine, but if there is some specific reason why this cannot/will not happen, someone would then respond in kind. Asking on the actual fixing revision might be more helpful, then if it doesn't get tagged before, users reviewing it later may tag it, or just do the merges

Thanks for the discussion here. I'm going to synthesize this at [[mw:Bug management/How are bugs fixed]]

Gilles moved this task from Untriaged to Done on the Multimedia board.Dec 4 2014, 10:03 AM
Restricted Application added a project: Commons. · View Herald TranscriptAug 9 2016, 3:50 AM
Restricted Application added subscribers: TerraCodes, Matanya. · View Herald Transcript
Restricted Application added a subscriber: Jay8g. · View Herald TranscriptApr 13 2017, 3:54 PM