wpd's profile - activity

Thanks for the tips... I have a specific question about a specific image, so I don't want my image to be corrupted by the compression process. I was hoping somebody could tell me, "The way we usually do this on the OpenCV forum is to upload the image to Google Photo Archive(tm), where it will be be archived, uncompressed, for all eternity." I feel like this should be a solved problem for the OpenCV forum, and that I'm missing something fundamental by not being able to find the solution easily.

I have a question about the performance of the cornerSubPix() function and would like to upload a reference image and the code I am using to find the subpixel resolution of the corners.

What is the best way to upload a .pgm image for reference by readers of this forum?

--wpd

Thanks. That's a fabulous answer, and very well presented.

I wonder how it would compare to just using the at() function to stride through the data. It seems (at first glance) to be roughly the same complexity, in that each iteration through the loop, the address of the next element is computed by adding offsets and multiples of step sizes to the base address.

Ideally, I would like to figure out a way to do this using pointers (iterators) and to have the compiler keep track of the right number of bytes by which to decrement my pointer each time through my loop.

Or, equivalently, why does the following code crash (on my Ubuntu 12.04 LTS box running OpenCV 2.4.5)

#include <iostream>
#include <opencv2/core/core.hpp>

using namespace cv;
using namespace std;

int
main(int argc, char *argv[])
{
  Mat m = (Mat_<int>(3,3) << 1, 2, 3, 4, 5, 6, 7, 8, 9);
  cout << m << endl;

  MatConstIterator_<int> Mptr = m.col(0).end<int>() - 1;
  for (int i = 0; i < 3; i++) {
    cout << (int)*Mptr-- << endl;
  }
  return(0);
}

I feel like this should work, but it crashes on the second iteration through the loop. I'm not completely comfortable with C++ iterators, and don't understand the nuances of begin()/end() vs rbegin()/rend(), but, as there is no rbegin()/rend() defined for OpenCV matrices, I guess that doesn't matter. Can somebody tell me what I'm missing here?

What is the correct way to iterate through a column of data in reverse order?

Thanks.

--wpd

Thanks. I'll go do that (he says hopefully and enthusiastically). It's (literally) the least I could do after running into this.

Thanks. I was confused that the "camera driver" for reading .bmp files does not support querying the frame format. From your answer to my other question, it would seem that the default format is CV_8UC3 and that I should be able to assume that in the absence of any other knowledge.

I'm ok with that. I wish it were better documented somewhere.

Thanks for the reply. I didn't realize that I will always get a BGR stream out of my VideoCapture object. That's a pretty key piece of information. Do you know how can I go about getting that added to the documentation?

Setup: Suppose I want to read images from arbitrary cameras or input files and don't know ahead of time if the images will be greyscale, color, 8 bits/pixel, 16 bits/pixel, etc...

I used to think that I could call get(CV_CAP_FRAME_FORMAT) to determine the fixed frame format for the images returned by my VideoCapture() object, but I have since learned that I cannot count on that feature being implemented, even for fixed format .bmp files.

Is there some common OpenCV idiom for determining the input format of a camera (or file) and for dynamically transforming that to the format required by downstream processing?

For example, suppose I have a single channel grayscale image (CV_8UC1) that I need to convert to RGB because my downstream algorithm assumes/requires RGB (or vice versa). I can call cvtColor() to do the conversion, but I must not do that if the input data stream is already an RGB stream. How do OpenCV experts typically handle this situation?

I could do something like this:

while (true) {
  cap >> image;
  switch(image.type())
  case CV_8UC3:
    // This is what my downstream algorithm expects
    // (Actually, I can't tell if the image is in RGB or BGR format
    // here.  That's probably yet another problem all together).
    break;

  case CV_8UC1:
    Mat converted;
    cv.cvtColor(image, converted, CV_GRAY2RGB);
    image = converted;
    break;

  ...

Thanks.

--wpd

Thank you for your answer. I guess that makes sense, although it is a bit confusing that, when reading from a .bmp file with a fixed format, OpenCV is unable to determine the format of the data.

Is it possible that CV_CAP_PROP_FORMAT doesn't return the CV_<bit-depth>{U|S|F}C(<number_of_channels>) value that I naively expected it would?

I'm going to go ask a different question now...

--wpd

Consider the following snippet of code:

VideoCapture cap(argv[1]);
int frame_format = cap.get(CV_CAP_PROP_FORMAT);

When I run this, and pass in a .bmp file as argv[1], the call to get(CV_CAP_PROP_FORMAT) returns 0. I would have expected it to return 16 (CV_8UC3).

When I fetch an image from the file with

cap >> image;
int image_type = image.type();

I get the 16 I expect.

Thanks for any tips you can give me.

--wpd