The easiest solution which wouldn't have to be hardcoded for certain images would be to have the app's dark mode invert any image whose alt parameter begins with a "\". There should be almost no non-symbol images whose alt text would begin with a backslash.

Change 713814 had a related patch set uploaded (by Vadim Kovalenko; author: Vadim Kovalenko):

[mediawiki/services/mobileapps@master] Display issues with math articles in dark & black mode

https://gerrit.wikimedia.org/r/713814

@Ahecht a better solution would be to establish a common class for these templates that will be addressed by PCS (Page Content Service). How can we start a thread about adding a class to these templates? My proposal would be something like mw-template-math-image. I would avoid existing classes at first because of possible side effects, but maybe we can take advantage of some classes already being used by Math.

And in the templates, for example in Oiint, we would add the class to the file, like this:

... [[File:OiiintLaTeX.svg|x44px|alt=\oiiint|class=mw-template-math-image|link=]] ...

Then, we need to add the CSS rule for the new class, like this.

cc/ @vadim-kovalenko, @ssastry, @Jdlrobson and @Elitre (to give an opinion about this approach on requesting Templates changes to the community)

Related: T129054

This makes me wonder if a generic fix in the Math extension is warranted.

Related feedback via email from Dec 6

DESCRIPTION:

Many if not most diagrams, formulas, etc. with a dark foreground are (still) unviewable in a dark theme (some pages appear to have improved).

This appears to be due either to widespread use of transparent backgrounds or mapping of white backgrounds to the theme background color, without adjustment of foreground colors.

REPRODUCTION:

Use version 2.7.50387-r-2021-11-24 of the Android application with a dark display theme to view any page with embedded formulas and/or some types of diagrams.

The article on Floating Point Arithmetic is one example; as are many articles

Some articles with electronic circuit symbols may have been problematic in earlier versions: I'm having difficulty finding examples, now.

POTENTIAL SOLUTIONS:

I don't know whether developers have had time to give this much thought; but I've sketched out a few thoughts, below, that they're free to ignore entirely, provided something is done that neither forces contributors to tweak images manually not forces readers to use a bright theme where they would prefer dark.

Where possible, warning contributors when they have “overspecified" foregrounds (that could be left to default and thereby “just work”) and offering a one-time, automated correction might be preferable: these measures are intended for cases where the contributor is unavailable or considers such alteration inappropriate.

One, more appropriate treatment might be to adjust background color luminance in graphics to contrast sharply with median foreground luminance. This approach is likely to work well for images with a large variance in foreground luminance.

Another might be to adjust foreground luminance such that its median contrasts sharply with background luminance: this approach is likely to work well for formulas rendered on the fly (e.g., MathJax, LaTeX) and for images with a small variance in foreground luminance.

For that matter, formulas not could simply be rendered at the extreme of luminance most different from the theme background (keep in mind perceived brightness and contrast are logarithmic, so the threshold to prefer bright text may not be 50% theme background luminance).

Adjustments (or adjusted copies, if foreground is adjusted) for a coarse set of theme background luminances could be computed and stored at time of update (or of feature implementation), to avoid retrieval and display bottlenecks. Of course, foreground adjustment may have a higher storage cost, since background adjustment can be left to alpha transparency and local rendering, without exceptional run-time cost.

Naturally, images with wide dynamic range and relatively smooth luminance distribution (as in photographs) might be best left unadjusted, other than by existing image dimming.

Another email about this in chore wheel.

Change 713814 abandoned by Vadim Kovalenko:

[mediawiki/services/mobileapps@master] Display issues with math articles in dark & black mode

Reason:

This fix probably should be applied to the Template:Intorient itsel + patch doen't solve the broader theme issue problem.

https://gerrit.wikimedia.org/r/713814

In T182128#7300575, @MSantos wrote:

@Ahecht a better solution would be to establish a common class for these templates that will be addressed by PCS (Page Content Service). How can we start a thread about adding a class to these templates? My proposal would be something like mw-template-math-image. I would avoid existing classes at first because of possible side effects, but maybe we can take advantage of some classes already being used by Math.

And in the templates, for example in Oiint, we would add the class to the file, like this:

... [[File:OiiintLaTeX.svg|x44px|alt=\oiiint|class=mw-template-math-image|link=]] ...

Then, we need to add the CSS rule for the new class, like this.

cc/ @vadim-kovalenko, @ssastry, @Jdlrobson and @Elitre (to give an opinion about this approach on requesting Templates changes to the community)

I attempted to abuse class=mwe-math-fallback-image-inline for this, but it didn't work. The reason it doesnt work is that the styling applied by pcs is specific to img.mwe-math-fallback-image-inline but with Parsoid the classes applied from wikitext to an image, are now applied to the wrapper and no longer to the image directly.

I also discovered the (undocumented, now fixed) class "notheme" but unfortunately, that doesn't work as here we want actually explicitly opt-in to the theming (we want the colors to flip, even though normally they should not flip).

I did fix this template for usage in combination with the dark mode gadget btw.