mynameisjohnj's profile - activity

Hi Balaji, good point about that scale factor. A few of these steps can certainly be collapsed.

I got the "expected output" by just double clicking the image in Windows (it opens in the default "Photos" program), but I'm not aware of this pipeline you speak of so that's definitely a good lead! No powerpoint here unfortunately, but I'll find a way of opening that presentation. Thanks!

edit: here are some links on the pipeline https://pdfs.semanticscholar.org/519e... http://www.cs.cmu.edu/afs/cs/academic...

if anyone finds this. I'll return with any positive results.

Unfortunate, but this is an acceptable answer.

CMake Docs

Some example on google

It was a pretty quick google search.

What is your intent? You may be able to link against other libraries and point the compiler at other include directories, but without changing the opencv code to use those libraries it would be kind of useless.

Hi all,

First off, this is a duplicate of this question: http://answers.opencv.org/question/31...

I'm in basically the same situation as those two; Windows 10 64 bit, OpenCV3 compiled with OpenGL and CUDA. On Debug the sample found at https://github.com/Itseez/opencv/blob... compiles and links fine, and even runs up until the draw call, at which point an error is thrown at line 1350 of opengl.cpp.

    gl::EnableClientState(gl::TEXTURE_COORD_ARRAY);
    CV_CheckGlError();

exactly as described in that post. If I set my build config to release then the program runs fine (and I see a lovely image of chicky_512 rotating slowly.)

The answer in the thread I linked hinted at commenting out those checks in the source and recompiling, but I'd rather not do that.

Is there anything I can do about this error? I'd like to be able to debug my code, so if not I'll try and use GLUT or SDL2 next.

Thanks,

john

I would say that pklab's answer is the right one. However, I am very lazy and dumb, but I needed to do this with the cudafilters library the other day and did it as follows. The only caveat to this is that you need the Visual studio solution created by CMake on hand.

1. Open up your solution of the project you're working on, and make sure you're on Debug
2. Right click your solution in the solution explorer, select Add Existing Project, and add the .vcxproj that corresponds to the OpenCV module you'd like to debug. The project should now be in your solution.
3. If you link against the debug libraries made by OpenCV, then stepping into these functions should allow you to see the OpenCV code.

The trick is having the OpenCV module project alongside the project you're working on in the Solution explorer. Once you're done you can remove the reference to the OpenCV project and continue.

I'm sure other people have run into this same issue, but given the tutorial you used it's tough to say. Running 'make install' will copy the built libraries to wherever the install directory was set during the cmake call (probably /usr/local/lib), and if the OpenCV 2.4.11 libraries were already there then running 'make install' with OpenCV3 would have overwritten in them, in which case you no longer have OpenCV2.4.11.

If that is the case (and it may not be), then you'd have to reinstall OpenCV 2.4.11. If you do have to reinstall it, you should specify the install directory as something distinct (/opt/opencv2 or something, just to make it clear that it's separate from OpenCV3).

So I guess the first thing to do would be to check which version gets picked up by your compiler by default, i.e if you don't specify any link or include directories and run a program that prints out the OpenCV version, check whether it's 2 or 3.

@StevenPuttemans So do you have any suggestions? And if my comment wasn't clear... I'm never actually "pushing the data" back from the GPU. I agree that in most cases it wouldn't be worth the effort, but I'm kind of using this for a larger project that will involve using thrust and context sharing with OpenGL, so I'd definitely like to get it on my graphics card as soon as possible (especially for something like this type conversion and division, which is what you'd call embarrassingly parallel.)

My guess is cudawarping.hpp

Fair question. My intent is to perform some further processing on the image, and I assume there is some added benefit to displaying the GpuMat inside a namedWindow created with OpenGL (maybe that assumption is wrong.) My thinking was that if I'm displaying the image, it's going on the GPU somehow, so if I can I may as well get it there as soon as possible.

Furthermore I plan on running this code on a Jetson TX1, and my intent is to verify that data transfer is cheaper on that device, given that the memory storage for the CPU and GPU are physically unified, but that is beside the point.

Hi All,

I've got a very basic example that grabs frames from a camera, uploads them to a GpuMat, and displays them in a namedWindow with CV_WINDOW_OPENGL as its type. The code below works as expected, but I don't understand why I have to perform the data type conversion using the host mat.

#include <opencv2/core/core.hpp>
#include <opencv2/core/cuda.hpp>
#include <opencv2/highgui/highgui.hpp>

#include <iostream>

int main() {
    using namespace cv;
    using cv::cuda::GpuMat;

    VideoCapture cap(0);
    if (!cap.isOpened())
        return -1;

    // create opengl window
    namedWindow("webcam", CV_WINDOW_OPENGL);

    // Gpu mat to display
    GpuMat g;

    // Host frame buf
    Mat frame;

    bool grabFrame = true;
    while (grabFrame) {
        // Grab frame
        cap >> frame;

        // Why is this line necessary?
        frame.convertTo(frame, CV_32F);

        // Upload to gpu
        g.upload(frame);

        // convert to normalized float
        g.convertTo(g, CV_32F, 1.f / 255);

        // show in opengl window
        imshow("webcam", g);

        // maybe quit
        if (cv::waitKey(30) >= 0)
            grabFrame = false;
    }

    return 0;
}

If I comment out that line and try to perform the conversion and division in one step, I get a black image. I thought it could be the order in which the conversion happens (i.e scale followed by conversion), so I tried this

g.convertTo(g, CV_32F);
g.convertTo(g, CV_32F, 1.f / 255);

but had no luck. Checking the type of image the camera yields returns 16, which is a 3 channel single byte image. I tried replacing CV_32F with CV_32FC3 but it didn't make a difference. For what it's worth, though, the final dataType of the gpumat is 21, which is CV_32FC3. The thing that breaks it seems to be the type conversion.

Are there limits on the data types we can convert?

Hi all,

In the docs for the old gpu module it is said that FilterEngines do not support in-place operations. Is this true of the new cuda module? It seems to be, since my dilation ends up being a bit wonky unless I supply a separate output mat, but it's a little confusing since the beta OpenCV3 cuda docs don't mention it, and the host code does support in-place dilations (I think.)

Thanks for any help you can provide.

John

P.S

As an aside, the rounding involved in converting my images from CV_32F to CV_8U kind of messed me up... I figure the reason only single-byte channels are supported for dilation is some sort of performance issue, but if instead the case is that there just isn't anyone around to implement it I'd be happy to try.

It's kind of strange, because the old ocl module docs from 2.4 said the same thing (only works with single-byte data), but I remember being able to run that operation on floating point images... I'm not sure what the docs say WRT UMats now.

Hi, I recall I ran into something like this because I was trying to build 32-bit libraries, but the CUDA toolkit only supplies performance libraries (cuFFT, cuBLAS, etc.) as 64 bit. It's probably possible to get the 32-bit libraries, or you can build 64-bit OpenCV.

http://stackoverflow.com/questions/33...

Of course I could be wrong... I also ran into some trouble using VS2015. I didn't know you could just install NSight Studio 5.0, so I just compiled and used 2013. If changing the library bitness does solve this for you, could you explain what you did to get CUDA 7.5 working in 2015?

Also another thing is that if have a CUDA capable device with sm_50, you don't set your CUDA_ARCH variable to 5.0 or higher, which will drastically reduce your compile time and maybe prevent crashes. I actually don't understand the issue here, it seems like CUDA code was compiled at runtime prior to the 5.0 architecture (maybe?)

http://stackoverflow.com/questions/30...

John