serratus/quaggaJS

quaggajs | Uncaught RangeError: Invalid typed array length on

Opened this issue · 5 comments

I was experimenting with quaggajs before integrating it in a potential app I plan to build I faced a problem, I am just curious to know if it's an issue? (Check the attachment)

Thank you

Additional information : This error occured also in an other image with size 1200 x 1550.

quag_err

I have noticed that the sample app doesn't seem to work when set to 1920, I've never looked into why. I don't presently know if that's a limitation of the app or the library itself.

if you could supply an image that size with a hopefully readable barcode, that'd be great to have in our test fixtures

First of all, I apologize for my late answer, I presume that we live in different time zones.
Secondly, I mistakenly posted an image in the comment above which had a code 128 selected, I updated it to code 39, since the image which I will share it contains a code 39 barcode.

  1. Image which appears on the issue :

code39_example

  1. Another example where the same problem occurs (I attached this image because it has a different size, maybe can be help)

code128_example

Note that it (second example) works when you provide these parameters :

image

but it won't work if you turn the half sample off (only when patch size is x-large):

image

Have a good day!l

@ericblade

there is a piece of code in initBuffers function as follows :
skeletonImageData = new ArrayBuffer(64 * 1024); # 65536
new Uint8Array(skeletonImageData, _patchSize.x * _patchSize.y * 3, _patchSize.x * _patchSize.y);

in my case _patchSize.x and _patchSize.y were calculated as 186 which makes the byteOffset paramter 103788, and the length parameter 34596. I suppose that this might be the problem.

Thank you for digging into that!

hmm. ok, so, we have a 65536 buffersize, it offsets way outside of that, with a length that is almost half that. Makes sense.

So, if you're going out to position 103788 and adding length 34596, it wants the ArrayBuffer to be at least 138384 .. so to combine those settings, it looks like the quick fix would be to make the ArrayBuffer at least 138384, so around about 2163k instead of 64k.

I've made a note about this on my fork, to research what the best way would be to fix it, but I'm pretty sure that if you were to bump that ArrayBuffer line to 2163+ it would at least get farther than it does now.