Closed YukihoAA closed 5 years ago
Works fine with Ubuntu & Windows
The output Image size limit is around 13370 and this issue is about size limit due to we use INT_MAX everywhere. (in my test, output image 13370*13370 is limit size of square image)
in our convert function you can easily find width and height is int char, that is 32bit.
13370 is nearly limit of int.
root(0xFFFF FFFF div 24) = 13,377.479957....
so i think it is limit of image size. (INT_MAX)
I tried to proof exact limit buf size of image is INT_MAX but i cannot because of lines like this.
This is not openCV 's problem and it is our problem, but I don't think we have to remake all of functions to support huge image like this... (opencv can read/write this big image)
We may consider split images in small pieces and run w2x and combine them out side of libw2x (libw2x's Buffer class only supports INT_MAX)
if we want to support this issue, i think split image is best idea.
This may seem obviously wrong but, Is it impossible to switch to long int or similar?
Otherwise I guess it wouldn't be too hard to split the image /4 and iterate over each part the same we already do over the whole image.
I have no idea with CL or CUDA but they may uses int too.
So i think it is more safe to implement divide in 4 pieces or max_image_size or something is better.
There was possible chance of memory fault in previous version of W2Mat.
Previous version of W2Mat won't be problem in most of the time because our program always using stack one direction.
but our program runs in multi-thread, so it can cause memory fault during operation.
what i did is made data to return by arguments not just returning,
so It will not produce dangling pointer anymore.
This PR doesn't fix issue #122, but this PR will be help.