Stall with some jpip requests

[pentath]

I am experiencing stalls when making high resolution requests far away from the origin of a JPIP image stream. The IAS Viewer gets quick results for the same regions and resolutions from the exact same URL. I'm using Kakadu 6.4, no speedpack, 64 bit build on Centos 5.3, with gdal trunk @ 20320.

The results of gdalinfo lead me to believe such a request should be fast:

"Band 1 Block=2048x128 Type=UInt16, ColorInterp=Undefined Overviews: 5012x25000, 2506x12500, 1253x6250, 627x3125, 314x1563, 157x782, 79x391"

Note that because the data is a single 10 bit band, I am adding -scale 0 1023 0 255 to my gdal_translate requests.

When I use gdal_translate with a -srcwin of 5000 5000 100 100, the request simply halts. It might come back if I waited long enough, but after 30 minutes I killed the request. A srcwin of 0 0 100 100 comes back in 1-5 seconds, a variation I presume is due to server load.

An example command that stalls:

gdal_translate -srcwin 5000 5000 100 100 'jpip://hijpip.lpl.arizona.edu:8064/PDS/EXTRAS/RDR/ESP/ORB_018400_018499/ESP_018487_1470/ESP_018487_1470_RED.NOMAP.JP2

I discussed this with FrankW on gdal.freenode.net, and he claims around 10s to get responses for the same request. We both enabled debug output, and there is an interesting difference in the FETCH command used:

My result: ​http://hijpip.lpl.arizona.edu:8064/jpip?cid=JPH_4B3375C248A85B54&stream=0&type=jpp-stream&roff=5000,5000&rsiz=-4921,-4609&fsiz=79,391,closest&quality=20&comps=0&len=2000

Frank's result: ​http://hijpip.lpl.arizona.edu:8064/jpip?cid=JPH_95A1107310247CE1&stream=0&type=jpp-stream&roff=5000,5000&rsiz=100,100&fsiz=10024,50000,closest&quality=20&comps=0&len=2000

Please let me know if more info is needed. I can easily patch this build if I can assist with testing of a fix.

[warmerdam]

I have upgraded to Kakadu 6.4 and confirm I see a similar behavior. The rsiz value is negative, and the fsiz is small and things seem to hang. Digging deeper.

[warmerdam]

It appears there has been a change in the behavior of get_rendered_image_dims() method on the decompressor since Kakadu 6.0. It was previously ignoring any installed input restrictions but that is no longer the case. I have added calls to clear the input restrictions in trunk (r20368) and 1.6-esri (r20869).

Eric, could you try refreshing from trunk and confirm things work properly for you now?

Thanks for the bug report!

[pentath]

That has done it. For this particular image at least, it responds in 7-10 seconds over 20 essentially randomly places requests. Best yet, there seems to be no correlation to performance and query location, which matches my expectation with iasview.

Thanks for such a swift response Frank!

• Eric