Texturing with TIFF files - a transparency and an extension problem

This issue started as a problem with texturing with a TIFF file in my PV derived “custom application”: I have there a “textured representation” that is supposed to add texturing to topo surfaces, like aerial photo with georeferencing information included - which works nicely most of the time.

But then I found a TIFF satellite photo (Geotiff) that did not texture the topo, but it made it transparent instead! And then I saved that same TIFF file (using QGIS) as another Geotiff, but now with JPEG compression - and this time the file was not only much smaller (ok, that’s obvious), but also it was showing like it should. I used the tiffinfo and geocp tools, put the output into two text files and compared them with WinMerge:

As you see, everything is the same, except for the compression and some “rows/strip” parameter.

Now I am a bit confused:

  • so far I was always thinking that JPEG “cannot do transparency” - which would then “explain” the problem: with the JPEG compression, some dubious transparency info would be stripped from the file! But from the above info you see: even the JPEG has 4 “samples/pixel”, so alpha channel is kept. Plus of course the most important: the TIFF file has no transparency at all!

  • then I was asking myself what transparency should actually do if you have it in a “texture” in ParaView? Should it just “now show” (ie, leaving the surface colored like it would be without texture), or should it indeed make the entire surface transparent? In that case I would have to see if the alpha info in the TIFF is maybe somehow “inverted” - at least in the eyes of ParaView.

But first of all I did not want to report a problem in my own “textured representation”, but something that happens also in “plain vanilla ParaView” - and so I tried to simply texture the topo with the same TIFF files, just ignoring the georeferencing. And there I encountered the extension problem:

  • If I tried to use these files (extension: *.tiff) as they are, ParaView just crashed - with the following messages (which I could catch through the QtCreator UI - because PV did not show it any more after the crash - obviously…):
(  89.133s) [paraview        ]vtkNetworkImageSource.c:138    ERR| vtkNetworkImageSource (0000020988BAD760): Unknown texture file extension: C:\Users\cornelis\Documents\Dev\Problems\ArnaudTexturing\2019_satellite_picture_1.tiff
(  89.197s) [paraview        ]   vtkOpenGLTexture.cxx:204    ERR| vtkOpenGLTexture (000002098840CCE0): No scalar values found for texture input!

Meaning that obviously it was not able to read the tiff file - due to it’s “unknown extension”.

  • Ok, I changed the extension to be tif instead of tiff, but now I could not even see the file any more: the file dialog for reading the texture in PV does not allow tif, but only tiff extensions!

So there seems to be some problem with TIFF files also already in PV, not only in my own application!

Of course it is possible to convert the TIFF file into PNG, and use also QGIS to write the georeferencing info into an ESRI World file instead of some GeoTIFF tags, but still: I think TIFF should be somehow supported as well!

Can you share a .tiff file with this problem ?

I can share both TIFF files, but they are 63 and 8 MB (without/with JPEG compression)!

No problem, you should be able to share them here, if not you can go through a file sharing site.

Ok, I will send you the files, together with a fitting topo and a screenshow of how it should look: This was generated by first converting the TIFF files into PNG, and since the topo surface and the image are matching exactly, also the georeferencing info is not required: just using the “automatic” option of the “Texture Map To Plane” will do.

I am not going to publish here just in order to be a bit careful: it’s customer data.

Just one more finding: I was dumping the data from the first four points in the image, and there is indeed a difference in the alpha value in the uncompressed and the JPEG compressed file that MIGHT explain the difference:


data dimension 2
scalar type 3
scalar type unsigned char
num scalar components 4
scalar size 1
pt 0 : 87 88 93 0
pt 1 : 79 80 85 0
pt 2 : 82 84 88 0
pt 3 : 82 85 90 0

JPEG compressed:

data dimension 2
scalar type 3
scalar type unsigned char
num scalar components 4
scalar size 1
pt 0 : 86 87 93 255
pt 1 : 83 81 87 255
pt 2 : 81 80 86 255
pt 3 : 82 86 91 255

Hmm, looks like I am looking at different points - which I need to check of course. But also I see that with the JPEG compression, the alpha values were “magically” changed from being all 0 to all 255!

From which I conclude:

  • In ParaView, “texturing” a surface with “transparent” makes it invisible

  • In order to avoid that, I have to make sure in my own code that alpha is either not existing or always set to 255 for all pixels

Well, that looks like a feasible agenda though…

I can confirm that by explicitly forcing all alpha values - if they exist - to being the maximum of the scalar type, the topo shows correctly now, nothing transparent any more!

So my own special problem is solved.

What remains: Also Paraview should not crash if you want to use such a file for texturing by using the TextureMapToPlane (or similar) filter.

1 Like

Indeed, please open an issue so the segfault can be tracked and fixed.