-
Notifications
You must be signed in to change notification settings - Fork 819
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"The map appears washed out, more contrast wanted" #3647
Comments
Related to: |
My personal opinions:
|
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. |
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. |
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. |
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: openstreetmap-carto/landcover.mss Lines 71 to 83 in 6684f0a
It needs testing, but after that color areas on z5-z12 would be more saturated. |
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. |
I’m not quite sure what you mean here? |
Highest possible contrast is 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. |
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.
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.
It's lightness is 89 out of 100. Objectively, this is rather light, which is appropriate for a background 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) |
If white roads don't look good on lighter backgrounds, then they should look terrible on bare land, but I think they look fine.
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. |
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. |
How did you create that effect? |
Not exactly - it is older version of carto, with some their won changes added - but without nearly all carto changes since that time |
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 ? |
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. |
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) |
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
|
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. |
The transformation shown by @bdxd111 can be easily included in a script: |
and values above 255 should be clipped
That will create unpredictable colors
…On Wed, Jan 30, 2019 at 4:55 AM vholten ***@***.***> 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
<#3647 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshGPLpVgtLLJqv9M_61gHTPNTaAGUks5vIKdDgaJpZM4aHFCX>
.
|
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. |
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 ***@***.***> 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
<#3647 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshHoofeFGpg61ONAI556zXR7WmkJ9ks5vIMwegaJpZM4aHFCX>
.
|
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 anyone wants to try this, here is a Python script (requires Pillow):
|
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. |
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 ***@***.***> 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
<#3647 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshHQdDUnlzJVikBL2sa5XQPd5KdQ2ks5vIab0gaJpZM4aHFCX>
.
|
No, tiles are generated without ancillary chunks - same for Kosmtik exports. |
Why would you not want to do the transformation in HSV? I only see advantages in doing so. |
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. |
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). |
Two problems I see here:
|
Semi-large meadows are to hard to see at lower zoom levels also. They would probably be more noticeable without the fading. |
I've written a script as @matkoniecz suggested in January:
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. 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:
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.
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. |
forest pattern seems to be less readable with saturated colours |
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 #3647 (comment)). But it would cause a number of problems if changes are not considered individually. For example, this commit would change the most basic colors: Meanwhile, the other basic map color, 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). |
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 #3936 (comment) |
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: #3635 (comment)
Possible causes
#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 societal_amenities (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 societal_amenities 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.
Improve mid-zoom levels and water color #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
The text was updated successfully, but these errors were encountered: