Normal format (transformed) PNGs are fuzzy and muted

[nvkelso]

Ported from hotosm/oam-dynamic-tiler#39.

Looks like MarbleTiler fork is producing different normals than Joerd. There are probably more than one way of calculating these, but the output of Joerd is better for presentation cartography like Walkabout style and MarbleTiler should better match that output.

Specifically, MarbleTiler dev (top again) seems to have less exaggeration on the terrain / less details (compared to joerd prod)? Is the kernel size larger in MarbleTiler versus Joerd? That may account for more generalized looking relief.

• MarbleTiler: https://github.com/mojodna/marblecutter/blob/mapzen/marblecutter/transformations/normal.py
• Joerd: https://github.com/tilezen/joerd/blob/master/joerd/output/normal.py

Example 1:

• https://d34o1q5y1d9is8.cloudfront.net/normal/6/33/22.png
• http://tile.mapzen.com/mapzen/terrain/v1/normal/6/33/22.png (requires API key)

marbletiler fuzzy, less exaggeration
joerd crispier (more detail), more exaggeration

Example 2:

• https://d34o1q5y1d9is8.cloudfront.net/normal/10/163/395.png
• http://tile.mapzen.com/mapzen/terrain/v1/normal/10/163/395.png (requires API key)

marbletiler
joerd

Walkabout showing Example 2:

marbletiler
joerd

[iandees]

For a more recent reference, here is output from the lambda tiler now:

url

[nvkelso]

This is still a problem. I suspect it's compounded by not having consistent exaggeration applied in #3 (as in first that one first, retest), but I suspect there are some data differences, too.

[iandees]

An anecdote: I took the URL from my comment above and added @2x to bump the resolution. Then I copied that 512x512 pixel image into an image manipulation program and sized it back down to 256x256 pixels I get this:

That image looks to be crisp like @nvkelso's image in the description of this bug. I wonder if this is a problem related to resolution?

[mojodna]

It is indeed resolution-related (and a side-effect of trying to use resolution for everything internally rather than target zoom as distinct from target output size). The 1x-scaled version only uses etopo1/ETOPO1_Bed_g.tif, the 2x-scaled version uses gmted/30N180W_20101117_gmted_mea075.tif, gmted/30N000E_20101117_gmted_mea075.tif.

The fix for this is to bump min_zoom for GMTED down by 1 (and possibly for all other sources). (It's currently 7 for these particular files; some GMTED sources are 5 (southern polar regions).)

I'll let @iandees do the honors.

[nvkelso]

Let's verify this by running the following on all rows in the footprints database:

update footprints set min_zoom = greater(0, min_zoom - 1)

Once verified via an updated Lambda tiler, we should followup on #12 and modify https://github.com/mojodna/marblecutter/blob/master/bin/ingest_single_footprint.sh#L48 to show:

min_zoom=approximate_zoom - 4,

The different content in a 256px versus 512px tile goes against the grain of what we've done for vector tiles but I see your point for raster.

[iandees]

Ran the SQL:

footprints=> update footprints set min_zoom = greatest(0, min_zoom - 1);
UPDATE 580635

[iandees]

Re-running the tile in question after the min_zoom change:

The imagery sources used:

gmted/30N180W_20101117_gmted_mea075.tif, gmted/30N000E_20101117_gmted_mea075.tif

[nvkelso]

Fixed! Verified in Seth's Lambda tiler.