Open kvmanohar22 opened 7 years ago
Sounds great. Indeed, the reason for using the std container at
method in convertToMat
and generally in OpenCV.jl
was initially to keep things simple. However, as you correctly pointed out setgray
and setcolor
already demonstrates that using pointers is obviously feasible in this library. Indeed using GPU Mat (UMat
) in addition can speed up image manipulation as well.
I suggest that you look into creating methods with templates
so that it is easy to call the same function with any Type. I believe that I tried looking into this early on, but there was no support for Templates in Cxx.jl
. Have a look also at misc.jl in Cxx.jl.
@maxruby I think we need to completely rewrite the src/OpenCV_Mat.jl to include templates. How about I open a WIP PR ?
Sure, go ahead! If you have more specific questions, just let me know. I will do my best to answer as quickly as possible.
@kvmanohar22 . You are welcome to have a look at WIP branch mat_templates
. It already supports conversion of JuliaImages 2d and 3d arrays to std::vector
. For 2d array images, conversion to cv::Mat_<T>
is working fine (getters and setters), but RGB image conversion still need some small fixes. Suggestions are welcome.
I think getPixel
and getPixel3d
should work for RGB images too ?
I think getPixel and getPixel3d should work for RGB images too ?
Indeed, I think both should already work. Currently stdvec3Mat_
is not working, but it should be easy to fix. The problem is in the inner assignment loop in stdvector3Mat_
.
Other than that, there are a number of tasks to be done:
cv::Mat_<T>
back to Julia Image arraysIf you would like to work on these, feel free to fetch the mat_templates
branch and then submit a new PR.
I will try to clean up the new methods by tonight. There are a number of breaking changes brought as a result of changing the cv::Mat
getters and setters. I need to have a look more carefully when I have time.
If you would like to work on these
Yes, I would like to work on them.
There are a number of breaking changes
Yes this too, I tried testing the new implementation but got errors, specifically when I tried importing OpenCV with mat_templates
branch checked out, this error popped up.
Yes this too, I tried testing the new implementation but got errors, specifically when I tried importing OpenCV with mat_templates branch checked out, this error popped up.
I assume this is an OS or setup-related error since I do not see it.
You mentioned in relation to this error that:
I had opencv 2.4.0 and opencv 3.0.0 installed previsouly and on top of this I installed 3.2.0. This caused errors. Finally I removed all the versions of opencv (including the shared object files) and did a fresh install of opencv 3.2.0. And then as you mentioned I commented #include statements for flann in opencv.hpp and the problem was solved !
Which error specifically do you see in the REPL?
julia> using OpenCV
ERROR: LoadError: ReadOnlyMemoryError()
Stacktrace:
[1] dlopen(::String, ::UInt32) at ./libdl.jl:97
[2] macro expansion at /home/kv/.julia/v0.6/OpenCV/src/OpenCV.jl:75 [inlined]
[3] anonymous at ./<missing>:?
[4] include_from_node1(::String) at ./loading.jl:539
[5] eval(::Module, ::Any) at ./boot.jl:235
[6] require(::Symbol) at ./loading.jl:453
while loading /home/kv/.julia/v0.6/OpenCV/src/OpenCV.jl, in expression starting on line 70
julia>
Maybe related to your OpenCV
installation again or something that you changed in your local repo but which is missing from the mat_templates
branch? I really do not know what could be going on since I can't reproduce it locally. . .
I have looked at the commit history and I have not made any changes to the lib loading routine in OpenCV.jl
since the last commit d2851b46b6226a547706aaf256507a1a17cccd1f
in the master
branch.
I guess I have messed up again ;). I will look into this.
As mentioned here, we can come up with a more efficient method to convert the images using c++ pointers method. I found that the wrappers are already implemented here, for manipulation using pointers in c++. But they seem to place the same
int value
over all the pixels. Maybe we need to come up with another wrapper to efficiently convert images ? I would like to work on this wrapper.