Hillshade renderer artifacts - Githubissues

qgis / QGIS

QGIS is a free, open source, cross platform (lin/win/mac) geographical information system (GIS)

https://qgis.org

GNU General Public License v2.0

10.09k stars 2.93k forks source link

Hillshade renderer artifacts #23859

Open qgib opened 7 years ago

qgib commented 7 years ago

Author Name: Paolo Cavallini (@pcav) Original Redmine Issue: 15943 Affected QGIS version: 3.0.0 Redmine category:symbology

Borders of cells are visible. See attached. Possibly more apparent in master, but present since the beginning.

hillshade.png (Paolo Cavallini)
nn vs bilinear.png (Johannes Kroeger)

qgib commented 7 years ago

Author Name: Giovanni Manghi (@gioman)

regression was configured as 0
easy_fix was configured as 0

qgib commented 6 years ago

Author Name: Johannes Kroeger (Johannes Kroeger)

That's a highly zoomed-in view (much closer than 1:1 scale) of a hillshaded raster with Nearest Neighbor resampling. I am not sure if this is a bug.

A simple workaround (or solution?) is to set the resampling to Bilinear or Cubic.

qgib commented 6 years ago

Author Name: Johannes Kroeger (Johannes Kroeger)

Example image at about 3:1 scale.

11926 was configured as nn vs bilinear.png

nn vs bilinear.png (Johannes Kroeger)

qgib commented 6 years ago

Author Name: Alister Hood (@AlisterH)

Also affects 2.18.16. I am pretty sure we can call it a bug - there is no reason a hillshade should need cell borders, and if you create an actual hillshade layer (e.g. using the gdal hillshade tool) it won't have them.

description was changed from Borders of cells are visible. See attached. Possibly more apparent in master, but present since the beginning. to Borders of cells are visible. See attached. Possibly more apparent in master, but present since the beginning.

qgib commented 6 years ago

Author Name: Alister Hood (@AlisterH)

Johannes Kroeger wrote:

A simple workaround (or solution?) is to set the resampling to Bilinear or Cubic.

It is a workaround, not a solution ;)

Also, unless I'm missing something there is no way to get rid of these artefacts in a 3D map in master.

qgib commented 6 years ago

Author Name: Alister Hood (@AlisterH)

Alister Hood wrote:

there is no reason a hillshade should need cell borders

Except they aren't borders as such, they are hillshading applied at the edges of the individual raster cells. I haven't looked at how hillshading algorithms work in gdal or wherever - maybe they actually incorporate smoothing, in which case the solution here would probably be to always enable smoothing for the hillshade renderer.

qgib commented 6 years ago

Author Name: Giovanni Manghi (@gioman)

version was changed from master to 3.0.0

AlisterH commented 5 years ago

Note that there is a similar effect around the edge of the canvas if your raster is in the same projection as your canvas (i.e. is not being reprojected "on the fly"). This one is more noticeable if smoothing is enabled. Presumably it is just because the OTF reprojection code does not use values from outside the map canvas in its calculations.

For example:

If you get the zoom level right it looks pretty extreme:

AlisterH commented 5 years ago

[previous comment now corrected]

Also, if smoothing is turned off it is generally only noticeable if you zoom out.

nirvn commented 5 years ago

This is one of the many limitation of the hillshade renderer. If I were you, I'd create an hillshade raster from your DEM using processing, I doubt the renderer will be improved on the short term.

bellanz80 commented 4 years ago

Hi, i have a DEM. DEM visualized with Hillshade style. Resampling: "Bilineal" In QGIS 3.8 and 3.10, when changing the Resamplig to "bilinear", it stays the same as "nearest", where the pixels are visible. Meanwhile, in QGIS 2.18 and 3.4 it works correctly.

Presentación1

I attach a video Grabando #17.zip

Windows 10 64 bit - 2 different pc. QGIS StandoAlone version

bellanz80 commented 4 years ago

Important update. He tested with QGIS 3.10.2 and a clean profile, no problem ... everything worked perfect ... will the plugins be? impossible now to know, I have many installed ..

AlisterH commented 4 years ago

I guess it is easy enough to try copying all the plugins into the clean profile, enabling them all and seeing if it is OK. Presumably you did confirm it was a problem in fresh empty projects, not just in your existing projects?

bellanz80 commented 4 years ago

thanks. But in reality it is not easy to copy the plug from one profile to another. Only a majority is included in the profile folder. And yes, they were new projects. It became clear that something subsequently installed stopped working the resampling.

bellanz80 commented 4 years ago

Update: I managed to copy all the plug of my profile, normal, to a clean profile (I had not seen the python folder inside the profile). And as expected, the problem continues to appear ... confirmed are the plug ... a day that has a few hours off, I will do a test. I also reviewed the OPENCL, and it does NOT change the result, activating it or not. Thank you!!

bellanz80 commented 4 years ago

Last update: I confirm that the problem is NOT the version of QGIS, but the plugs. I opened the profile with plug in QGIS 3.4, and the error was generated. Thank you

gioman commented 4 years ago

Should we close this?

roya0045 commented 4 years ago

I guess it would be nice to isolate the plugin that causes this in order to have a future reference or allow the author to fix it.

gioman commented 4 years ago

I guess it would be nice to isolate the plugin that causes this in order to have a future reference or allow the author to fix it.

yes, but if is a plugin to blame this ticket does not belong here anyway.

bellanz80 commented 4 years ago

hi. After 3 hours of testing, I found the problem and the solution ... I don't know if it's a bug, or if it's completely normal, but the "render resamplig" stopped working because the CRS of the layer is UTM (EPSG 32615), but the CRS of the project was Geographic (EPSG 4326). By putting the two systems the same, the resample works without problem. With your great experience, is it a bug, or is it all normal and I was wrong the process? Thank you

nirvn commented 4 years ago

It's a known limitation. We can safely close this as the limitation is well known.

pcav commented 4 years ago

Sorry, I don't agree: even if known, this is a real issue for the user. Apparently it should be easily overcome by activating resampling.

jfbourdon commented 4 years ago

If I may add my voice, I'm glad to have came across this issue as it was a real bummer for me to see that the hillshade renderer was not usable due to the cells being visible. Only now, after 3 years of using QGIS, I learn that:

The CRS of the layer needs to be the same of the one of the project to minimize artifacts;
The sampling method must be changed from the default nearest to bilinear (and average for zoom out).

It would be nice if these info were written on the Hillshade panel or a warning issued when selecting the hillshade renderer.

AlisterH commented 4 years ago

hi. After 3 hours of testing, I found the problem and the solution ... I don't know if it's a bug, or if it's completely normal, but the "render resamplig" stopped working because the CRS of the layer is UTM (EPSG 32615), but the CRS of the project was Geographic (EPSG 4326). By putting the two systems the same, the resample works without problem. With your great experience, is it a bug, or is it all normal and I was wrong the process? Thank you

Haven't you have described it backwards? Testing here it seems "The resample works without problem" when the layer is reprojected i.e. when the layer CRS and project CRS are DIFFERENT.

AlisterH commented 4 years ago

The sampling method must be changed from the default nearest to bilinear (and average for zoom out).

I avoid this annoyance by setting these as default in Settings>Options>Rendering>Rasters. But it probably isn't a great idea for layers that aren't hillshaded.

AlisterH commented 4 years ago

Sorry, I don't agree: even if known, this is a real issue for the user. Apparently it should be easily overcome by activating resampling.

What do you mean? Changing the default setting as per my last comment? Always resampling hillshaded layers regardless of the layer's setting? Automatically changing the layer's setting when hillshading is enabled?

jfbourdon commented 4 years ago

I avoid this annoyance by setting these as default in Settings>Options>Rendering>Rasters. But it probably isn't a great idea for layers that aren't hillshaded.

As you correctly pointed out, changing the global default value isn't a great solution because if you have a classified raster, you wouldn't want a bilinear resampling, so it's just replacing a annoyance by another.

Could the current state of resampling be saved when choosing the hillshade renderer so that when the user switch back to Singleband pseudocolor for example, it automatically revert resampling to whatever it was before? That way the hillshade renderer could be set to always be bilinear without causing issues.

Haven't you have described it backwards? Testing here it seems "The resample works without problem" when the layer is reprojected i.e. when the layer CRS and project CRS are DIFFERENT.

What I observe is effectively the opposite: if the layer CRS and project CRS are DIFFERENT, the issue is present, even with bilinear resampling, but less present than with nearest neighbour.

Lorchi74 commented 1 week ago

I confirm this rendering bug with QGIS version 3.34.8. Both the layer and the project have the same CRS: EPSG:25832 (UTM 32N).