Color map issues with sequence of images

ParaView Support
1

ParaView 5.10.1 seems to have some strange behavior when I try to visualize a sequence of rasters.

Here is the first raster loaded individually (results are as anticipated):

first
first926×648 15.1 KB

and the second loaded individually (slightly different from the first):

second
second926×648 17.7 KB

When I load the two rasters together as a sequence (for an animation), the first image appears the same as before but the second image is different:

together
together926×648 19.2 KB

This seems to happen only when the data in the raster is highly bimodal (part of the image is close to one value and the rest is close to a different value).

2

Hi @jdpellet

Please share your data.

Best,

3

soil_1.tif (5.3 KB)
soil_2.tif (20.4 KB)
I didn’t save the exact same files but the two tif images above show the same issue. Here are the screenshots for these files loaded separately:

soil1
soil1926×648 15.1 KB

soil2
soil2926×648 16.2 KB

and then here is the screenshot of the second image with the images loaded together as a sequence using “open multiple files with the cntrl key”.
soil1and2
soil1and2926×648 31.6 KB

After I loaded the sequence I turned off “read as image stack” and then made them visible using default colors/settings.

4

I think the problem is that your two tiff files are of different formats. If you load soil_1.tif independently, ParaView reports that the data are represented as 8-bit unsigned integer values in the Information panel.

image

If you load soil_2.tif independently, ParaView reports that the data are represented as 32-bit floating point values.

image

This explains why the file size of soil_2.tif is 4 times that of soil_1.tif.

Now the problem is that when you read the files as a stack, ParaView’s tiff reader (reasonably) assumes that the data format is consistent across all the files. So, it reads the first file and identifies the data as 8-bit unsigned integers. It then assumes the second file is the same and reads the 32-float values as 8-bit integers. The weird pattern you are seeing are the 4 bits of the IEEE floating point values.

5

Thank you. I used a batch gdal_translate to convert the ascii xyz outputs from my mathematical model to geotiffs. I will seek out how to force gdal_translate to produce 32-bit float for all files or try another converter. That should resolve.