CloudCompare forum

Hey guys,
I'd like to know if there's anyway to export a 16bit heightmap (GEOTIFF or DEM) out of cloud compare?

So far I can export 3d geometry and manually create a heightmap, but i'm wondering if this is somehow possible within cloud compare?

Cheers,
Joe

Well with the Rasterize tool (http://www.cloudcompare.org/doc/wiki/in ... =Rasterize), you can create rasters / height maps and then export them to Geotiff (but I believe it will be 64bits layers by default) or also as a mesh (so it's a kind of DEM).

Hi, I also want to ask that. I'm exploring solutions to render XYZ data to GeoTIFF. But based on the outputs we got, Cloud Compare only seem to Rasterize into 8bit data. Is there an option to control the bit rate for rasterizing?

Normally the depth layer should be 32 or 64bits. Only an RGB layer would have 3 x 8 bits (normally).

[SEE ATTACHED]
Hello sir, can you explain more about that part?

Surely the RAW tiff is more than 8bit, but my goal is to create a Rasterized "Image" GeoTIFF.

Im exporting from Tools/Projection. When I import the rasterized image GeoTIFF to TerreScultor for DEM Visualization, the points are not extrapolated and the mesh looks jaggy (step-stairs look). It does not render in the same quality inside like the way CC render the points via pcv and edl.

Maybe there is something wrong with my export process. :,<

Well, internally, when we create the GeoTiff (thanks to GDAL), we allocate a 64bits layer ('GDAL_Float64' - see https://github.com/CloudCompare/CloudCo ... .cpp#L1155) unless it's RGB colors.

One reason I see that could explain these stairs would be for the grid cells to be quite large. In this case, as you keep for each cell a single value (the average height for instance) it could explain that you have 'steps' in the raster 'height' layer.

The other reason would be of course that the tool doesn't read the 64bits layer properly (but that seems unlikely).

Have you tried to load the tiff file in another tool? (QGis, etc.)

I tried on my side (with the 2.12.alpha version). I can read the Geotiff generated by CloudCompare with QGis, and it confirms that the depth layer is indeed 64bits. The result is also visually good.

However I was not able to import the same geotiff in TerreSculptor... It rants that the file is of an "invalid file type".

Which version of CC are you using?

Hello sir, I'm using CC v2.

The RAW TIF from CC - just judging at the file size, I assume is indeed more than 8bit. I can open the TIF file as a raster layer in QGIS, no problem here.

However, the RAW TIF file cant be opened in TerreSculptor. TerreSculptor works with grid heightmaps and grid meshes only. Any digital elevation model data must already be elevations per raster pixel and cannot be TINs or Point Cloud Samples.

A workflow would be to convert any Point Cloud data to heightmaps in BIL, FLT, HGT, or other TerreSculptor supported DEM heightmap formats using other software that converts Point Cloud data to Heightmaps. In this case, I am using CC to generate GeoTIFF

Since the RAW tif from CC is an Invalid File Type in TerreSculptor, I assume that the TIF as a container stores un-rendered raster pixel. This is why I have to open the RAW TIF in QGIS and export it as Rendered GeoTIFF. From there I can open the file in TerreSculptor.

Yes, I also realized that when exporting the geotiff file with QGis it could then be loaded in TerreSculptor.

However, where I'm a little bit confused is that the geotiff exported by CC (with GDAL: https://gdal.org/drivers/raster/gtiff.html) is already a raster grid (with a grid like structure) and not a DEM/TIN or a point cloud. It would be good to know what TerreSculptor doesn't like exactly...

Hello sir,

So I kinda got additional information however, I still have not resolved the terracing effect.

Cloud Compare exports a Float64 RAW TIF.

TerreSculptor is using Windows API library for management of image file types (BMP, GIF, JPG, JRX, PNG, TIF) called the Windows Imaging Component or WIC. WIC unfortunately does not support 64-bit floating point grayscale images. 32-bit grayscale is the highest that it supports.

TerreSculptor will only support 8/16/32 bit grayscale and 8/16/32 bits-per-channel RGBA color (32/64/128-bit color).

That said, running a GDAL convertion is the other option which is also supported by QGIS.
That means the rasterised point cloud data can be ported to TerreScultor albeit an conversion processing is required either via gdal command line or QGIS.

NOW, we are able to troubleshoot data importation, that means that the terracing effect in the 3d mesh is probably not an issue with data interpretation. It seems like the interpolation is was correct when creating the raster image.

Is there some sort of TIN interpolation or data extrapolation in Cloud Compare?

We took a 1m lidar resolution for a mountain, inside Cloud Compare, the visualization seems accurate but the rastered image doesnt seem to interpolate between points hence the terracing effect. Here's the screenshot from Cloud Compare to TerreScultor to Unreal Engine