In T26070#8401685, @Ladsgroup wrote:

I don't know if it should be a blocker or not but the dark mode being used in mobile frontend leads to scary pictures in search:

(it might not be a blocker as mobile is a different skin altogether?)

The solution here is to either add the classes used by the widget to the non-inversion selector, or to add the standard mw-no-invert class to the images.

The latter is a much better way to do this. Darkmode should not have to maintain a list of CSS classes by every extension that uses background images.

Filed as T345281

Do we really need years to modify a simple CSS? I wonder what the priorities are. Or are you guys applying the bad practice of if something works, don't touch it?

In T26070#9131701, @Esanders wrote:

In T26070#8401685, @Ladsgroup wrote:

I don't know if it should be a blocker or not but the dark mode being used in mobile frontend leads to scary pictures in search:

(it might not be a blocker as mobile is a different skin altogether?)

The solution here is to either add the classes used by the widget to the non-inversion selector, or to add the standard mw-no-invert class to the images.

The latter is a much better way to do this. Darkmode should not have to maintain a list of CSS classes by every extension that uses background images.

Just invert image colors for png/svg/icons and not for jpeg our photographs

Thanks for pointing it, I though I was the only one to think about just inverting colors. I really don't think they thought of this option, thanks for the hint. I tried on Google, Bing and DuckDuckGo and I confirm that searching "wikimedia foundation dark night mode invert" will not display a Dark mode is coming blog post.

Also, this non-existent blog post doesn't contain this ghostly paragraph on the subject of technical motivations and never-before-studied issues:

Editors control content which includes templates: amboxes, infoboxes, navboxes, as well as bitmaps, timelines, tables, and more. Some of those, like weather and sports tables, use colors in a meaningful, or semantic, way. Simply inverting these colors would immediately lose their meaning. We need to find other options.

Just hallucinations!

We need stability for communication to communities: are we talking about a night mode, or a dark mode? I read MediaWiki-extensions-DarkMode. But the WMF wrote this page: recommendations for night mode compatibility on Wikimedia wikis, initially named recommendations for dark mode compatibility on Wikimedia wikis. Also, the WMF published the "Dark mode is coming" blog post 4 days before the recommendations page rename.

I might being nitpicky here, but you know how noisy communities discussions can be.

@Lofhi https://www.mediawiki.org/w/index.php?title=Reading/Web/Accessibility_for_reading/Frequently_asked_questions#Why_is_it_called_%22Night_mode%22_and_not_dark_mode?

Corrected link: https://www.mediawiki.org/w/index.php?title=Reading/Web/Accessibility_for_reading/Frequently_asked_questions#Why_is_it_called_%22Night_mode%22_and_not_dark_mode?

On the subject of inverting colours, it is worth noting that while we try to uninvert colours of photographs with mw-no-invert, due to the way CSS hue transforms are calculated this always results in some distortion of the colours[1][2]. While this is subtle and acceptable for photographs, it is not really acceptable for instances where the colour is the information, e.g. on https://en.wikipedia.org/wiki/Pantone#Color_of_the_Year:

Original	Double inverted
	Note the slightly darker red of the shirt:
	2002, 2007, 2009 in particular:

1. https://stackoverflow.com/questions/76164156/css-revert-filter-with-invert1-and-hue-rotate180deg
2. https://stackoverflow.com/questions/19187905/why-doesnt-hue-rotation-by-180deg-and-180deg-yield-the-original-color

Thanks @Esanders !

Feel free to add any of this context to the existing FAQ question if you think it would be helpful!

There is something I don't understand @Esanders. Why are you uninverting the CSS filter on images? I will ask a very dumb question: why not using the not CSS selector to exclude img? For old browsers support?

In T26070#9131701, @Esanders wrote:

The solution here is to either add the classes used by the widget to the non-inversion selector, or to add the standard mw-no-invert class to the images.

The latter is a much better way to do this. Darkmode should not have to maintain a list of CSS classes by every extension that uses background images.

A newly-available solution here would be to use machine learning to classify images by whether they should be inverted. It is easy for a NN, for example, to recognize that those old photographs with faces should not be inverted even though their general lack of color would make them a good inversion candidate by most inversion heuristics.

A proof of concept of this as an API is now live at InvertOrNot.com, which uses a FLOSS-licensed NN (trained in large part on Commons images) to classify images by inversion status. It is pretty accurate, and only takes ~0.1s/image on a CPU & <20MB space, so running it at scale is possible.

I have been using it on my website mostly for improving the appearance of Wikipedia thumbnails in dark mode, and it has been working well. (InvertOrNot.com caches the classification; so we implement it as a background call on loading a WP article, and so if it's not fast enough to return the classification in time the first time an article is loaded, oh well, fall back to conservatively dimming the image, and its classification will be ready in time the next time.)

While it won't be perfect, error cases could be contributed upstream and the model updated eventually, in addition to marking them explicitly as invertible/non-invertible. (I would also point out that reliance on an API to classify images by URL would help avoid issues like double inversion where people or code loses track of metadata being threaded deeply throughout overlapping distant codebases and whether to negate or negate the negation etc.)

Thanks for sharing @Gwern, and for you work. It's undeniably a high-quality tool that could be shared with communities. Is it possible to host an instance on Toolforge? It would so appear on Toolhub.

@Gwern wonderful application, and agreed that this should be by URL and not by chain-of-reasoning.

In T26070#9667513, @Lofhi wrote:

Is it possible to host an instance on Toolforge? It would so appear on Toolhub.

Thanks, but I'm afraid I don't know what Toolhub is or what software it can easily host. I don't believe the developer, Mattis Megevand, uses anything particularly exotic: as you can see in the Github repo I linked, it's just PyTorch to train and Onnx to run/serve the model. So if Toolhub supports any nontrivial ML/DL tools from the past few years, I'd expect it to be able to host an instance...?

Megevand would be pleased to see Wikipedia use of InvertOrNot, so if there are any problems he can fix upstream, I'm sure he'd be happy to try to help.

Hello, as @Gwern said I would be happy to help.
Only requirements is to be able to use ONNX and NumPy, also as Gwern mentioned the model isn't perfect however it will improve over time.

The main challenge with automatically inverting any kind of image is that on our wikis there are many images which are semantically tied to non-images: for example consider a map of Europe with a key defined in a table where the table has colors that refer to parts of the map. In this situation if the map gets inverted, it now does not correspond with the key. For this reason, we have no plans to invert images at least in the initial version of the release.

I think any solution for marking an image as "invertable" should likely be done as part of the thumbnail processing as meta data perhaps as part of CommonsMetadata extension (which is maintained by another team than the one working on the night theme) - we'd need this information at time of rendering and doing it during rendering for all images would be too expensive so it will need to be cached.

you might try a mixture-of-classifiers, which all have an 'uncertain' range between yes and no:
0 - is precise color the point?
1 - does inversion look good in dark context?
2 - is there a color key in the text?
3 - other (non-standard inversion?)

@Gwern do you have a test set of images that are tricky and in particular need of care, for benchmarking?

You might like to ask community members dealing with the graphics in their project for advice.

you might try a mixture-of-classifiers, which all have an 'uncertain' range between yes and no:

Yeah, it's possible that more complicated categorizations will be necessary, but I'm not convinced it is yet. Even in the example of colored maps with separate keys - a colored map, which is colored by semantics, is something that can be recognized on its own without access to the key, necessarily. A colored map is clearly not 'just' a map, particularly if the coloring does not simply line up with the standard national boundaries. (In fact, if you're using something like CLIP, the model may have been pretrained *on* that pair already as WMF wikis will contribute a lot of paired data.)

do you have a test set of images that are tricky and in particular need of care, for benchmarking?

I don't because every time I have an error I just send it to Mattis (there's an API for reporting errors) and it gets added to the training data. I believe the current model doesn't reach 100%, so those could be used for testing.

Thanks gwern. I can see a single classifier working for our purposes, if it supports an 'uncertain' middle ground. just need to tweak where the threshold is drawn.

This will become resolved when we roll out dark mode on mobile this week so adding to sign off

This will become resolved when we roll out dark mode on mobile this week

Yaaaay! 🎉

I hope I've added the subtask above correctly. If not, excuse me and please revert it.

Is dark mode available for the Timeless skin?

@LikeLifer: See https://www.mediawiki.org/wiki/Manual:Dark_mode#Forcing_dark_mode_temporarily

Is dark mode available for the Timeless skin?

No Timeless is not in active development. There are no plans to add dark mode for this skin.

In T26070#10026321, @Aklapper wrote:

@LikeLifer: See https://www.mediawiki.org/wiki/Manual:Dark_mode#Forcing_dark_mode_temporarily

The query string here won't work but this page does list other options you have for Timeless skin.

Do you think a separate task would be warranted for dark mode Timeless? I hope so, because Vector 2022 still has problems with stuff like responsive design that has prevented me from using it.

In T26070#10029066, @Awesome_Aasim wrote:

Do you think a separate task would be warranted for dark mode Timeless? I hope so, because Vector 2022 still has problems with stuff like responsive design that has prevented me from using it.

You can create one but Timeless has no active maintainers so it is unlikely to be worked on.

Please add dark theme to the "Vector legacy (2010)" skin.

In T26070#10029066, @Awesome_Aasim wrote:

Do you think a separate task would be warranted for dark mode Timeless? I hope so, because Vector 2022 still has problems with stuff like responsive design that has prevented me from using it.

It is the same reason why I use it, timeless is the only skin with a responsive design.

@LikeLifer, that's off-topic for this ticket. If you experience a bug with Vector, file a separate issue about that.