Jump to content

sandworm masks generation problem


Recommended Posts


I'm using some custom landuse I've generated (geotif no compression 20 indexed colors 2.5mppx, no nodata transparency) but for some reasons some extracted tags (ie: indexed color from 9 to 9) produce bad results (pixel bombing everywhere): for example highly sloped cliffs here index color 9 (purple color) generate some mask white values whre supposed to but also a bit everywhere. Of course those pixels are not like that in source data. Same thing if I use the rgb values directly not the index. Some other tags generate good results. Any idea what's causing this or if it's a bug ?



Link to comment


Romain, to be honest it looks like a bug to me. And the problem now is that there isn't much you can do simply adjusting any settings.

I believe the behavior you see happens due to mask blending, those "pixel bombing" must show the differences between colors where they overlap.

We need to have a closer look on this, could you be so kind and share sources together with the configured  ".sworm" project?

Until we fix this internally, I recommend you to create and use an individual mask for those problem areas instead of one common mask for the whole area.


Link to comment

Hi, I tried to identify the source of the problem a bit further: maybe it's to do with indexed colors somehow overlapping as you said (but different colors changes nothing...) HOWEVER, I tried exact same data source with a different file name - instead of iterating tests on the same file- and now results are OK, at least on this layer. So I think this is more a cache related problem (the weird thing is that I deleted lmaps and sandworm cache everytime I've iterated on the same file, only using another file worked...

have a good day  


Link to comment

Hi, a little update on that subject:

found out straight R8 only rasters don't seem to be supported unfortunately (I've made an FME process to export each land use palette keys trough individual rasters and wanted to save some disk space hence Red8 format) documentation says R8/16/32f are supported but they import as void data in sandworm. Had to coerce the data to RGBA8 (so lots of unnecessary data) for my individual masks to load and generate masks correctly (with color tagging as single band doesn't seem to work either). i'll try soon to combine the palette entries to RGBA bands and see if it's working with sandworm (again to save some space) and keep to update this thread. :)

Link to comment


18 hours ago, romain.janil said:

found out straight R8 only rasters don't seem to be supported unfortunately

We have tested behavior on several 8-bit masks and unfortunately the problem is not reproduced on our side yet.

Romain, could you make a simple sample for us using exactly your mask within configured .sworm project? Heights and albedo data are not needed, we will use TMS instead.


Link to comment

HI, here's a Red8 version which won't load correctly in sandworm (and FME settings used image.png.697673fb3903023f82a33afe1b037a15.png

Note that values are already in the 0 255 range, and that there's only one band.

And a mask in the archive.


Edited by romain.janil
Link to comment

You can also check for the system messages in the console window after adding a mask to the project.

If the asset has any problems, warnings are usually displayed here.

To open it switch to Editor and select Windows -> Console from main menu.

Link to comment
39 minutes ago, romain.janil said:

GdalTileAccessor: can't fetch raster data from dataset(cliff_LU_R8.tif).


Romain, indeed as well as many other fixes this one has been fixed in most recent update hotfix

Besides the fixes, there were also useful improvements too, so I highly recommend you update.


Link to comment

Hi, little update, all issues gone with latest hotfix update indeed. :)

Have some suggestions to improve sandworm tool hower, I'll make another thread.

Have a good day

  • Like 2
Link to comment
  • Create New...