The background in general should not be black in the first place (too dark, but there's also a related bug about it causing problems with black images), and using a light checkered background for the transparent images is also very jarring against this, resulting in a very hard, high-contrast line. The background for everything should be a single, more neutral colour, with some sort of indicator where the image edges are, applied to all images. One of the purposes of even having a transparent background is that an image can then be stuck on anything, usually seamlessly, and this just negates that.
Wait, crap, mmv isn't actually using oojs, is it?
Eh, just set the general background to something like #444 (maybe make it all checkered with 555 or something?) and then add a border on hover. Thick blue (progressive?) would be consistent with standards used in oojs.
MMV is using OOJS but you probably meant OOUI, and it's not using that (for the canvas, at least) because it's rather large. In any case, the file selector wizard in VE is the only relevant OOUI-based feature I can think of, and that just uses white backgrounds and adds a border, which looks ugly for partially transparent images (not really a problem for an image picker, bit would be for an image viewer).
The checkered pattern was added due to T59620. Adding a solid background color generally has the same issue (plus, non-black surroundings tend to be more ugly for photos). Hover is not particularly useful to rely on for an image viewer + not supported on all devices.
Calculating a background color dynamically based on some sort of image processing was suggested, but it seems like a lot of effort for questionable results.
Using a black baground for anything is usually a poor design choice,
photos included. The very high-contrast hard edge against ALL
transparent or partially-transparent images only makes it worse, but it
will affect any image with a light background.
That's the problem, and why I filed this task, but I really don't care
enough to try to solve it for you when all you're going to do is fight me.
I don't think I've been combative at all, I just tried to summarize the history of this issue in MMV. But in general you should not open tasks that you are unwilling to explain or argue for. There is no shortage in people with strong opinions and high horses in MediaWiki development, and it's usually not easy determine the level of clue. MediaViewer went through a design review and seems to be mostly in line with what other websites do (Flickr for example does display bright images on a black background), so Joe Random showing up and saying that it looks horrible is unlikely to be reason enough in itself to write (or even accept) a patch.
Sorry! I am prone to high-horsing myself. In a couple weeks the Multimedia team will move to Reading, and will probably become the maintainers of MediaViewer, so I guess I should just leave subjective decisions to them.
(As for the other tasks, I think what you are asking for in T161346 is already there, but maybe I'm just misunderstanding what you are asking for, so a more bug-report-style description would help. And T72933 just does not seem useful to me in 2017. Maybe I just don't understand the browser landscape well enough.)
The current checkered background doesn't work at all for transparent images with white text like https://commons.wikimedia.org/wiki/File:Romney-Ryan_2012_logo1.png. Maybe look at the average value of the image and select a darker checkered background if it's near white?
I actually really like this idea - programmatically set the background to a colour calculated from the content of the image itself, if colours not already varying a lot. Would something like that be feasible?