Documentation and Assertion mismatch for cv::threshold (Bug #3160)

Added by Md Iftekhar Tanveer over 11 years ago. Updated over 11 years ago.

Status:Cancelled Start date:2013-07-17
Priority:Normal Due date:
Assignee:Andrew Senin % Done:

0%
Category:imgproc, video
Target version:2.4.7
Affected version:branch '2.4' Operating System:Any
Difficulty:Easy HW Platform:Any
Pull request:

Description

The documentation for c++ interface of cv::threshold says: "src – input array (single-channel, 8-bit or 32-bit floating point).". However, the assertion in code says (src.type() == CV_8UC1). So, the threshold fails for 32 bit floating point.

Associated revisions

Revision 4d9d7e6d
Added by Vadim Pisarevsky over 10 years ago

Merge pull request #3160 from akarsakov:ocl_dft_double_support

History

#1
Updated by Andrew Senin over 11 years ago

Thanks for submitting the bug. We will try to address it in the next release.

But if you can fix it and send us a pull request (please see more info here: http://code.opencv.org/projects/opencv/wiki/How_to_contribute) it would be really great!

  • Difficulty set to Easy
  • Target version set to 2.4.7
  • Category set to imgproc, video
  • Assignee set to Md Iftekhar Tanveer

#2
Updated by Steven Puttemans over 11 years ago

I think this bug report is not correct. Looking at the code I see the following two uses of the code:

CV_Assert( src.type() == CV_8UC1 )

First one on line 719, which is to check if it is 8 bit unsigned integer, which then applies otsu thresholding. However this is only implemented for the 8bit so this check should be made!

Second one on line 796 which checks if adaptiveThresholding can be applied. However, again here you only want to push in 8 bit unsigned integers, as the algorithm requests it.

Basically if it skips all steps in the threshold process, due to not being the correct format, at the end it stills call thresholding by this code:

parallel_for_(Range(0, dst.rows),
                  ThresholdRunner(src, dst, thresh, maxval, type),
                  dst.total()/(double)(1<<16));

So I am guessing the code is actually correct?

  • Assignee changed from Md Iftekhar Tanveer to Andrew Senin

#3
Updated by Steven Puttemans over 11 years ago

And to actually show that it works, when jumping to the thresholdrunner function you have the operator defined as:

void operator () ( const Range& range ) const
{
        int row0 = range.start;
        int row1 = range.end;
Mat srcStripe = src.rowRange(row0, row1);
        Mat dstStripe = dst.rowRange(row0, row1);
if (srcStripe.depth()  CV_8U)
{
            thresh_8u( srcStripe, dstStripe, (uchar)thresh, (uchar)maxval, thresholdType );
        }
        else if( srcStripe.depth()  CV_16S )
{
            thresh_16s( srcStripe, dstStripe, (short)thresh, (short)maxval, thresholdType );
        }
        else if( srcStripe.depth() == CV_32F )
{
            thresh_32f( srcStripe, dstStripe, (float)thresh, (float)maxval, thresholdType );
        }
    }

So this clearly states that CV_32F is actually allowed. The only change I think that needs to be added to the documentation, is that there is actually allowance of CV_16S typed input for thresholding, which is not in documentation?

#4
Updated by Andrew Senin over 11 years ago

Steven, thanks for your help! Agree, no problem here. Also, the documentation states that "Currently, the Otsu’s method is implemented only for 8-bit images". So, I'm closing the issue.

  • Status changed from Open to Cancelled

#5
Updated by Steven Puttemans over 11 years ago

Thx for the review.

Also available in: Atom PDF