Integer size for drawing. Limited to short. (Feature #2890)

Added by Michael May almost 12 years ago. Updated almost 10 years ago.

Status:Done Start date:2013-03-15
Priority:Normal Due date:
Assignee:Vadim Pisarevsky % Done:

0%
Category:core
Target version:-
Difficulty: Pull request:

Description

Hello

I have a large image greater than 32768px wide.

When I try and draw on the image at an x position greater than 32768 nothing is drawn. I think the value is limited to 16 bit even though the input value for cv::Line in cv::Point which specifies int. When I get the size of an int from c++ it states that the max is 2,147,483,648 which is 32 bit.

When I read the value from the cv::Point they are greater than 32768 but once they are passed to the opencv drawing functions it seems that they are truncated.

The system is 64bit Windows 7. VC++ 2010 and OpenCV 2.4.3. I am building a 64-bit application.

History

#1
Updated by Daniil Osokin almost 12 years ago

Hi!, Michael!
Could you try to create a ROI after 32768px position and try to draw line in this ROI?

  • Assignee set to Michael May

#2
Updated by Daniil Osokin almost 12 years ago

  • Category set to core

#3
Updated by Michael May almost 12 years ago

Daniil Osokin wrote:

Hi!, Michael!
Could you try to create a ROI after 32768px position and try to draw line in this ROI?

I have done so, that was my work around. It seems like a bug though that the input is an int when that max that can be used is a short in reality. The function should make this clear.

#4
Updated by Daniil Osokin almost 12 years ago

Thanks! Could you create a pull request with bugfix (http://code.opencv.org/projects/opencv/wiki/How_to_contribute)? It will speedup fixing in many times!

  • Assignee changed from Michael May to Vadim Pisarevsky

#5
Updated by Gurpinder Sandhu almost 12 years ago

I looked into this problem
It seems that the line function has been explicity designed for 16-bit wide numbers with other 16 bits left for the fractional part (given using "shift" argument to line)

The function line calls ThickLine where the points p0 and p1 are effectively truncated in the following code:


p0.x <<= XY_SHIFT - shift;
p0.y <<= XY_SHIFT - shift;
p1.x <<= XY_SHIFT - shift;
p1.y <<= XY_SHIFT - shift;

where XY_SHIFT is defined as 16.

The whole line function seem to have been built with the above mentioned idea.
@Vadim Pisarevsky I can provide a bugfix for this particular situation where points are greater than 16-bit number and fractional part required can also be accomodated in 32-bits)
Or the other option is to completely change the line function to allow for any number whose significant bits can be accommtade in 32-bit wide space.

#6
Updated by Kirill Kornyakov almost 12 years ago

Gurpinder, I think you can proceed and submit a pull request with he proposed change. It will be considered for integration.

  • Affected version changed from 2.4.3 to 2.4.5 (latest release)

#7
Updated by Vadim Pisarevsky almost 10 years ago

ok, this is long overdue. The fix would not be easy to check for correctness and compatibility with all existing code. I change it to the feature request.

  • Tracker changed from Bug to Feature

#8
Updated by Vadim Pisarevsky almost 10 years ago

the corresponding PR has been put to 3.0-pre

  • Status changed from Open to Done

Also available in: Atom PDF