<div dir="ltr"><div>Hi everybody,<br></div><div><br>I've written a long Python script to batch-process and compute a series of raster layers. The script is written to run entirely outside of QGIS, which I accomplish by importing the required  modules.<br><br></div><div>I use the processing toolbox for a number of operations, for example:<br><br><span style="font-family:monospace,monospace">processing.runalg("grass7:r.buffer",input_layer,mg_buf,1,False,clipped_extent,0,output_layer)</span><br><div><br></div></div><div>For some layers, I get error messages like this:<br><br><span style="font-family:monospace,monospace">ERROR 1: /home/user/Output/masks/mgrid_mask_buffer.tif, band 1: Failed to compute statistics, no valid pixels found in sampling.<br></span></div><div><br></div><div>I used a debugger and went down as many levels as it would let me. The error occurs when QgsRasterLayer(uri, name) is called in /usr/share/qgis/python/plugins/processing/tools/dataobjects.py:266.<br><br></div><div>The layer in question is an eight-bit unsigned integer GeoTIFF with pixels that are either 1 or NoData (NoData value is 255).<br></div><div><br></div><div>One might think that the GeoTIFF is the problem. However, when I open the very same file in QGIS, I get no such error. This is true even if I use the Python console within QGIS, set the variables in question, and run the command <span style="font-family:monospace,monospace">processing.runalg("grass7:r.buffer",input_layer,mg_buf,1,False,clipped_extent,0,output_layer)</span><br><br></div><div>Overall, my experience with the Processing toolbox has been frustrating. It's not that I expect things to work perfectly, I understand that open-source software is a work in progress and supporting a great variety of external libraries and third-party software such as GDAL, GRASS and SAGA in a unified way is no easy task.<br><br>But it is a mistake to obfuscate or block error messages. These are essential for troubleshooting. I've invested days of development time hunting for bugs that result in part from silent failures that result in later errors that are totally misleading. Had the original error been presented unadulterated right at the moment when it occurred, the cause could have been resolved in a few minutes. <br><br></div><div>(My impression that, in an effort to make QGIS "user-friendly" and avoid confusing beginners and laypeople, aspects critical to a professional are hidden. At the very least it should be a simple matter to turn such functionality on.)<br><br></div><div>I understand that the bulk of development effort is going into QGIS 3. Have these aspects been considered? I'm referring specifically to code transparency.  QGIS really should pass on error messages originating from an external module, tell the user in which module the error occurred, and provide both the command that was issued and the output returned (I know that the log messages panel already does this to some extent, but why doesn't processing.runalg, for example?)<br><br></div><div>Having said all that, I do appreciate all the development effort that has gone and is going into QGIS. Thank you.<br><br></div><div>Kind regards<br><br></div><div>Stephen Bosch<br></div></div>