OpenCV vs JavaCV can I please get some detailed information on why to pick one over the other?

[Dried Meat]

Hello all,


I have been trying to search Google for which is better, and I am getting very little information, as well as conflicting answers.


Since this is the JavaCV group I want to know why you choose JavaCV over OpenCV with Java?

There really is no Java documentation on OpenCV, and most of it seems to need the user to convert to Java from C++.

JavaCV seems to be newer than OpenCV in general, but I'm not too sure how updated it is and how much it can do.

I am mostly looking to do Mobile/Tablet programming, with possibly using Desktop for my application.


I want to be able to use Object Recognition as well as DescriptionMatching.

I would like to use JavaFX with this project as well as possibly using Java8.

Please let me know if there are pros and cons to using both JavaCV or OpenCV.

It seems to me if you're using Java it would make sense to use JavaCV, but I want to make sure this is something that will be supported for a long time, and something that is a good choice overall.


All the best, thank you for your time,


~Jason

[Samuel Audet]

Hello,

OpenCV itself dates back to 1999 at Intel, but it never had a good Java
interface, as is the case of almost any C/C++ library... So anyway,
after a few frustrating years writing (mostly debugging) code in C++ and
a couple of failed attempts with SWIG, I succeeded in making my own
bridge in 2009. At first, I started by using JNA, and it worked OK,
unlike SWIG, but it was slow and didn't support C++. I figured I could
do something better, and the result was JavaCPP.

The current Java interface of OpenCV is more recent than JavaCV, but
it's limited to OpenCV. It's never going to support other things like
FFmpeg or Tesseract. My plan is to get JavaCPP's Parser to generate
automatically the equivalent of the files currently in the
com.googlecode.javacv.cpp package, but for the JavaCPP Presets module:
http://code.google.com/p/javacpp/wiki/Presets
And have JavaCV use those classes, instead. That should happen within
the next few months, I hope. I'm still pretty much alone working on
this, but I'm pretty committed to that, and should rename the package
name to a domain name I own at that point to make it more
"professional", and probably also move to GitHub :)

On the other hand, if all the things you are interested in are all
available in the Java interface of OpenCV, that's probably a good
choice, because it's part of the OpenCV project...

Samuel

[Dried Meat]

Thanks for the reply Samual!

First thank you for this project, I'm surprised you haven't had others helping out.

I am not too sure what I will fully need, but what does the Java portion of OpenCV have that JavaCV does not?

It also seems that you're saying if I do NOT need things like FFmpeg or the others it's best to use OpenCV?

Like you mentioned I REALLY am NOT looking to convert C++ code to Java.

The examples are in Scala for JavaCV though, but that is closer to Java(and can be used with Java) than C++.

As for the Parser it seems your main purpose is to convert the c++ into Java so we can use All of the features in OpenCV?


I guess I will ask here that I really am looking to use image and video recognition, as well as image stitching with both video and images.  I am looking to recreate scenes and be able to identify the objects within that scene.

Hopefully JavaCV has what I'm looking for, and I would appreciate if you could let me know if it is possible to do what I am looking for..

It does seem better to use an officially supported language, but I figure if this is supported for awhile it would be a great choice, I definitely do not want to have to convert code later on if this project somehow dies.

Thank you, all the best, and I hope you(if you want) get some help in making this library the best!

~Jay

[Samuel Audet]

On 12/24/2013 03:57 AM, Dried Meat wrote:
> Thanks for the reply Samual!

Thanks to you!

> First thank you for this project, I'm surprised you haven't had others
> helping out.

Well, I think it has a lot to do with the lack of "marketing".. It'll
probably get better once I get a domain name and switch to GitHub. And
there's also the fact that there has been so many attempts at coming up
with something useful in the past that most people have simply given up,
or gone back to do raw JNI, and won't be convinced until shown something
that actually works.

> I am not too sure what I will fully need, but what does the Java portion
> of OpenCV have that JavaCV does not?

The APIs are obviously not the same, many little differences there, but
I think the only big thing is a hack to access the camera from native
code on most Android devices. But that doesn't work on all devices,
while Android already provides a standard Java API to capture from
cameras, so I'm not sure that it's actually useful.

> It also seems that you're saying if I do NOT need things like FFmpeg or
> the others it's best to use OpenCV?

Probably, but opencv-java doesn't support callbacks or direct NIO
buffers, for example. Java is a second class citizen in OpenCV. Or
actually third class, Python is second class, and we can't even do
everything with Python, because it's just so slow. Only C++ is fully
supported. Its Java API might never support GPU calls, for example,
because it can't be used on Android anyway, or direct NIO buffers,
because they are slow on Android anyway. "And who programs in Java
outside of Android?" is what most people erroneously believe in the
computer vision community, in my experience, unfortunately.

> Like you mentioned I REALLY am NOT looking to convert C++ code to Java.
>
> The examples are in Scala for JavaCV though, but that is closer to
> Java(and can be used with Java) than C++.
>
> As for the Parser it seems your main purpose is to convert the c++ into
> Java so we can use All of the features in OpenCV?

No, it's purpose is to convert C++ header files (almost)
/automatically/. It's already possible to do it /manually/, and that's
what is in JavaCV at the moment.

> I guess I will ask here that I really am looking to use image and video
> recognition, as well as image stitching with both video and images. I
> am looking to recreate scenes and be able to identify the objects within
> that scene.
>
> Hopefully JavaCV has what I'm looking for, and I would appreciate if you
> could let me know if it is possible to do what I am looking for..

Sure, it sounds like it's what you are looking for :) You are probably
going to need to train it to recognize your objects though:
http://docs.opencv.org/doc/user_guide/ug_traincascade.html

> It does seem better to use an officially supported language, but I
> figure if this is supported for awhile it would be a great choice, I
> definitely do not want to have to convert code later on if this project
> somehow dies.

Well the API might change a bit with the "Presets"... What I really want
for now is to show that it's technically feasible (no reason to believe
that it isn't at this point), and then after that it should be smooth
sailing

> Thank you, all the best, and I hope you(if you want) get some help in
> making this library the best!

Of course! What do you have in mind?

Samuel

[Dried Meat]

> Well, I think it has a lot to do with the lack of "marketing".. It'll 
> probably get better once I get a domain name and switch to GitHub. And 
> there's also the fact that there has been so many attempts at coming up 
> with something useful in the past that most people have simply given up, 
> or gone back to do raw JNI, and won't be convinced until shown something 
> that actually works. 

I hope the transition to Github will be smooth, good luck!

> The APIs are obviously not the same, many little differences there, but 
> I think the only big thing is a hack to access the camera from native 
> code on most Android devices. But that doesn't work on all devices, 
> while Android already provides a standard Java API to capture from 
> cameras, so I'm not sure that it's actually useful. 

So will there be a problem developing in JavaCV with the camera?  That is very important to me with image/video recognition.  What exactly doesn't work on "all devices?" and devices meaning mobile, or all(including laptops and desktops)?  Can JavaCV use the native Android API?

> Probably, but opencv-java doesn't support callbacks or direct NIO 
> buffers, for example. Java is a second class citizen in OpenCV. Or 
> actually third class, Python is second class, and we can't even do 
> everything with Python, because it's just so slow. Only C++ is fully 
> supported. Its Java API might never support GPU calls, for example, 
> because it can't be used on Android anyway, or direct NIO buffers, 
> because they are slow on Android anyway. "And who programs in Java 
> outside of Android?" is what most people erroneously believe in the 
> computer vision community, in my experience, unfortunately. 

Yeah I don't want anything slow, and seeing as they don't care about Java(I really hate ignorance when people ask why we use Java as a language).  People think Java is some POS, but it's an amazing language, and even if it has "boilerplate" if people are going to complain about that, and not look at the power of Java then there is a problem.  I rather write tons of boilerplate that works then to use a language like ruby, develop a large app, and then get rocked because Ruby is awful with bigger projects.

Use of the GPU is important IMO, especially on these mobile devices.

> Sure, it sounds like it's what you are looking for :) You are probably 
> going to need to train it to recognize your objects though: 
> http://docs.opencv.org/doc/user_guide/ug_traincascade.html 

Sounds great, as long as it can do exactly what I need, and can utilize it all + be fast I think I'll stick with JavaCV.  I just want to make sure that it can indeed use the Camera, and can do exactly what I need.  I will definitely need to train my objects, most of them will be boxes or other symmetrical shapes :).

> Well the API might change a bit with the "Presets"... What I really want 
> for now is to show that it's technically feasible (no reason to believe 
> that it isn't at this point), and then after that it should be smooth 
> sailing 

I also believe that since you are still working on it, that JavaCV will be the choice for the future, because once it can do EVERYTHING OpenCV can do, and more, I don't think anyone would go to OpenCV for Java, especially with what you said that it's a "3rd class citizen" and that we cannot access the GPU and such.

> Of course! What do you have in mind? 

I have nothing to input right now, but once I get a feel/flavor for JavaCV I will make suggestions if I need them.  Like I said as long as I can do video/image recognition with stitching the results together, as well as creating 3D Objects(Photogrammetry) with I'm assuming Features2d and obj3d(or other libraries) that would be great(I might not need this since the pictures/model data would be on a server in my db), but if I have to create them I would like to possibly be able to do that as well/

I'm also looking to work with JavaFX8 to create 3d representations of these objects. I know 8 isn't out yet, but I would like to utilize it.

Do you also think it would be possible to get JavaCV working on iOS?  I know they have released Glass and Prism for open source ports, and RoboVM has an iOS port, so I'm curious if it's possible to get it working on iOS with fx?

I wonder how OpenCV works with Obj-C on iOS.


Thanks again for all of your help!!!

~Jason

[Samuel Audet]

On 12/25/2013 03:57 AM, Dried Meat wrote:
> So will there be a problem developing in JavaCV with the camera? That
> is very important to me with image/video recognition. What exactly
> doesn't work on "all devices?" and devices meaning mobile, or
> all(including laptops and desktops)? Can JavaCV use the native Android API?

The only official API is Java, so hacking something in native code
usually works apparently, but not always. Of course Java works fine:
http://code.google.com/p/javacv/source/browse/samples/FacePreview.java
http://code.google.com/p/javacv/source/browse/samples/RecordActivity.java
The main reason not to use it is to avoid using Java on Android. Desktop
is another thing, that's native, and OpenCV usually works.

> Yeah I don't want anything slow, and seeing as they don't care about
> Java(I really hate ignorance when people ask why we use Java as a
> language). People think Java is some POS, but it's an amazing language,
> and even if it has "boilerplate" if people are going to complain about
> that, and not look at the power of Java then there is a problem. I
> rather write tons of boilerplate that works then to use a language like
> ruby, develop a large app, and then get rocked because Ruby is awful
> with bigger projects.

And alternative languages on the Java platform are happening, like Scala
and Groovy. Even the latter is pretty fast these days apparently!

> I also believe that since you are still working on it, that JavaCV will
> be the choice for the future, because once it can do EVERYTHING OpenCV
> can do, and more, I don't think anyone would go to OpenCV for Java,
> especially with what you said that it's a "3rd class citizen" and that
> we cannot access the GPU and such.

Ok, I'll do my best! Thanks

> I have nothing to input right now, but once I get a feel/flavor for
> JavaCV I will make suggestions if I need them. Like I said as long as I
> can do video/image recognition with stitching the results together, as
> well as creating 3D Objects(Photogrammetry) with I'm assuming Features2d
> and obj3d(or other libraries) that would be great(I might not need this
> since the pictures/model data would be on a server in my db), but if I
> have to create them I would like to possibly be able to do that as well/
>
> I'm also looking to work with JavaFX8 to create 3d representations of
> these objects. I know 8 isn't out yet, but I would like to utilize it.

Sounds great! Would be nice to have sample code to show for that ;)

> Do you also think it would be possible to get JavaCV working on iOS? I
> know they have released Glass and Prism for open source ports, and
> RoboVM has an iOS port, so I'm curious if it's possible to get it
> working on iOS with fx?

I'm sure it can work. We probably need to make a few tweaks like I had
to do for Android's version of JNI, but it should work fine.

That's another thing that we need: builds. I sometimes get build
requests, mainly for CentOS/RHEL, Android x86, Raspberry Pi, and now
RoboVM, that's a first, but I hope it becomes more popular alright.
Would be nice to have builds ;)

> I wonder how OpenCV works with Obj-C on iOS.

It doesn't, C++ works fine.

> Thanks again for all of your help!!!

Sure! Happy Holidays!

Samuel

[Dried Meat]

> The only official API is Java, so hacking something in native code 
> usually works apparently, but not always. Of course Java works fine: 
> http://code.google.com/p/javacv/source/browse/samples/FacePreview.java 
> http://code.google.com/p/javacv/source/browse/samples/RecordActivity.java 
> The main reason not to use it is to avoid using Java on Android. Desktop 
> is another thing, that's native, and OpenCV usually works. 

I guess I keep getting confused by these replies, so since it's officially Java we should have no problems with JavaCV, but with OpenCV we would have an issue, or what I'm confused :P.


So you're saying that people would have a hard time using C++ on Android, to not use Java(since you said people dislike Java in the CV community)?

As long as everything works for Java, and Android I'm happy, I also will need to use Desktop devices at first, I figured that is stage 1, and then stage 2 is mobile.


Thanks again!

[Samuel Audet]

On 12/26/2013 01:45 AM, Dried Meat wrote:
> I guess I keep getting confused by these replies, so since it's
> officially Java we should have no problems with JavaCV, but with OpenCV
> we would have an issue, or what I'm confused :P.

Using a Java API from C++ is kind of hard and not really efficient,
that's pretty much it. We might gain some efficiency by skipping Java
entirely as well, but...

> So you're saying that people would have a hard time using C++ on
> Android, to not use Java(since you said people dislike Java in the CV
> community)?

Yes, seems like that to me. Whether that's actually true or not...

> As long as everything works for Java, and Android I'm happy, I also will
> need to use Desktop devices at first, I figured that is stage 1, and
> then stage 2 is mobile.

Great :) And if that works out, let me know if you have some cool sample
code you'd like to contribute, thanks!

Samuel

[Dried Meat]

> Using a Java API from C++ is kind of hard and not really efficient, 
> that's pretty much it. We might gain some efficiency by skipping Java 
> entirely as well, but... 

Sorry, still confused, "Using a Java API from C++" meaning OpenCV's version?

Are we losing "efficiency" with JavaCV compared to OpenCV Java?? or C++?

thanks :P

> Great :) And if that works out, let me know if you have some cool sample 
> code you'd like to contribute, thanks! 

I like to contribute when I can, I really like the warmth of the open source and programming communities in general(As long as people are respectful I'm happy, there have been a few people on various communities who were rude, and 1 community in particular had a lot of "know it alls."  I did a lot of testing with OpenJDK and Java8 in Q1-2 of this year, and it was fun, but took a lot of time and effort to report and fix bugs.

I wanted to help OpenCV originally by giving them more Java tutorial code, but I think I'm going to go this route now.

I'll see what kinds of tutorials are needed and try to help from there, I honestly would love to make this the best choice for Java programmers, I'm new to CV in general, but the libraries are really amazing, and I really want to learn all I can about them!

I also have been messing around with leap motion, as well as JMonkeyEngine so I can see how it works with JavaCV as well!

[Samuel Audet]

On 12/27/2013 05:50 AM, Dried Meat wrote:
> > Using a Java API from C++ is kind of hard and not really efficient,
> > that's pretty much it. We might gain some efficiency by skipping Java
> > entirely as well, but...
>
> Sorry, still confused, "Using a Java API from C++" meaning OpenCV's version?

No, I mean using Android's Java API from C++, literally. We can use C++
APIs from Java, but vice versa is also possible. That has nothing to do
with OpenCV or Android.

OpenCV offers a native C++ camera capture API that works on most Android
devices, but it's not official. Android offers a Java camera capture
API, and that's supported by Google and cellphone manufacturers. That is
all.

> Are we losing "efficiency" with JavaCV compared to OpenCV Java?? or C++?

Compared to raw C++, always a little bit, but a bit more in the case of
Android: Dalvik isn't a model of efficiency... That's why a lot of games
for Android are mostly written in C++. At least, Google seems to be
working on the problem. They are upgrading Dalvik to ART (Android
Runtime), so that should get better eventually.

> I like to contribute when I can, I really like the warmth of the open
> source and programming communities in general(As long as people are
> respectful I'm happy, there have been a few people on various
> communities who were rude, and 1 community in particular had a lot of
> "know it alls." I did a lot of testing with OpenJDK and Java8 in Q1-2
> of this year, and it was fun, but took a lot of time and effort to
> report and fix bugs.
>
> I wanted to help OpenCV originally by giving them more Java tutorial
> code, but I think I'm going to go this route now.

Great, thanks :) Actually, we should be talking to Eric Christiansen
about this as well. (I added him to the Cc: list just in case he does
not get all the messages on this list.) He's the guy who took the
original Android Java module, and modified it to target Java on the
desktop as well. He agrees more could be done, but he's currently
satisfied with the state of the Java wrappers in OpenCV. As for me, I'm
continuing my work on the JavaCPP Presets, and we'll see how well that
goes, not just for OpenCV, but for C++ in general.

> I'll see what kinds of tutorials are needed and try to help from there,
> I honestly would love to make this the best choice for Java programmers,
> I'm new to CV in general, but the libraries are really amazing, and I
> really want to learn all I can about them!

I did get some requests to translate the Scala examples back to Java. I
suppose that would be something that's not too hard to do, and would be
a good step forward in understanding the API a bit more for yourself...
Well, anyway, I'll leave it up to you to decide what you'd like to do :)

> I also have been messing around with leap motion, as well as
> JMonkeyEngine so I can see how it works with JavaCV as well!

Great! Let us know what you find

Samuel

[Dried Meat]

> No, I mean using Android's Java API from C++, literally. We can use C++ 
> APIs from Java, but vice versa is also possible. That has nothing to do 
> with OpenCV or Android. 

> OpenCV offers a native C++ camera capture API that works on most Android 
> devices, but it's not official. Android offers a Java camera capture 
> API, and that's supported by Google and cellphone manufacturers. That is 
> all. 

> Compared to raw C++, always a little bit, but a bit more in the case of 
> Android: Dalvik isn't a model of efficiency... That's why a lot of games 
> for Android are mostly written in C++. At least, Google seems to be 
> working on the problem. They are upgrading Dalvik to ART (Android 
> Runtime), so that should get better eventually. 

I didn't think originally c++ was used on android, I thought native it was Java.  Do we need to call c++ libraries at all, or does the java suffice?

So it's good that the Java cam is supported by google and such then.

As for efficiency, It's interesting c++ is used a lot more in respect to gaming, I would assume there are a  lot of java games/java applications wouldn't be slow.

> Great, thanks :) Actually, we should be talking to Eric Christiansen 
> about this as well. (I added him to the Cc: list just in case he does 
> not get all the messages on this list.) He's the guy who took the 
> original Android Java module, and modified it to target Java on the 
> desktop as well. He agrees more could be done, but he's currently 
> satisfied with the state of the Java wrappers in OpenCV. As for me, I'm 
> continuing my work on the JavaCPP Presets, and we'll see how well that 
> goes, not just for OpenCV, but for C++ in general. 

You said before that desktop is well equipped for most's needs and the needs I mentioned before, right?

Hope it works out well for you!

> I did get some requests to translate the Scala examples back to Java. I 
> suppose that would be something that's not too hard to do, and would be 
> a good step forward in understanding the API a bit more for yourself... 
> Well, anyway, I'll leave it up to you to decide what you'd like to do :) 

Yeah that could be done, It would be a good learning experience to start using both.

> > I also have been messing around with leap motion, as well as 
> > JMonkeyEngine so I can see how it works with JavaCV as well! 

> Great! Let us know what you find 

Yeah I want to use both on Android, so I would like to see how it works out.

[Samuel Audet]

Hi,

On 12/28/2013 01:33 PM, Dried Meat wrote:
> I didn't think originally c++ was used on android, I thought native it
> was Java. Do we need to call c++ libraries at all, or does the java
> suffice?

Android is based on Linux, so we need to use C at least, and C++ is
usually needed for various convenient libraries under the hood to
support Java, so it was always there. They added support for JNI after a
while as well:
http://developer.android.com/training/articles/perf-jni.html

> So it's good that the Java cam is supported by google and such then.
>
> As for efficiency, It's interesting c++ is used a lot more in respect to
> gaming, I would assume there are a lot of java games/java applications
> wouldn't be slow.

Well, I was referring to graphic intensive games and such. But
obviously, if we segregate the parts that require heavy processing into
reusable libraries, such as with libgdx or JavaCV, the rest can be done
efficiently in Java, even on Android or iOS with RoboVM:
First RoboVM/libgdx app in iOS App Store
http://www.badlogicgames.com/wordpress/?p=3193

> > Great, thanks :) Actually, we should be talking to Eric Christiansen
> > about this as well. (I added him to the Cc: list just in case he does
> > not get all the messages on this list.) He's the guy who took the
> > original Android Java module, and modified it to target Java on the
> > desktop as well. He agrees more could be done, but he's currently
> > satisfied with the state of the Java wrappers in OpenCV. As for me, I'm
> > continuing my work on the JavaCPP Presets, and we'll see how well that
> > goes, not just for OpenCV, but for C++ in general.
>
> You said before that desktop is well equipped for most's needs and the
> needs I mentioned before, right?

That's what it seems to me, yes. Also, JavaCPP makes it easy to create
your own native C++ functions and call them from Java, in case you need
more performance, especially on Android.

> Hope it works out well for you!

Thanks!

> > I did get some requests to translate the Scala examples back to Java. I
> > suppose that would be something that's not too hard to do, and would be
> > a good step forward in understanding the API a bit more for yourself...
> > Well, anyway, I'll leave it up to you to decide what you'd like to do :)
>
> Yeah that could be done, It would be a good learning experience to start
> using both.

Ok, good! We should be talking to Jarek about that (added to Cc:), about
where the samples should end up. Anyway, I'm sure it'll take you a while
to get started, so feel free to ask technical questions here until we
get this cleared up, thanks!

Samuel

[Dried Meat]

> Android is based on Linux, so we need to use C at least, and C++ is 
> usually needed for various convenient libraries under the hood to 
> support Java, so it was always there. They added support for JNI after a 
> while as well: 
> http://developer.android.com/training/articles/perf-jni.html 

Gotcha, okay, I need to learn about mobile dev as well, so this is good knowledge.
I haven't worked with JNI at all, is that something I should definitely learn as part of this quest of mine?

> Well, I was referring to graphic intensive games and such. But 
> obviously, if we segregate the parts that require heavy processing into 
> reusable libraries, such as with libgdx or JavaCV, the rest can be done 
> efficiently in Java, even on Android or iOS with RoboVM: 
>        First RoboVM/libgdx app in iOS App Store 
>        http://www.badlogicgames.com/wordpress/?p=3193 

Well I'm glad RoboVM is getting somewhere, I remember when it first came out, and it was in Alpha and it didn't run all that well on iOS.  Recently I thought I checked and it was still "Alpha;" However now I see it's updated site and it looks GREAT!

It says it only runs on Mac OS, then says Ubuntu?    Boo :P.

> That's what it seems to me, yes. Also, JavaCPP makes it easy to create 
> your own native C++ functions and call them from Java, in case you need 
> more performance, especially on Android. 

Hmm I'll look into that.  I have very limited knowledge in C++, though I doubt it would be hard to learn anything if needed.  Hopefully my tasks aren't too demanding.

> Ok, good! We should be talking to Jarek about that (added to Cc:), about 
> where the samples should end up. Anyway, I'm sure it'll take you a while 
> to get started, so feel free to ask technical questions here until we 
> get this cleared up, thanks! 

I'm still finishing up a project using JMonkeyEngine, so I'm not exactly sure when I'm starting this.  I'm starting to read up, but no work as of yet.  Hopefully it doesn't take that long to produce goodies.

[Dried Meat]

Sorry for double post, but I have 2 questions.

1.  Do we have to use Maven?  I'm sure I should learn how to use it anyways since repositories seem to be big, and I could have probably used it in the past.

2   What is the max OpenCV version we should use?  According to https://code.google.com/p/javacv/ it says 2.4.8 is the version we should download, but I'm not sure if the page is old, or if that's the version we SHOULD be downloading.


As for this:

> And please make sure your Java and OpenCV have the same bitness: 32-bit and 64-bit modules do not mix under any circumstances. Further, although not always required, some functionality of JavaCV also relies on:

What happens?  Does your comp explode? haha :).


as for the addons should we download them all, or would you recommend the basic JavaCV install?

Also I see you add JOGL downloads, but does JavaCV support LWJGL?  I believe JMonkey was built ontop of LWJGL, but does work with JOGL, so I would assume LWJGL would also work since it's OpenGL, but who knows...  I hope it does because since I'm using Jmonkey now and possibly for my CV Project I would not like have to switch things around to JOGL, but we shall do some testies :).

[Samuel Audet]

On 01/06/2014 08:44 AM, Dried Meat wrote:
> Gotcha, okay, I need to learn about mobile dev as well, so this is good knowledge.
> I haven't worked with JNI at all, is that something I should definitely learn as part of this quest of mine?

Not necessarily. With something like JavaCPP we don't usually need to
touch JNI, even to access native code.

> Well I'm glad RoboVM is getting somewhere, I remember when it first came
> out, and it was in Alpha and it didn't run all that well on iOS.
> Recently I thought I checked and it was still "Alpha;" However now I
> see it's updated site and it looks GREAT!

Yes, I want a nice site too, eventually :)

> It says it only runs on Mac OS, then says Ubuntu? Boo :P.

That's because of Apple. It's a licensing issue, not a technical one.
But we don't need a physical Mac. It's possible to boot Mac OS X inside
a virtual machine, but Apple does not seem too happy about that either:
http://en.wikipedia.org/wiki/OSx86#Legal_issues_and_Apple_objections
We can also rent one on the cloud though:
http://www.macincloud.com/

> Hmm I'll look into that. I have very limited knowledge in C++, though I
> doubt it would be hard to learn anything if needed. Hopefully my tasks
> aren't too demanding.

We don't need C++. Just C is usually more than enough for that kind of
task, and the syntax has about the same level of complexity as the Java
language, so you should be fine. It looks like this:
https://code.google.com/p/javacpp/#Optimizing_Code_Performance

> 1. Do we have to use Maven? I'm sure I should learn how to use it anyways since repositories seem to be big, and I could have probably used it in the past.

No, just put all the JAR files in the CLASSPATH. I guess I'll
reformulate the README.txt file to make that clearer...

> 2 What is the max OpenCV version we should use? According to https://code.google.com/p/javacv/ it says 2.4.8 is the version we should download, but I'm not sure if the page is old, or if that's the version we SHOULD be downloading.

We have to use the exact version of OpenCV specified: Different versions
of OpenCV are almost never compatible among themselves.

>> And please make sure your Java and OpenCV have the same bitness: 32-bit and 64-bit modules do not mix under any circumstances. Further, although not always required, some functionality of JavaCV also relies on:
>
> What happens? Does your comp explode? haha :).

No, Windows just throws cryptic error messages like "%1 is not a valid
Win32 application". I wonder what the Windows guys were thinking about
when they thought that would be the best error message to return in that
case.

> as for the addons should we download them all, or would you recommend the basic JavaCV install?

Depends on your needs. I'm guessing you only want OpenCV at this point, no?

> Also I see you add JOGL downloads, but does JavaCV support LWJGL? I believe JMonkey was built ontop of LWJGL, but does work with JOGL, so I would assume LWJGL would also work since it's OpenGL, but who knows... I hope it does because since I'm using Jmonkey now and possibly for my CV Project I would not like have to switch things around to JOGL, but we shall do some testies :).

No need to worry about that if the only thing you're interested in is
OpenCV at that point!

Samuel

[Dried Meat]

> Not necessarily. With something like JavaCPP we don't usually need to 
> touch JNI, even to access native code. 

cool cool, but do you think it's something good to learn in general?  I'm a bit interested.  I love to learn as much as I can as well, but right now I'm only learning as I need it for the most part.

> Yes, I want a nice site too, eventually :) 

We'll have to get you one up!  Do you do web dev as well?  I'm sure a group of users could come together and build a site.

> That's because of Apple. It's a licensing issue, not a technical one. 
> But we don't need a physical Mac. It's possible to boot Mac OS X inside 
> a virtual machine, but Apple does not seem too happy about that either: 
>         http://en.wikipedia.org/wiki/OSx86#Legal_issues_and_Apple_objections 
> We can also rent one on the cloud though: 
 >        http://www.macincloud.com/ 

that is why I hate Apple, they are such greedy pos.  People complained about Microsoft, they got sued for a monopoly, but what about Apple?

Is there an IDE that runs a virtual environment like Android/iOS?

> We don't need C++. Just C is usually more than enough for that kind of 
> task, and the syntax has about the same level of complexity as the Java 
> language, so you should be fine. It looks like this: 
> https://code.google.com/p/javacpp/#Optimizing_Code_Performance 

So we would only need C for optimizing then, I guess I'll worry about then when I need to optimize.

> No, just put all the JAR files in the CLASSPATH. I guess I'll 
> reformulate the README.txt file to make that clearer... 

Sounds good ty.

> We have to use the exact version of OpenCV specified: Different versions 
> of OpenCV are almost never compatible among themselves. 

That's really stupid, no backwards compatibility?  Also that is the most recent version, for some reason I thought the were on 2.7 or 3.0, weird.

> No, Windows just throws cryptic error messages like "%1 is not a valid 
> Win32 application". I wonder what the Windows guys were thinking about 
> when they thought that would be the best error message to return in that 
> case. 

Lol :).  Nice error!

> as for the addons should we download them all, or would you recommend the basic JavaCV install? 

Depends on your needs. I'm guessing you only want OpenCV at this point, no? 

> Also I see you add JOGL downloads, but does JavaCV support LWJGL?  I believe JMonkey was built ontop of LWJGL, but does work with JOGL, so I would assume LWJGL would also work since it's OpenGL, but who knows...  I hope it does because since I'm using Jmonkey now and possibly for my CV Project I would not like have to switch things around to JOGL, but we shall do some testies :). 

No need to worry about that if the only thing you're interested in is 
OpenCV at that point! 

Well, I'm interested in OpenCV, as well as OpenGL.  I already use OpenGL With JMonkey as mentioned above.  After I'm done with my current project I want to use it with my image rec application. I originally was going to work 3D into JavaCV with Java8, but since I already did most of it in JMonkey that I figure it would be best to keep it....

I also could port the code to JOGL or w/e, but JMonkey can run with JOGL as well.  Who knows what's going to happen :P.

As for the other things... TBH a lot of it seems to be unsupported or "old."  I'm not sure which of the additional libraries would be good for what I need...

JReality is really awesome!

[Samuel Audet]

On 01/08/2014 03:41 AM, Dried Meat wrote:
> > Not necessarily. With something like JavaCPP we don't usually need to
> > touch JNI, even to access native code.
>
> cool cool, but do you think it's something good to learn in general?
> I'm a bit interested. I love to learn as much as I can as well, but
> right now I'm only learning as I need it for the most part.

IMO? Not until you've exhausted all other less painful alternatives, no

> > Yes, I want a nice site too, eventually :)
>
> We'll have to get you one up! Do you do web dev as well? I'm sure a
> group of users could come together and build a site.

Sure, but I'd need to do some PR and stuff, and I'm not especially good
at that as you can see, so I'm postponing that until after I'm mostly
satisfied with the state of JavaCPP's Parser.

> that is why I hate Apple, they are such greedy pos. People complained
> about Microsoft, they got sued for a monopoly, but what about Apple?
>
> Is there an IDE that runs a virtual environment like Android/iOS?

On Mac OS X? Sure. But the way I see this going is that eventually
JavaFX is going to run on both Android and RoboVM, a preview of that here:
JavaFX8 multimedia project on iPad, Android, Windows and Mac!
http://blog.software4java.com/
And if that works out alright, I guess most shops are going to develop
with Android, and will only need the minimum amount of Mac hardware to
test it there.

> > We have to use the exact version of OpenCV specified: Different versions
> > of OpenCV are almost never compatible among themselves.
>
> That's really stupid, no backwards compatibility? Also that is the most
> recent version, for some reason I thought the were on 2.7 or 3.0, weird.

Sometimes the API is backward compatible, but they change the filenames
of the Windows DLLs on each version anyway, so the Windows binaries are
never compatible across versions because of that. I used to think FFmpeg
was badly managed, but you haven't seen nothing until you take look
inside OpenCV 2.x :)

> Well, I'm interested in OpenCV, as well as OpenGL. I already use OpenGL
> With JMonkey as mentioned above. After I'm done with my current project
> I want to use it with my image rec application. I originally was going
> to work 3D into JavaCV with Java8, but since I already did most of it in
> JMonkey that I figure it would be best to keep it....
>
> I also could port the code to JOGL or w/e, but JMonkey can run with JOGL
> as well. Who knows what's going to happen :P.

You're probably not going to use anything that needs OpenGL from JavaCV,
so I wouldn't worry about that. Just go with LWJGL if that works for you.

> As for the other things... TBH a lot of it seems to be unsupported or
> "old." I'm not sure which of the additional libraries would be good for
> what I need...

Well, read up on their features, it's the only way!

> JReality is really awesome!

Cool :) I hope you'll be able to make something nice with all that

Samuel

[Dried Meat]

> > cool cool, but do you think it's something good to learn in general? 
> >   I'm a bit interested.  I love to learn as much as I can as well, but 
> > right now I'm only learning as I need it for the most part. 

> IMO? Not until you've exhausted all other less painful alternatives, no 

Okay, will do.  Future project :p.
 

>  > Yes, I want a nice site too, eventually :) 
> 
> > We'll have to get you one up!  Do you do web dev as well?  I'm sure a 
>>  group of users could come together and build a site. 

> Sure, but I'd need to do some PR and stuff, and I'm not especially good 
> at that as you can see, so I'm postponing that until after I'm mostly 
> satisfied with the state of JavaCPP's Parser. 

For sure, good luck with that.
 

> that is why I hate Apple, they are such greedy pos.  People complained 
> about Microsoft, they got sued for a monopoly, but what about Apple? 
> 
> Is there an IDE that runs a virtual environment like Android/iOS? 

> On Mac OS X? Sure. But the way I see this going is that eventually 
> JavaFX is going to run on both Android and RoboVM, a preview of that here: 
>         JavaFX8 multimedia project on iPad, Android, Windows and Mac! 
 >        http://blog.software4java.com/ 
> And if that works out alright, I guess most shops are going to develop 
> with Android, and will only need the minimum amount of Mac hardware to 
> test it there. 

I meant on Windows so I could use Robovm without having to buy a mac or w/e.  I can't wait to starting using FX with it, Jmonkey has bee doing ios support for about a year now I wonder what's going on with them.
 

> > Well, I'm interested in OpenCV, as well as OpenGL.  I already use OpenGL 
> > With JMonkey as mentioned above.  After I'm done with my current project 
> > I want to use it with my image rec application. I originally was going 
> > to work 3D into JavaCV with Java8, but since I already did most of it in 
> > JMonkey that I figure it would be best to keep it.... 
> > 
> > I also could port the code to JOGL or w/e, but JMonkey can run with JOGL 
> > as well.  Who knows what's going to happen :P. 

> You're probably not going to use anything that needs OpenGL from JavaCV, 
> so I wouldn't worry about that. Just go with LWJGL if that works for you. 

Why wouldn't I?  I do want to integrate it with my other projects, but maybe you're saying that i don't need the OpenGL within my cv project, itself or...?
 

[Samuel Audet]

On 01/15/2014 02:56 AM, Dried Meat wrote:
> I meant on Windows so I could use Robovm without having to buy a mac or
> w/e. I can't wait to starting using FX with it, Jmonkey has bee doing
> ios support for about a year now I wonder what's going on with them.

Well, like I said, it's possible to hack Mac OS X to run on VirtualBox
or VMware, but I wouldn't recommend it because Apple clearly dislikes
people doing that... You might want to keep an eye on Codename One, though:
http://www.codenameone.com/
They offer a free cloud service to build iOS apps with Java, but it's
currently based on XMLVM, and that doesn't support JNI. Given that
RoboVM seems more promising in that sense, they might eventually switch:
http://www.codenameone.com/3/post/2013/09/java-one-detailed-trip-report.html

> Why wouldn't I? I do want to integrate it with my other projects, but
> maybe you're saying that i don't need the OpenGL within my cv project,
> itself or...?

Almost all the functionality in JavaCV proper was added to support these
two applications:
http://www.ok.ctrl.titech.ac.jp/~saudet/research/procamcalib/
http://www.ok.ctrl.titech.ac.jp/~saudet/research/procamtracker/

If that doesn't look like something you need for your own applications,
then you don't need to worry about it.

Samuel

[Dried Meat]

> Almost all the functionality in JavaCV proper was added to support these 
> two applications: 
> http://www.ok.ctrl.titech.ac.jp/~saudet/research/procamcalib/ 
> http://www.ok.ctrl.titech.ac.jp/~saudet/research/procamtracker/ 

> If that doesn't look like something you need for your own applications, 
> then you don't need to worry about it. 

I'm confused what you mean by this, you're saying that if i don't need this then there's no point in using JavaCV...?

[Samuel Audet]

On 02/01/2014 01:05 PM, Dried Meat wrote:
> I'm confused what you mean by this, you're saying that if i don't need
> this then there's no point in using JavaCV...?

No, you were asking about JOGL... Whether there is no point in using
JavaCV or not, well that depends on your application.

Samuel

[Dried Meat]

i was just confused when you were mentioning the AR stuff, which is awesome btw, I want to get involved in that as well.

I'm assuming both ProCamCalib and Tracker are needed for this completely, I loved your demo http://www.ok.ctrl.titech.ac.jp/~saudet/procamtracker/

is the ARToolKitPlus the only library with AR? I would assume OpenCV might have something as well...

Thanks for all the goodies!

- show quoted text -