"The map appears washed out, more contrast wanted"

[jeisenbe]

Issue

According to @kocio-pl, some map users have been complaining that the current rendering appears "washed out", and there "more contrast [is] wanted". See this comment: https://github.com/gravitystorm/openstreetmap-carto/issues/3635#issuecomment-453684493

• "Washed out" suggests what happens to watercolor paints when too much water is added, or the color of a faded article of clothing after many launderings.
• This may refer to a reduction in contrast between different area fills or between some of the background colors, linear features and icons.
• Perhaps the complaint is that there are too many areas with high lightness values now?
• There may also be a complaint that more colors are now unsaturated (gray or grayish)
• Note: this issue is not my personal complaint. I did not notice this issue myself). Rather this is a place to discuss what has been said by others and decide if it is a problem or not.

Possible causes

• A review of all the merged PRs in the past 3 years shows this list of pull requests which were related to the color of landcover, icons or linear features, and which may have reduced contrast and saturation or increased lightness.
• I have highlighted the PRs which are more likely to be related to this issue, in bold.

#3625 Allotments color and pattern 2 - changed from light green to less saturated, more blueish green #3548 Allotments color and pattern 1 - changed from orange-brown to light green #3536 Landcover low zoom cleaning - removed buildings, some roads and paths #3529 Change scrub color and pattern - slightly less blue and less saturated #3493 Render religious landuse and place_of_worship lighter - lighter color, lower contrast

3475 Rendering orange dots for gastronomy on z17 - smaller, less prominent icons

3470 Reduce noise of swimming pools at low zoom - probably not related

3467 Clean up z13 - removed buildings, some paths and minor roads from z13

3466 Render societal amenities like residential etc on mid zoom

#3444 Change color of apron in aerodromes - changed apron color from light purple to light gray #3412 Change societal amenities color - changed color to very light yellow #3327 Changing farmland and societal amenities colors - _switched societalamenities (lighter, less saturated) with farmland

3225 Brighten built-up areas on z12

3096 Making gardens to use grass color with plant nursery pattern - probably not related?

3085 Change label colour of private parking - Minor change, but text is lighter

#3057 Made military area rendering less prominent

2954 Change sports_centre and stadium color to [leisure] green - _Previously was same as societalamenities color

2949 Fix color for man_made icons - Changed some icons from black to gray

#2934 Make parking gray instead of yellow - New color is unsaturated, less prominent

2933 Clean up low-zoom levels

2835 Hide tiny zoos and theme parks - No longer rendered outline on small zoos

2707 Changing area color for railway=station - changed from #d4aaaa to @railway = @industrial

#2654 Improve mid-zoom levels and water color - made water color lighter, and added fading of landcover at z12 and below

2589 Render most shops on z17 as dots only

2574 Better outline color for societal amenities (hospitals, schools), adding missing outline for stadium/sports_centre - weaker outline color, so that it doesn't look like a barrier

#2515 Unification of major buildings - changed aeroway=terminal color from purple to brown #2363 Making pitch and track color less dominant

2292 Less dominant construction color desaturated and lightened the construction fill

2249 Different color for playground changed from green-blue to light green

#2071 Change and unify colors for stadium/track/pitch to be less dominating

Even earlier, the farmland color was changed from darker brown to lighter brown, but this PR was >3 years in the past.

• I personally approve of most of these changes, but those that are highlighted could be seen as making the rendering lower contrast and less saturated or lighter.

• #2654 is probably one of the main causes of this issue, and might be reconsidered now that we are rendering landcover much earlier than before.

Links and screenshots illustrating the problem

• @kocio-pl, I believe you have some before and after renderings from 2015 vs now?

[jeisenbe]

Related to:

3607 "Adjust societal amenity colors" - the color is currently too light

3517 "Coordinate shades of non-physical green areas (meta-ticket)" - which suggests that the @leisure color may be a problem. Perhaps it is too light / low contrast?

1863 "Usability : New map openstreetmap-carto is too pale" - September 2015

[jeisenbe]

My personal opinions:

1) In general, I approve of most of the changes in the past 3 years that may have reduced contrast or made some features lighter. Most have improved the appearance of the map while not hurting mapper feedback or map usability 2) After #2654, landcover colors fade out from z12 to z10, and then stay very faint at lower zoom levels. I believe this should be improved. 3) #3444 and #2934 made parking and apron areas neutral gray instead of colorful. While this is helpful in some ways, both of these colors are too close to land-color now, and could be improved. 4) #3412 made societal-amenities too light. We've been working on solving this in #3607. The easiest option would be to revert #3412, but a darker shade of yellow might work. 5) The leisure color is rather light, but I'm not sure how to improve it.

[Adamant36]

On 4, OsmAnd goes with yellow also for societal-amenities and it looks good there. So we might try going with something similar to their tone. They also have a better leisure green color that might be worth testing.

[kocio-pl]

@kocio-pl, I believe you have some before and after renderings from 2015 vs now?

This is a follow up to #1863 and while the analysis seems to be wide, we need some examples (with location) for different problems it tries to cover, lack of which was the reason to close that ticket. Then it's easy to get the code back to any previous release and make a rendering comparison with current data.

[polarbearing]

I have no general issue with landfill colours appearing "light" or "washed". IIRC it was intentional in this style, and makes detailed features - which then appear with more saturated colours - better visible. I'm not against fine tuning a thing here and there, but I don't want a squeaky high-contrast map.

[kocio-pl]

In general i like the current also, but after making (semi)natural areas visible from z5 I think it would be good to tune the mid/low zoom rendering and make the fading not that fast:

https://github.com/gravitystorm/openstreetmap-carto/blob/6684f0aeba571c01fb774530f3acc8f90b6aaaff/landcover.mss#L71-L83

It needs testing, but after that color areas on z5-z12 would be more saturated.

[meased]

The term "washed out" seems to be interpreted here as "background is too light".

But contrast is the difference between foreground and background colors, in our case increasing contrast would mean either darkening the foreground or lightening the background. We have a fairly dark foreground already (black in some cases), so to increase the contrast, we would have to lighten the background.

I think our "washed out" appearance is because our backgrounds are too dark, not too light. Probably a result of individual pull requests over the years all wanting to be noticed on a noisy map, and PRs can only darken themselves to get noticed, they can't lighten everything else.

[matthijsmelissen]

I think our "washed out" appearance is because our backgrounds are too dark, not too light.

I’m not quite sure what you mean here?

[meased]

I think our "washed out" appearance is because our backgrounds are too dark, not too light.

I’m not quite sure what you mean here?

Highest possible contrast is #000000 on #FFFFFF. As backgrounds compete for attention, they get darker (or, closer to foreground) and therefore, less contrast.

For example, I feel our landuse=residential color is too dark. It's very close to the building fill color. In #3426, the main reason minor buildings could not be added was that lightening buildings even a little resulted in them disappearing in landuse=residential.

[jeisenbe]

I think our "washed out" appearance is because our backgrounds are too dark, not too light.

I appreciate your observation and I think it is a valuable opinion to consider.

However, I don't believe it matches with the complaints that are expressed by this issue. The request for "more contrast" is probably(?) about wanting a clearer difference between the different backgrounds, rather than between the background colors and icons or linear features.

Highest possible contrast is #000000 on #FFFFFF

True, but we use both colors for linear features such as roads and bridges: a residential road on a bridge has a white fill with a black casing. Reducing the darkness of the background increases the contrast with the black bridge casing, but reduces contrast with the white fill. This problem can be seen on the current societal_amenities color used for schools and hospitals. It is very light (97, compared to 89 for residential) and white roads are harder to see, though the darker casing helps.

Reducing the darkness of all background colors also reduces the contrast between each type of background fill. I believe this is probably what people have complained about, though this is all second-hand.

I feel our landuse=residential color is too dark.

It's lightness is 89 out of 100. Objectively, this is rather light, which is appropriate for a background fill color.

It's very close to the building fill color.

The building color was changed several years back to be lighter. It used to have much higher contrast with all of the backgrounds fills. (Personally I would prefer the buildings to be less prominent on my local maps, by reducing the strength of the building outline, because many buildings here in Indonesia are very small, and the Mercator projection makes them appear even smaller near the equator, so that most of the building is outline all the way up to z17)

[meased]

Reducing the darkness of the background increases the contrast with the black bridge casing, but reduces contrast with the white fill

If white roads don't look good on lighter backgrounds, then they should look terrible on bare land, but I think they look fine.

Reducing the darkness of all background colors also reduces the contrast between each type of background fill.

We use hue to differentiate landuse, not contrast.

When I hear contrast, I think foreground/background contrast. But apparently, a lot of people are thinking land/landuse contrast, which is, of course, perfectly valid. As was pointed out with social amenities and residential landuses, we're all over the place here; one is barely visible, the other is blatantly obvious.

My main point is that the way this project is setup with PRs focusing on single issues, tweaking a single feature is easy, but a paradigm shift is very difficult. Let's say for example, we wanted to darken the land color and make landuse lighter than land. Too many things would have to change at once (potentially even road colors). Therefore, it is unlikely to ever happen, even if it is a good idea.

[matkoniecz]

Let's say for example, we wanted to darken the land color and make landuse lighter than land. Too many things would have to change at once (potentially even road colors). Therefore, it is unlikely to ever happen, even if it is a good idea.

That may be possible to achieve by running script over stylesheet that would (1) edit all color definitions (increasing saturation) (2) edit raster files in the same way.

I never did it because I am not convinced that it is an important problem. For example when I look at https://mc.bbbike.org/mc/?lon=20.015261&lat=49.242902&zoom=13&num=2&mt0=mapnik&mt1=osmfr&marker= I think that "washing out" made possible to spot and read labels.

Though I am sure that it heavily depends on computer screen one uses, light around it, eyesight and many more things.

[kocio-pl]

Indeed, French fork looks like prepared for mobile devices with a low quality screen (or in bad lighting conditions) - areas are very strong (except water), but details are missing:

[bdxd111]

I believe the french stylesheet is the same as an older version of carto from when the motorways were still blue. Anyway, the current stylesheet is defenitly an improvement over the french one.

Just to see what a less 'washed out' map could look like at z14:

Compared to the original colors:

[kocio-pl]

Just to see what a less 'washed out' map could look like at z14:

How did you create that effect?

[bdxd111]

In paint.net: First change levels to bring out the colors. Then increase the brightness to match the original image.

Apparently it still rembered the settings I used:

[matkoniecz]

I believe the french stylesheet is the same as an older version of carto from when the motorways were still blue.

Not exactly - it is older version of carto, with some their won changes added - but without nearly all carto changes since that time

[jragusa]

Wow, once compared to the "brightened" version, the current version looks really washed out. IMO, the "brightened" version is pleasant to see.

@bdxd111 could we have a similar example at z10 or z11 ?

[Adamant36]

the current version looks really washed out

I agree with that. The current version is pretty hard on the eyes. I have to do a lot of squinting to distinguish things sometimes. I really like the colors, but they really could be brighter.

[bdxd111]

Using same settings as above.

z11:

z10:

z9:

When looking at an area with a bit less green:

z11:

z10:

z9:

[jragusa]

Even at low zoom, the brightened version seems to me better. Note also the contrast between water body and landuses (e.g. National Park de Biesboch to the top left in the first pictures)

[matkoniecz]

If someone would be interested I may try writing script that edits all color definitions in text files of this style (not in image patterns) and applies some transformation to them - for example making the more saturated.

Note that

• to use this script one would need to be able to tweak and review style and this is not suitable for your first PR
• to use this script one would need to be able to run Python/Ruby scripts (it requires installation of software and may require using command line but there is plenty of documentation how it can be done on your system)
• it is likely that at least initial versions would be completely or partially broken and one will need to report what and how went broken ( https://www.chiark.greenend.org.uk/~sgtatham/bugs.html )
• it is certain that transformed style will require massive amount of testing and tweaking (for example it is unlikely that healthcare or shop icons should be even more saturated, it is likely that there are also other features that should be excluded from transformation or that transformed version of style will have some bugs)

[kocio-pl]

I guess this could be useful for style customization.

Some other script could be used for removing name labels, since there are repeating requests for "bare" tiles.

[vholten]

The transformation shown by @bdxd111 can be easily included in a script: new = 255*(old/255)^1.6 + 17 where this formula is applied to each of the R, G, and B values, and values above 255 should be clipped to 255.

Graph of this transformation (blue curve):

[jeisenbe]

and values above 255 should be clipped

That will create unpredictable colors On Wed, Jan 30, 2019 at 4:55 AM vholten notifications@github.com wrote:

The transformation shown by @bdxd111 https://github.com/bdxd111 can be easily included in a script: new = 255*(old/255)^1.6 + 17 where this formula is applied to each of the R, G, and B values, and values above 255 should be clipped to 255.

Graph of this transformation (blue curve): [image: osm-contrast-graph] https://user-images.githubusercontent.com/5209216/51935192-a7ca4c00-2405-11e9-96c6-986983b2d515.png

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gravitystorm/openstreetmap-carto/issues/3647#issuecomment-458684158, or mute the thread https://github.com/notifications/unsubscribe-auth/AoxshGPLpVgtLLJqv9M_61gHTPNTaAGUks5vIKdDgaJpZM4aHFCX .

[meased]

These brighten images look really good. I think it's worth noting that the bare ground color is a lot lighter in these images, which makes me happy.

(current:brightened)

I'm liking the more saturated water too.

[bdxd111]

and values above 255 should be clipped

That will create unpredictable colors

In this case it does not really matter because in the current rendering color values above 245 do not really exist. At high zoom levels at least.

The only exeption being white roads. But those will just stay white.

Edit: also checked for dark colors. Values smaller than 17 also seem to be very rare.

Edit: At lover zoom levels things like sand and farmland do get clipped.

[jeisenbe]

highway_raceway is pink; rgb(255,192,203)- red is 255 max

highway_footway is salmon; rgb(250,128,114)

Cycleway is blue Rgb(0,0,255)

These would get changed to rgb(255,178,194) and rgb(255,102,87) and blue would be unchanged at (0,0,255)

So salmon Lch(67,54,33) goes to Lch(63,69,34)

Pink Lch(84,24,8) to lch(80,30,6)

Blue Lch(32,134,306) is unchanged.

Also, consider green used for bridleways and some types of text label. This is rgb(0,128,0) so only the green value would change, from 128 to 102. But rgb(0,102,0) is a less saturated green: Green Lch(46,72,136), while the new darker green is Lch(37,61,136) - so the chroma is lower with green, unchanged with blue, and higher with pink and salmon after the script

This is the problem with using RGB: it doesn’t match the human eye, and changes don’t always do what you expect.

Joseph

On Wed, Jan 30, 2019 at 7:33 AM bdxd111 notifications@github.com wrote:

and values above 255 should be clipped

That will create unpredictable colors

In this case it does not really matter because in the current rendering color values above 245 do not really exist.

The only exeption being white roads. But those will just stay white.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gravitystorm/openstreetmap-carto/issues/3647#issuecomment-458734426, or mute the thread https://github.com/notifications/unsubscribe-auth/AoxshHoofeFGpg61ONAI556zXR7WmkJ9ks5vIMwegaJpZM4aHFCX .

[vholten]

I don't see any major problems with this RGB transformation. It is a contrast enhancement, all three RGB channels are changed in the same way, and there is no hue change. I don't think there is a reason in this case to do the transformation in Lch.

A slight disadvantage is that some information is lost due to the clipping for values higher than 244. The clipping can be avoided by changing the transformation for high values, for example:

if (old < 240) new = 255*(old/255)^1.6 + 17
else new = 0.5*(old - 255) + 255

If anyone wants to try this, here is a Python script (requires Pillow):

from PIL import Image

def newcolor(oldcolor):
    if oldcolor < 240:
        return 255*(oldcolor/255.)**1.6 + 17
    return 0.5*(oldcolor - 255) + 255

try:
    im = Image.open("org.png")
    new = im.point(newcolor)
    new.save("new.png")
except IOError as e:
    print("I/O error({0}): {1}".format(e.errno, e.strerror))

[imagico]

A bit of warning here:

Always be careful when assessing colors based on PNG images unless you know exactly what you are doing. The screenshots shown by @bdxd111 have different ancillary chunks and will not display correctly in many web browsers.

When you generate screenshots to publish them here you should always try to generate them without any gAMA, cHRM, iCCP or sRGB chunks and without any color management messing with the pixel values in either displaying the tiles or making and processing the screenshot. When in doubt verify your process by comparing color values measured with those in the style.

[jeisenbe]

try to generate [screenshots] without any gAMA, cHRM, iCCP or sRGB chunks and without any color management

I read about PNG chunks but I don’t understand how to know if this is any issue: http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html

Do we need to be concerned about this when rendering with Kosmtik and standard browsers, eg Firefox, Chrome? On Wed, Jan 30, 2019 at 11:06 PM Christoph Hormann notifications@github.com wrote:

A bit of warning here:

Always be careful when assessing colors based on PNG images unless you know exactly what you are doing. The screenshots shown by @bdxd111 https://github.com/bdxd111 have different ancillary chunks and will not display correctly in many web browsers.

When you generate screenshots to publish them here you should always try to generate them without any gAMA, cHRM, iCCP or sRGB chunks and without any color management messing with the pixel values in either displaying the tiles or making and processing the screenshot. When in doubt verify your process by comparing color values measured with those in the style.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gravitystorm/openstreetmap-carto/issues/3647#issuecomment-458955864, or mute the thread https://github.com/notifications/unsubscribe-auth/AoxshHQdDUnlzJVikBL2sa5XQPd5KdQ2ks5vIab0gaJpZM4aHFCX .

[imagico]

Do we need to be concerned about this when rendering with Kosmtik and standard browsers, eg Firefox, Chrome?

No, tiles are generated without ancillary chunks - same for Kosmtik exports.

[dktue]

Why would you not want to do the transformation in HSV? I only see advantages in doing so.

[matkoniecz]

Why would you not want to do the transformation in HSV?

Some people may be familiar with RGB and unaware that other colour spaces exist or unfamiliar with them. The same applies to tools. That is not a good reason, but "almost everyone knows it" is the main advantage of RGB.

[dktue]

I think in this particular case people will definitely be able understand the two parameter "brightness" and "saturation" -- as this is exactly what we are trying to change. Much simpler than a formula which explains how R, G and B are being transformed -- together with a edge case (clipping at 255).

[Prince-Kassad]

Two problems I see here:

• The contrast difference between grass and farmland is too large. While grass stands out well from the background, farmland is sometimes near impossible to make out from the unmapped white especially in regions that are not fully mapped, where farmland borders unmapped white (or is completely surrounded by it). farmland should be made a bit darker like it used to be, I think the reasons we made farmland so bright no longer apply with the current style.
• forest and vineyard look too similar, especially when they directly border each other on lower zooms where we render landuse brighter in general. Maybe someone should test making vineyard brighter, a bit like grass (but not identical)?

[Adamant36]

Semi-large meadows are to hard to see at lower zoom levels also. They would probably be more noticeable without the fading.

[vholten]

I've written a script as @matkoniecz suggested in January:

If someone would be interested I may try writing script that edits all color definitions in text files of this style (not in image patterns) and applies some transformation to them

The script reads the original mss files, and transforms all colors according to a function that is provided in the script. As an example, I've included the transformation shown by @bdxd111 earlier.

z14 before:

z14 after:

z18 before:

z18 after:

The script and the resulting mss files are in https://github.com/vholten/openstreetmap-carto/tree/color-transform. This repo can be used as-is for rendering.

In January @matkoniecz made some remarks about a script such as this one, and I'll comment on them:

to use this script one would need to be able to run Python/Ruby scripts (it requires installation of software and may require using command line but there is plenty of documentation how it can be done on your system)

This is a Python script (tested with Python 3.7.3, not tested with Python 2) and requires the Python packages numpy, scipy, colormath and webcolors. It is run from the command line and currently has no parameters.

it is likely that at least initial versions would be completely or partially broken and one will need to report what and how went broken ( https://www.chiark.greenend.org.uk/~sgtatham/bugs.html ) it is certain that transformed style will require massive amount of testing and tweaking (for example it is unlikely that healthcare or shop icons should be even more saturated, it is likely that there are also other features that should be excluded from transformation or that transformed version of style will have some bugs)

I am more optimistic. Because the script applies the same transformation to all colors, the balance between colors remains good, even without any tweaking, and without excluding any features from the transformation.

I think that the higher zoom levels (z13 and higher) could benefit from a color transformation such as this one. The contrast enhancement results in a better map legibility.

[jragusa]

forest pattern seems to be less readable with saturated colours

[vholten]

forest pattern seems to be less readable with saturated colours

Good catch! The forest pattern comes from an SVG file, and currently the script does not change colors inside SVG files. This should be done for better results.

From left to right: before, current script output, and forest pattern as it should be.

[jeisenbe]

Doing this in an automated fashion is interesting, and I appreciate the emphasis on increasing contrast between colors again. Several changes in the past year or two have intentionally reduced the contrast between different features, so this would reverse the direction that this style has moved in some ways (Examples in first comment https://github.com/gravitystorm/openstreetmap-carto/issues/3647#issue-400539288).

But it would cause a number of problems if changes are not considered individually.

For example, this commit would change the most basic colors: @land-color would change from #f2efe9 Lch(95,3,87) to #f9f7ee Lch(97,5,101) - while this is only change of 2 in both Lightness and Chroma, relatively it's a 40% change in the difference between the color and pure white: the new color is much closer to white in lightness, and the higher chroma and shifted hue does not really compensate for this, or make much sense.

Meanwhile, the other basic map color, @water-color, would change from #aad3df Lch(82,15,224) to #96cddf Lch(79,20,227). This increases the apparent difference between @land-color and @water-color from Δ: 21.3 to Δ: 29 - this is much higher contrast between water and land.

The land-color is tricky: on the one hand we want to to look a bit "blank" to encourage mappers to fill in areas that are not mapped, but on the other hand it needs to provide a reasonable amount of contrast with lines and icons which are placed on top of it. Moving the land-color towards white would increase the contrast with most features, but reduces the contrast with white (e.g. residential roads, under-construction secondary roads).

[jeisenbe]

I think we rather than changing all the colors at once, we should start by fixing #3896 and #3936 by using the darker, higher chroma river-color and reducing the fading of landcover at lower zoom levels. Adding a lighter ocean-color (#3895) would also make it possible to increase the chroma of lakes without making the low-zoom map too high contrast between land and water.

We should also work on fixing #3607 (societal amenities color) and #3891 (parking fill color).

Once those changes are done, we can then consider if contrast needs to be increased further. I've shown some options of using darker/higher chroma lines for roads and rivers at low zoom level, so that the full landcover can be shown, in https://github.com/gravitystorm/openstreetmap-carto/issues/3936#issuecomment-543138520