<div dir="ltr"><div><br><br>On Mon, May 1, 2017 at 11:17 AM, Markus Neteler <<a href="mailto:neteler@osgeo.org">neteler@osgeo.org</a>> wrote:<br>><br>> On Sun, Apr 30, 2017 at 10:39 PM, Markus Metz<br>> <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>> wrote:<br>> ...<br>> > 16+GB of RAM still seems too much to me, unless the histograms of the cell<br>> > values are highly skewed. What is the output of r.stats -c for B04_255,<br>> > B11_255, B8A_255?<br>><br>> Since this comes from our automated processing chain I could only<br>> reimport the resulting S2 bands which should not change much.<br><br></div><div></div>If NULL values are correctly set, I would assume about 4 GB of RAM needed by r.quantile.<br>If there are no NULL cells, I would assume about 14 GB of RAM which is close to what you observed.<br><div><br>Can you check your processing chain to make sure the nodata value is correctly set?<br><br></div><div>Also note that there are about 7 billion NULL cells in B04, but only 1.7 billion NULL cells in B8A and B11.<br></div><div><br>> I think they are (strongly) skewed: will send the data off-list to you.<br><br></div><div>The cell count for value 1 is quite high in all three bands. Is this expected? However, the cell count for value 1 does not explain the high RAM consumption of 16+ GB.<br><br></div><div>Markus M<br></div></div>