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

Switch sand and wetland patterns to SVG #2727

Merged
merged 1 commit into from Aug 7, 2017

Conversation

Projects
None yet
4 participants
@sommerluk
Collaborator

sommerluk commented Aug 6, 2017

Some more work to eliminate raster images. Should not make a visual difference when rendered at default resolution.

@kocio-pl

This comment has been minimized.

Collaborator

kocio-pl commented Aug 6, 2017

Sand looks much different now, could you check beach.svg? Wetland looks the same and mud.png is really not used anywhere, thanks for spotting it.

Before
fbv1uq3w
After
echxl2nj

Before
wbcooqqb
After
8mu21h6m

@sommerluk

This comment has been minimized.

Collaborator

sommerluk commented Aug 6, 2017

Okay, I see. What I get here is (left before, right after):
screenshot 2

That’s not good.

@imagico Do we have to apply some transparency to the pattern? Does Mapnik support transparency?

It seems still different from your rendering, but I do not know why.

@imagico

This comment has been minimized.

Collaborator

imagico commented Aug 6, 2017

I noticed two things when looking at this:

  • i apparently forgot to add the beach patterns to generating_patterns - should supplement that which will allow you to better pinpoint where Mapnik's SVG rendering differs. There is no distinct transparency involved in generating the PNG though.
  • i distinctly remember the generic wetland pattern being semi-transparent but apparently only the more sophisticated wetland patterns are (leading to the dashes differing slightly in color between those which should probably be changed).

@kocio-pl kocio-pl changed the title from Switchsvg01 to Switch sand and wetland patterns to SVG Aug 6, 2017

@kocio-pl

This comment has been minimized.

Collaborator

kocio-pl commented Aug 6, 2017

It seems still different from your rendering, but I do not know why.

How do you render it then? I use Kosmtik with export.

@imagico

This comment has been minimized.

Collaborator

imagico commented Aug 6, 2017

See #2729 for the source SVGs and the process to generate the PNGs.

@sommerluk sommerluk force-pushed the sommerluk:switchsvg01 branch 3 times, most recently from cf68094 to 32dc3cb Aug 7, 2017

@kocio-pl

This comment has been minimized.

Collaborator

kocio-pl commented Aug 7, 2017

Now it's OK. You should probably join two commits into one and it's ready to be merged soon.

sabje3yx

@sommerluk sommerluk force-pushed the sommerluk:switchsvg01 branch from f402051 to 7df344f Aug 7, 2017

@kocio-pl kocio-pl merged commit 3a74d72 into gravitystorm:master Aug 7, 2017

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@imagico

This comment has been minimized.

Collaborator

imagico commented Aug 7, 2017

This is still very different from the PNG:

beach difference

@kocio-pl

This comment has been minimized.

Collaborator

kocio-pl commented Aug 7, 2017

For me it's close enough, so I would leave it as it is now. What would you propose?

@sommerluk

This comment has been minimized.

Collaborator

sommerluk commented Aug 7, 2017

Here two screenshots that I have made:

At the left a screenshot from openstreetmap.org.

At the right a screenshot from kosmtik running the code of this PR.

osm_org

It’s indeed not identical, but almost identical.

On the other hand, it is quite different from the picture that you have posted. I wonder where these rendering differences come from.

@imagico

This comment has been minimized.

Collaborator

imagico commented Aug 7, 2017

@sommerluk - my sample is based on the screenshot by @kocio-pl. I have not yet tested this myself (will do when i find the time). Your comparison indeed looks fine (and probably within the bandwidth to be expected due to rounding errors etc. due to different processing).

Your SVG and mine differ in the individual symbols but not the pattern so some small difference will always be there but this is not a problem if the overall impression is the same.

@sommerluk

This comment has been minimized.

Collaborator

sommerluk commented Aug 7, 2017

@imagico

This comment has been minimized.

Collaborator

imagico commented Aug 7, 2017

Yes, for explanation: the SVG used for the raster process has gray symbols (#969696). This color is used for the alpha mask with ImageMagick (CopyOpacity). So your foreground color essentially has to be a mixture between my foreground color (#685d45) and the background color (#fff1ba). And there are also probably some color mixing differences between Mapnik and ImageMagick.

@kocio-pl kocio-pl referenced this pull request Aug 7, 2017

Merged

Cemeteries rework in SVG #2714

@kocio-pl

This comment has been minimized.

Collaborator

kocio-pl commented Aug 7, 2017

Export test shows that there's really a difference:
znbirnet
yriwdib4

@imagico

This comment has been minimized.

Collaborator

imagico commented Aug 7, 2017

I tested the change and can add to the confusion - screenshot directly from kosmtik (no composite):

svg pattern rendering inconsistency

The left version which is probably what @sommerluk saw is a bit more reddish in the pattern than the PNG version which is to be expected with the colors used:

http://davidjohnstone.net/pages/lch-lab-colour-gradient-picker#685d45,fff1ba,dbb677

Looks quite clearly like a Mapnik bug to me - it generates different renderings based on the same data and the same code depending on some unknown condition.

@kocio-pl

This comment has been minimized.

Collaborator

kocio-pl commented Aug 7, 2017

It would be good to create an issue ticket then, if you can explain them what's going on.

@sommerluk

This comment has been minimized.

Collaborator

sommerluk commented Aug 7, 2017

@springmeyer Do you have an idea what could be the reason for #2727 (comment) ?

@springmeyer

This comment has been minimized.

Contributor

springmeyer commented Aug 7, 2017

@sommerluk I don't detect a Mapnik svg rendering bug here. The beach.svg renders in mapnik nearly identically to chrome.

@imagico

This comment has been minimized.

Collaborator

imagico commented Aug 13, 2017

I have analyzed this a bit further:

  1. There are more than two variants produced when rendering from kosmtik:

svg pattern rendering inconsistency

I of course have no way to reliably reproduce this or to reliably determine conditions where this does not occur.

  1. The differences look like different gamma settings or multiple renderings of the pattern.

  2. If i don't render the pattern in a separate layer like it is done for beaches but together with the base color fill i seem to reliably get the darkest variant (see bottom left above) everywhere.

  3. If i render the pattern together with the base color fill and set polygon-gamma: 1; (not polygon-pattern-gamma!) i seem to consistently get the correct (lightest) result.

  4. The problem is not specific to grain patterns like for beaches but also shows up with normal patterns unless they are trivial b&w pixel painting geometries like the base wetland pattern. This is not always clearly visible of course given the typical low contrast between symbols and base colors.

I have not checked if observations 3. and 4. could be due to a Carto bug rather than a Mapnik bug or if any of the observations is specific to the kosmtik setup.

Wherever the problem lies exactly unless someone finds a workaround to reliably get the correct rendering that is not overly complicated my conclusion would be that SVG patterns are not ready for production use here.

@kocio-pl

This comment has been minimized.

Collaborator

kocio-pl commented Aug 13, 2017

Thanks for looking deeper into this subject. Are these images screenshots or exports? Is there a difference in how Kosmtik shows them on screen and how it exports them?

@imagico

This comment has been minimized.

Collaborator

imagico commented Aug 13, 2017

Since the differences are at the metatile boundaries they obviously only show up with a tiled render. I don't know if this also happens with tiled rendering outside kosmtik. Update: it is confirmed that this also happens in production rendering - see #2750.

@sommerluk sommerluk deleted the sommerluk:switchsvg01 branch Aug 19, 2017

@imagico imagico referenced this pull request Aug 23, 2017

Closed

Release v4.2.0 #2728

@kocio-pl kocio-pl referenced this pull request Dec 11, 2018

Open

Convert patterns to SVG #2045

8 of 18 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment