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!