<div dir="ltr"><div>Hi Even,<br><br></div>I ran the script you linked, and your hypothesis is absolutely correct. <br><br><JP2KCodeStream filename="/vsisubfile/4038_<wbr>901949970,/vsis3/glitch253/<wbr>test2.ntf"><br>.<br>.<br>.<br><div><Field name="SGcod_Progress" type="uint8" description="RLCP">1</Field><br><Field name="SGcod_NumLayers" type="uint16">19</Field><br><br></div><div>I
 also added a quick printf in the vsi subfile read function which prints
 the nSize and nCount variables. Running the python script you linked me
 triggered the vsi subfile read function 75,868 times, mostly with small
 sizes, and nCount=1. <br><br></div><div>Doing the same thing on my 
gdal_translate -srcwin 000 000 1000 1000 triggered vsi subfile read 
9,024 times, almost all with nSize=1 and nCount=1024. If the vsisubfile 
object is wrapping a vsis3 dataset, then does each vsi subfile read turn
 into an HTTP request? That would certainly explain the extremely long 
time to crop my window. <br><br></div><div>Just out of curiosity I ran 
the python script you linked on my JP2 file (same image as the NITF, I 
just ran gdal_translate on it). <br><br></div><div>This one appears to have the codestream progression order LRCP with only one layer...?:<br> <Field name="SGcod_Progress" type="uint8" description="LRCP">0</Field><br> <Field name="SGcod_NumLayers" type="uint16">1</Field><br><br></div><div>I'm
 guessing the fact that my JP2 file only has one layer is the reason 
vsis3 works well with it, regardless of it being LRCP (not optimal for 
windowed reads). </div><div><br></div><div>Anyway, thanks. I learned 
some more about JPEG2K here. Unfortunately I think I'm pretty out of 
luck on the prospect of doing remote windowed reads quickly on this 
data. However, I'm very open to suggestions if anyone has any ideas on 
how it might work. <br><br></div>Cheers.<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 24, 2017 at 11:21 AM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div style="font-family:'Sans Serif';font-size:9pt;font-weight:400;font-style:normal">
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">Mike,</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">(note to other readers: this is the continuation of the thread</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">[gdal-dev] VSIS3 on digital globe multiview-stereo (NITF) )</p><span class="">
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> I turned on some debug options that shed some light on to what's going on.</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> It appears that the NITF driver must internally open a JPEG 2000 Driver on</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> a virtual subfile. In my case, that virtual subfile starts at offset 4038</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> and continues to the end of the file, offset 901949970.</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> While this is a nice way of providing a JPEG2000 decompression routine to</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> the NITF driver, when accessing a remote dataset, it causes the entire file</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> to be downloaded even when reading a small window.</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> I used gdal_translate locally on my NITF file and turned it into a JP2</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> file, then I uploaded this file to S3 and ran my gdal_translate -srcwin 000</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> 000 1000 1000 /vsis3/mybucket/jp2file.JP2 local_file.tiff and it ran</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> instantly. Is there a way to completely bypass using the NITF driver and</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">> simply open the NITF file with the JP2 driver wrapped up with vsis3?</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
</span><p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">Yes, you should be able to open the following filename, but this is actually what the NITF driver does :</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">/vsisubfile/4038_901949970,/<wbr>vsis3/glitch253/test2.ntf  (you may need to adjust the second value '901949970' to be 901949970-4038, since it is supposed to be a lenght and not an offset)</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">This shoud be recognized by one of the JPEG2000 drivers, and you should likely get the same performance characteristics as using it through the NITF driver (or the NITF driver does something that requires reading the whole file, but I don't think so)</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">My hypothesis is that the root cause of the performance issue comes is the progression order of the JPEG2000 codestream of this NITF file, that causes most of the file to be read through. Likely only X % of bytes are really read, but as they are scattered throughout the whole file, given the chunk by chunk downloading logic of /vsis3, you end up reading the whole file in practice.</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">For example I'd expect LRCP (Layer-Resolution-Component-<wbr>Precincts), RLCP and RPCL to cause issues. Whereas PCRL and CPRL should perform better for windowed requests.</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"><a href="http://www.gwg.nga.mil/ntb/baseline/docs/bpj2k01/ISOJ2K_profile.pdf" target="_blank">http://www.gwg.nga.mil/ntb/<wbr>baseline/docs/bpj2k01/ISOJ2K_<wbr>profile.pdf</a> recommands using LRCP with 19-20 quality layers, so that would indeed cause a lot of seeking through the file. You can check the progression order in the output of the following (check for "SGcod_Progress")</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">python dump_jp2.py /vsisubfile/4038_901949970,/<wbr>vsis3/glitch253/test2.ntf</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">where dump_jp2.py is</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"><a href="https://svn.osgeo.org/gdal/trunk/gdal/swig/python/samples/dump_jp2.py" target="_blank">https://svn.osgeo.org/gdal/<wbr>trunk/gdal/swig/python/<wbr>samples/dump_jp2.py</a></p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">It is likely that your translating into JP2 turn the original codestream into one with a progression order that is more seeking friendly (the default progression order may be different depending on drivers)</p><span class="">
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">Even</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"> </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">-- </p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px">Spatialys - Geospatial professional services</p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"><a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a></p></span></div></blockquote></div><br></div></div>