search

geotiffjs / geotiff.js

geotiff.js is a small library to parse TIFF files for visualization or analysis. It is written in pure JavaScript, and is usable in both the browser and node.js applications.
https://geotiffjs.github.io/
MIT License
878 stars 183 forks source link

Offset is outside the bounds of the DataView #52

Open skynice opened 6 years ago

skynice commented 6 years ago

`[Violation] 'setTimeout' handler took 62ms lzw.js?8b40:17 ran off the end of the buffer before finding EOI_CODE (end on input code) getByte @ lzw.js?8b40:17 geotiffimage.js?5c03:327 Uncaught (in promise) RangeError: Offset is outside the bounds of the DataView at DataView.getFloat32 () at eval (geotiffimage.js?5c03:327)

source.js?c402:32 Uncaught (in promise) RangeError: Invalid typed array length: -610682 at typedArrayConstructByArrayBuffer () at new Uint8Array (native) at readRangeFromBlocks (webpack-internal:///143:116:23) at BlockedSource._callee3$ (webpack-internal:///143:454:51) at tryCatch (webpack-internal:///94:63:40) at Generator.invoke [as _invoke] (webpack-internal:///94:337:22) at Generator.prototype.(anonymous function) [as next] (webpack-internal:///94:96:21) at step (webpack-internal:///29:17:30) at eval (webpack-internal:///29:28:13) at readRangeFromBlocks @ source.js?c402:32 source.js?c402:32 Uncaught (in promise) RangeError: Invalid typed array length: -620184 at typedArrayConstructByArrayBuffer () at new Uint8Array (native) at readRangeFromBlocks (webpack-internal:///143:116:23) at BlockedSource._callee3$ (webpack-internal:///143:454:51) at tryCatch (webpack-internal:///94:63:40) at Generator.invoke [as _invoke] (webpack-internal:///94:337:22) at Generator.prototype.(anonymous function) [as next] (webpack-internal:///94:96:21) at step (webpack-internal:///29:17:30) at eval (webpack-internal:///29:28:13) at `

constantinius commented 6 years ago

Hi @skynice

Thanks for submitting this issue. This seems like an error with LZW decoding. Could you please provide the TIFF file where this error occurs? Maybe I can have a look at it.

skynice commented 6 years ago

@constantinius please download in http://182.92.155.46:81/geotiff.tif

constantinius commented 6 years ago

hm... when I try to open it with the basic testing html file it seems to load correctly (see image below; it is colorized using a color scale). What version of geotiff.js have you installed? Can you show me some code how you use it?

image

skynice commented 6 years ago

@constantinius i clone the git project , in my project ,i use like this:




    
    Title

my browser is chrome 61.0.3163.79

please download in http://182.92.155.46:81/localhost.zip .see my chrome request deatials

skynice commented 6 years ago

@constantinius if i use like this, the worked...

Title
constantinius commented 6 years ago

Alright, I see, I'll investigate further!

constantinius commented 6 years ago

@skynice Okay, I think I now know what the issue is.

The problem seems to be twofold.

First: your server does not seem to understand HTTP Range requests, as it seems to answer with the complete file, when it actually only should respond with a portion of it.

Second: there seems to be a bug in handling exactly that case in the fromUrl method within geotiff.js

If you are looking for a solution right now, you can use your second approach (downloading beforehand and using fromArrayBuffer) or use a different server that understands HTTP Range requests.

In any case, I'll try to fix the issue, but I cannot promise that it will be in the near future, as I'm quite involved in other tasks.

Please let me know if you have found a suitable solution. Thanks again for reporting this issue!

skynice commented 6 years ago

@constantinius thank you very much. i use webstorm nesting web server found the problem.today i receiver your reply ,i try iis or node express ,the function correctly

jukkatolonen commented 5 years ago

Hi @constantinius,

Do you have an estimate when this issue with fromUrl method will be fixed?

constantinius commented 5 years ago

Hi @jukkatolonen

Do you have the same issue? If yes, you could mitigate it by switching to a server that properly supports range requests and the issue should not arise.

Regarding the issue itself: the response size is not actively enforced, but it is handled in a more robust way when unexpectedly the whole file is returned.

I think there need to be more configuration options for those cases (like raising errors, when the whole file is returned unexpectedly or just continue).

There is currently no direct plan to fix the issue, as there are currently no resources to address this issue.

jukkatolonen commented 4 years ago

Ok, thanks. I have some what similar issue but nothing that can't be worked around. Was just curious about the plans regarding this issue.