Issue3258

[ramiromagalhaes]

This pach forces the coertion to size_t of certain arithmetic operations that determined the buffer sizes of a Matrix while cv::imread'ing a big PGM file I have.

Also, I changed the name of a local variable named "readed" to read. This variable simply counts the amount of bytes read from a RLByteStream.

[ramiromagalhaes]

Since size_t is unsigned, this assertion became useless.

[asmorkalov]

@SpecLad, @vpisarev Please look at it.

[SpecLad]

This isn't quite correct, because m_block_pos is used as an offset for fseek, which only accepts a long.

I also question the necessity of changing m_block_size to size_t, given that it's only ever set to BS_DEF_BLOCK_SIZE, which is well within the range of int.

[ramiromagalhaes]

@SpecLad I made a couple changes addressing your comments. Indeed, m_block_size has no need to be of type size_t and I did test this with my big image. However, when I changed m_block_pos back back to int for testing purposes, altough the cv::imread method did run without crashing, the image displayed misplaced lines.

[SpecLad]

Try long.

[ramiromagalhaes]

@SpecLad long works fine too.

[ramiromagalhaes]

But seriously, I think that using long is not a good thing since its size depends on the platform we're compiling on.

[alalek]

Please fix these warnings (Win x64, MSVS 2010):

    13>..\..\..\opencv\modules\highgui\src\grfmt_pxm.cpp(171): warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data [C:\buildslave\precommit_OCL-win64-vc10\build\modules\highgui\opencv_highgui.vcxproj]

    13>..\..\..\opencv\modules\highgui\src\grfmt_sunras.cpp(121): warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data [C:\buildslave\precommit_OCL-win64-vc10\build\modules\highgui\opencv_highgui.vcxproj]

    13>..\..\..\opencv\modules\highgui\src\grfmt_sunras.cpp(134): warning C4267: '=' : conversion from 'size_t' to 'int', possible loss of data [C:\buildslave\precommit_OCL-win64-vc10\build\modules\highgui\opencv_highgui.vcxproj]

    13>..\..\..\opencv\modules\highgui\src\bitstrm.cpp(177): warning C4267: '=' : conversion from 'size_t' to 'long', possible loss of data [C:\buildslave\precommit_OCL-win64-vc10\build\modules\highgui\opencv_highgui.vcxproj]

    13>..\..\..\opencv\modules\highgui\src\bitstrm.cpp(237): warning C4267: '+=' : conversion from 'size_t' to 'int', possible loss of data [C:\buildslave\precommit_OCL-win64-vc10\build\modules\highgui\opencv_highgui.vcxproj]

[ramiromagalhaes]

Will check that pretty soon.

[SpecLad]

But seriously, I think that using long is not a good thing since its size depends on the platform we're compiling on.

Point is, fseek accepts a long, so using a size_t won't make a difference in the end. But I guess you can use size_t if you want.

[vpisarev]

step.p[0] is already size_t, the change is not needed

[ramiromagalhaes]

@alalek I might have some problem to deal with those warnings since I do not have a Windows machine to try and fix those warnings. Is there a gcc warning that I might turn on so that I get a similar output?

[SpecLad]

@ramiromagalhaes I think it's -Wconversion. I don't see any warnings right now, though, perhaps you've already fixed them by accident.

[mdim]

@vpisarev Could you please back to review this PR?

[BKNio]

@vpisarev just remind you to review :)

[snosov1]

@vpisarev ping

[Daniil-Osokin]

@vpisarev Just a reminder.

[BKNio]

@ramiromagalhaes 10x PR! unfortunately there are build warnings: http://pullrequest.opencv.org

[ramiromagalhaes]

Ok, I'll try to get back to this soon (this time, for real). I'll check those warnings pointed by @alalek and @BKNio following @SpecLad 's advice of using (-Wconversion).

[vpisarev]

as I see, there is no progress on PR, long and size_t are still used where they should not be. Actually, the images could be converted to, e.g., png format, so it's not a huge problem. Let's close this PR for now as we are cleaning the list of opened PR. @ramiromagalhaes, when you have time to address the pointed out issues, please, feel free to re-open the PR.

[marisvali]

Hello. We are using opencv in a commercial project and we work with huge tif files (a little over 4gb). As a workaround to this issue, we are using a different library to read the huge tif file, then we convert the data to a Mat. It would be great if this issue would be solved.