Color picker for Building/Roof color

[RubenKelevra]

Use case Currently the color of a building/roof need to be estimated by eye. Apart from the limited list of colors, which are hard to match to the real world, this is often weird, as there are very little differences between some colors, say lightgrey vs #cccccc, lightyellow vs beige, grey vs #708090 making me often wonder what to choose.

Proposed Solution There's a neat app called Color Picker where you can average the color directly from the camera image, with a configurable circle size.

It would be nice if SCEE could work together with the App dev of the app, to have the app called like the Measure app, and if the user taps on the color copy button below, the color is copied back to SCEE (either as RGB color or as color name).

[Helium314]

I don't remember exactly, but I think there were good reasons not to allow arbitrary colors in the building/roof color quests.

[rusty-snake]

The problems with picking from camera are:

• depend on (day)light conditions
• depend on device camera color "correction"

I agree that the current mixed palette is very confusing.

[mnalis]

Yeah, few presented choices are similar/confusing... I'd go with cleanup there of that few circled values there, but remain with small fixed palette using mostly (and preferably only, if possible) English names (instead of hex-RGB colors) as values.

One could use taginfo to find popular values for that and similar tags (ignoring those present in SCEE, as those are obviously incorrectly self-reinforcing), and see how the list could be modified in BuildingColour.kt and RoofColour.kt

[meiphoo7-Mae]

This attracted my attention, because I'm also struggling with this and therefore I usually ignore this matter. I feel the color of something is largely opinion based and dependent on several factors (time of the day, natural or artificial lighting and who knows what else). Still it fascinates me so I've looked up how the Vespucci app tackles this. To my surprise it offers only the colors: blue, brown, yellow, grey, red, white and black or the user can type whatever they see fit. TBH: I like this. The difference between these colors is pretty clear and if they're not appropriate in rare cases there's always the free choice available.

[mcliquid]

My first thought was to be able to choose between the CSS Web Colors. But after looking at them, I doubt the prevalence of these colors in house facades. (https://www.w3.org/TR/css-color-3/#html4)

At least in German-speaking countries, RAL colors are widely used for facade paints. But there are thousands of colors here. That would be too many. There are already 216 shades in the Classic color palette. (https://www.ral-farben.de/alle-ral-farben) (https://de.m.wikipedia.org/wiki/RAL-Farbe)

But perhaps a selection can be defined from the Classic colors?

[RubenKelevra]

The benefit of using a color picker is that it already comes with a built-in palette (see link below), matching the selected color to the closest available shade. Instead of copying RGB hex codes, we could simply fetch the color name.

In terms of accuracy, 10 phone cameras are likely to produce more consistent results than asking 10 people to manually select from a palette of 200 color options. Modern phone cameras are highly reliable.

To address lighting, we could make this quest time-based, avoiding color mapping at night, which wouldn't make sense regardless of the method used.

@mcliquid well, RAL is copyright protected. We can't use it. See first sentence in your link: "Die technischen Werte der dargestellten RAL Farben sind urheberrechtlich geschützt."

Edit: I forgot the link to the color palette the app uses:

https://en.wikipedia.org/wiki/List_of_colors_%28alphabetical%29

[RubenKelevra]

Maybe @gmikhail could weigh in here — would you be open to adding a feature that returns the color name when your app is called?

[meiphoo7-Mae]

A little philosophy: Let's assume you encounter a road that's not surveyed by someone else. There's a quest about the surface of the road. The surface is clearly made out of paving stones, so that's the answer to the quest. But hey, wait a minute... There are dozens of types of paving stones. So you're going on your knees to measure if the stone is 10 X 2.5 cm to distinguish it from stones that are 9.6 X 4.5 cm? Well, I don't think so, because the answer "paving stones" is sufficient. So why is it so important to distinguish one shade of color from the probably 43493 very similar other shades of the same color? A paving stone is a paving stone and likewise a color is a color.

[mnalis]

would you be open to adding a feature that returns the color name when your app is called?

Before people invest effort, I should warn that I'm heavily against SCEE (being FOSS) depending or even recommending using 3rd party non-FOSS apps in order to solve a quest, especially if there is no way to solve a quest without external app.

And unless I'm wrong, suggested app does not look FOSS. In other words, I don't want SCEE getting F-droid anti-features flags because we promote some closed source software, nor SCEE being associated with such practices. If we go the way of external color-picker app, it should be one maintained and available on f-droid at the very least.

The benefit of using a color picker is that it already comes with a built-in palette (see link below), matching the selected color to the closest available shade.

I'm dubious how well it would work. Think different daylight conditions. Have you tried it? What RGB colors do you get of the same roof on sunny day, cloudy day, at dusk and at early dawn at the very least? I doubt you get the same, or even similar, values. Now try with different camera softwares and with different phone hardware.

Perhaps if the color palette is very small, error rates might be comparable to human.

[...] matching the selected color to the closest available shade Instead of copying RGB hex codes, we could simply fetch the color name.

RGB hex codes are definitely bad idea; so using color name would be less bad. But still I prefer humans and the small fixed palette to such external apps, but even if we found FOSS external app which is suitable, I'd say:

• color picker / measurement app should be freely available on F-droid at least (and Google Play & Huawei etc.; not to mention soon also on iPhones)
• it should still match to the closest color in small fixed color palette (e.g. 16-color one)
• there should still be interface for solving quest without external app (e.g. like measurement quests work if AR software is not available)

In terms of accuracy, 10 phone cameras are likely to produce more consistent results

^{[Citation Needed]}

than asking 10 people to manually select from a palette of 200 color options. Modern phone cameras are highly reliable.

That is why trying to match 200-color palette is horrible idea (for computers or humans). It is madness trying to match if something is "Cerulean frost" or "Carolina blue" or "Dark sky blue" or "Glaucous", even with studio equipment and stable unchanging known CRI; much less in varying outside conditions.

We should stick to say 16-colors fixed palette. Then human can then perhaps make a mistake between (dark shade of) "red" and "brown" at dusk.

To address lighting, we could make this quest time-based, avoiding color mapping at night, which wouldn't make sense regardless of the method used.

That is way too simplistic... you'd at the very least need to carry sheet of white paper with you at all times, and do AWB calibration on it (after properly positioning it to avoid shades/creases) every time lighting condition change (i.e. few hours pass, or sun becomes occluded by clouds etc.). That is hugely impractical, and without it AutoWhiteBalance sucks even for regular photography; and is horrible for attempting color matching.

To my surprise it offers only the colors: blue, brown, yellow, grey, red, white and black or the user can type whatever they see fit. TBH: I like this. The difference between these colors is pretty clear and if they're not appropriate in rare cases there's always the free choice available.

I like that too. Very small color palette is absolute requirement for even attempting to claim any kind of verifiability. Rule of thumb: if you cannot recite whole palette by names from memory, it's too big.

[mnalis]

So why is it so important to distinguish one shade of color from the probably 43493 very similar other shades of the same color?

Yes, it is impossible, so a very small palette must be used.

A paving stone is a paving stone and likewise a color is a color.

It's even worse than that. While you can precisely and verifiably measure a paving stone[^0] and results will come the same every time[^1], you can't do that with colors, not even close. Every time some mapper try they'll get a different result then you. Only protection against that is making the scale more and more coarse (i.e. the palette smaller and smaller) until such verifiability errors disappear / become negligible.

[^0]: As evidenced by a plethora of paving_stones sub-tags :smile: [^1]: well, technically it won't be exactly the same, but the errors will be so small they'd be the same for all practical purposes. It might 23.007mm one time and 22.997mm another time, but you'll write it down as 23mm either way.

[gmikhail]

Maybe @gmikhail could weigh in here — would you be open to adding a feature that returns the color name when your app is called?

First of all, I'm glad you liked my app. In the Color Picker settings, you can enable the function of automatically copying the HEX color value to the clipboard after pressing the button. Then you can paste it into any app as plain text. The color name is not copied for the sake of universality.

Before people invest effort, I should warn that I'm heavily against SCEE (being FOSS) depending or even recommending using 3rd party non-FOSS apps in order to solve a quest, especially if there is no way to solve a quest without external app.

You are right that Color Picker is not FOOS, but the built-in palettes that come with the app are free to use. In the Color Picker settings, the palette sources are specified. The source for the palettes was mainly Wikipedia: https://en.wikipedia.org/wiki/List_of_colors_(alphabetical)

---

From the discussion, I understand that you are looking for a simple and universal way to specify the color of the roof.

I am not familiar with the project in question, but if you can't specify the HEX color value manually, it's better to use a predefined color palette with a limited number of colors. As @mnalis suggested earlier.

You can use either a ready-made palette, like HTML Colors or use your own simplified palette based on spectral colors: chromatic colors (primary colors of the rainbow) + achromatic colors (black, white, gray):

Red #FF0000 Orange #FF8000 Yellow #FFFF00 Green #00FF00 Cyan #00FFFF Blue #0000FF Violet #8000FF Black #000000 White #FFFFFF Gray #808080

You might also want to take a look at the 2014 Material Design palette: https://m2.material.io/design/color/the-color-system.html If you take a shade as a basis for each color, for example, 500 (used by default to represent the color in the first iteration of the palette: https://m1.material.io/style/color.html#color-color-palette), then you get 21 colors in total:

Red 500 #F44336 Pink 500 #E91E63 Purple 500 #9C27B0 Deep Purple 500 #673AB7 Indigo 500 #3F51B5 Blue 500 #2196F3 Light Blue 500 #03A9F4 Cyan 500 #00BCD4 Teal 500 #009688 Green 500 #4CAF50 Light Green 500 #8BC34A Lime 500 #CDDC39 Yellow 500 #FFEB3B Amber 500 #FFC107 Orange 500 #FF9800 Deep Orange 500 #FF5722 Brown 500 #795548 Gray 500 #9E9E9E Blue Gray 500 #607D8B Black #000000 White #FFFFFF

I still use the Material Design color palette from 2014 in many things and am happy with its simplicity and variety.

A small note: In the third (current) iteration of Material Design, Google abandoned the pre-defined color palette and modern palettes are generated based on any selected color. Therefore, in the latest documentation, this particular palette is not mentioned.

[RubenKelevra]

While you can precisely and verifiably measure a paving stone and results will come the same every time, you can't do that with colors, not even close. Every time some mapper try they'll get a different result then you. Only protection against that is making the scale more and more coarse (i.e. the palette smaller and smaller) until such verifiability errors disappear / become negligible.

There's a limit to this. If you reduce it to two colors, like black and white, no one can confirm it. The current palette is similarly unbalanced—too coarse in some areas, too fine in others.

A refined, verifiable palette, like the one on Wikipedia, could work since it organically grew from people's desire to differentiate colors. But with so many colors, it's tough for humans to handle. That's where the app comes in.

If you take a picture of a house with 10 modern phones, the colors will resemble reality much more than if a person manually selects it.

Plus, the human isn't completely out of the loop. You get a preview of the color the app chooses, and you can confirm it if it looks right to you.

Here’s an example of how the app's chosen color compares to a natural looking camera view:

@mnalis wrote

Before people invest effort, I should warn that I'm heavily against SCEE (being FOSS) depending or even recommending using 3rd party non-FOSS apps in order to solve a quest, especially if there is no way to solve a quest without external app.

This sounds a lot like how Microsoft viewed open source as a "cancer" two decades ago, just reversed. I strongly disagree. I use plenty of free software, but I also see no problem using proprietary tools when they work better.

I’m not suggesting we replace the manual palette. Instead, like the Measure app in SC, we could offer a button that lets users open the external app when needed.

[RubenKelevra]

@gmikhail thanks for taking the time to respond - much appreciated!

Maybe @gmikhail could weigh in here — would you be open to adding a feature that returns the color name when your app is called?

In the Color Picker settings, you can enable the function of automatically copying the HEX color value to the clipboard after pressing the button. Then you can paste it into any app as plain text. The color name is not copied for the sake of universality.

You noted that HEX values are used for universality, but in this case, the universality of color names might be more useful than 8-bit RGB.

This project already has two apps: StreetComplete (and its variant, SCEE) and the Measure app, which helps with measurements using ARcore. My suggestion is to follow the same approach with your app for color: SCEE could trigger your app, which would return the color name instead of the HEX value.

Hope this makes sense!