<div dir="ltr">Thanks for the replies. I think in this instance that as Even suggests it's because both the ECW SDK and GDAL are trying to allocate which will take me over the RAM limit.<div>From a users perspective I just figured that more RAM = better, based on experience that's usually how things work. Useful to know it's not here.</div>

<div><br></div><div>Thanks again,</div><div>Jonathan<br><div class="gmail_extra"><br><div class="gmail_quote">On 2 December 2013 19:03, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@mines-paris.org" target="_blank">even.rouault@mines-paris.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le lundi 02 décembre 2013 19:42:59, Jonathan Moules a écrit :<br>
<div class="im">> On 2 December 2013 18:32, Even Rouault <<a href="mailto:even.rouault@mines-paris.org">even.rouault@mines-paris.org</a>> wrote:<br>
> > Le lundi 02 décembre 2013 19:12:07, Jonathan Moules a écrit :<br>
> > > Hi Even,<br>
> > > To hit the 10GB limit I'm using (Windows Server 2008):<br>
> > ><br>
> > > gdal_translate -of GTiff -co TILED=YES -co BIGTIFF=YES -co<br>
> > > COMPRESS=JPEG -co JPEG_QUALITY=60 -co BLOCKXSIZE=512 -co<br>
> > > BLOCKYSIZE=512 -co<br>
> > > PHOTOMETRIC=YCBCR 2000.vrt 2000.tif<br>
> > ><br>
> > > I tried adding:  --config GDAL_CACHEMAX 27000000000 but then it'd just<br>
> > > crash with out-of-memory (it wouldn't actually stop at 27GB; so I guess<br>
> > > that works differently again).<br>
> ><br>
> > Crash (Windows dialog) or "clean" exit with a GDAL error message ?<br>
> > What are the files (TIFF, ECW, ...) in the VRT ?<br>
> > I don't see anything wrong, and have not OS and hardware specs to<br>
> > reproduce that.<br>
><br>
> A clean GDAL error:<br>
><br>
> 0...ERROR 2: GDALRasterBlock::Internalize : Out of memory allocating 262144<br>
<br>
</div>It is really the operating system refusing to do the allocation. Perhaps there<br>
are too much of small allocation, but the virtual memory space on 64 bit is<br>
huge so fragmentation should not be an issue.<br>
Or perhaps you've just reached the RAM size due to the ECW SDK eating RAM by<br>
itself. According to <a href="http://www.gdal.org/frmt_ecw.html" target="_blank">http://www.gdal.org/frmt_ecw.html</a>, it can consume up to<br>
1/4 of the RAM by default. I'm not sure which version of the SDK you are<br>
using, but I remember that with the ECW SDK 3.3 it requires a patch for Linux<br>
64 bit, otherwise it could use much more RAM than 1/4. You could try setting<br>
ECW_CACHE_MAXMEM explicitely (possibly below 2 GB to avoid any potential 32/64<br>
bit issue)<br>
<div class="im HOEnZb"><br>
><br>
> > bytes.<br>
> > ERROR 1: GetBlockRef failed at X block offset 334, Y block offset 60<br>
><br>
> The "files" are one single ECW file. 5GB compressed, about 200GB<br>
> uncompressed.<br>
<br>
</div><div class="HOEnZb"><div class="h5">--<br>
Geospatial professional services<br>
<a href="http://even.rouault.free.fr/services.html" target="_blank">http://even.rouault.free.fr/services.html</a><br>
</div></div></blockquote></div><br></div></div></div>

<br>
<span style="color:rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(255,255,255)">This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.</span>