Im all for a big glaring "OpenCV >= 2.0 required if you want to use opencv extensions" On Wed, Nov 4, 2009 at 1:57 PM, SirVer <sirver@gmx.de> wrote:
A __version__ function in the future is little help to distinguish between OCV 1 and OCV 2. BUT the current case is not bearable; for example the test suite can not be run when you have OpenCV 1 installed, because OpenCV errors always result in a coredump because of their braindumped I-do-my-own-Exceptions-In-C-Which-Are-Uncatchable Stuff. That is, as soon as the opencv tests run, the whole python process is KILLED by opencv throwing an exception because I expects an array of 1x5 instead of 1x4. (Note that the same is true if we do stuff vice-versa: making version 1 a dependency and the user has 2 installed).
The only REAL solutions I see for this mess is to either a) decide which version to build against at build time using IFDEFs. Which is ugly and not easy to pull off and makes OpenCV a hard build time dependency. On plus we would have to ship binary versions linked against OCV1 and OCV2. Ugly code, Ugly distribution, hard to implement. b) Determine at run time if the user has OpenCV 1 installed and ABORT then in a pythonic fashion. I know of no portable way to pull this off; one could only check for relative positions of functions in the binaries or so. Nice code, nice distribution, very hard to implement. c) Rip the parts that we need from the OpenCV source code (if licensing allows that) and build our own subset of the functionality into scikit.image. No dependency on the OpenCV anymore, no cranky void* pointer passing around, no strange exceptions that are uncatchable. Heaven on earth. Downside: a lot of work. Upside: We really would provide the image processing capabilities.
What do others think? Personally, I always wanted to have a better designed Image Library with a smaller, but well tested subset of ImageProcessing Algos that are really useful.
Goodluck with getting that done though. I doubt we will see a new OpenCV release for awhile... and people will be using 2.0 for a long time to come... No wonder; hacking OpenCV code is as ugly as coding can get.
Cheers, Holger
2009/11/4 Stéfan van der Walt <ste...@sun.ac.za>:
2009/11/4 Chris Colbert <sccolb...@gmail.com>:
OpenCV has a ___version___ header file.
We can only access that if it exposed as a function, though, so maybe they can help us out.
Cheers Stéfan
2009/11/4 Chris Colbert <sccolbert@gmail.com>:
Im all for a big glaring "OpenCV >= 2.0 required if you want to use opencv extensions"
This does look like the most painless way forward. Chris, would you mind putting up a big notice in the OpenCV docs? Thanks Stéfan
2009/11/4 Stéfan van der Walt <stefan@sun.ac.za>
2009/11/4 Chris Colbert <sccolbert@gmail.com>:
Im all for a big glaring "OpenCV >= 2.0 required if you want to use opencv extensions"
This does look like the most painless way forward. Chris, would you mind putting up a big notice in the OpenCV docs?
A notice is good but does not really solve the issue right? If you need to have 1.x on your computer for whatever reason, you get crashes anyway when running the tests. I like Holger's option b:
b) Determine at run time if the user has OpenCV 1 installed and ABORT then in a pythonic fashion. I know of no portable way to pull this off; one could only check for relative positions of functions in the binaries or so. Nice code, nice distribution, very hard to implement.
Not sure if this works, but could you use multiprocess to import opencv and run a function known to fail in 1.x in a separate process. Then if it works, write something to a file, and read that file. If you avoid any shared objects this may work. Alternatively, locate the opencv header somehow, and parse it. Cheers, Ralf
I would rather make a global module variable in the OpenCV files that a user can set to the path of their OpenCV 2.0 libs if they have more than one version installed. I see three situations: 1) a user wants to use scikits and doesnt have opencv - so they follow the build instructions and build 2.0 - no problems 2) a user wants to use scikits and has opencv 1.x - so they remove 1.x and build 2.0 - no problems 3) a user wants to use scikits and has opencv 1.x but CANT get rid of it because they are using it for other things. - THIS user is a power user and shouldnt mind setting a variable in a file to point to their 2.0 libs. Cheers! Chris On Wed, Nov 4, 2009 at 4:28 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
2009/11/4 Stéfan van der Walt <stefan@sun.ac.za>
2009/11/4 Chris Colbert <sccolbert@gmail.com>:
Im all for a big glaring "OpenCV >= 2.0 required if you want to use opencv extensions"
This does look like the most painless way forward. Chris, would you mind putting up a big notice in the OpenCV docs?
A notice is good but does not really solve the issue right? If you need to have 1.x on your computer for whatever reason, you get crashes anyway when running the tests.
I like Holger's option b:
b) Determine at run time if the user has OpenCV 1 installed and ABORT then in a pythonic fashion. I know of no portable way to pull this off; one could only check for relative positions of functions in the binaries or so. Nice code, nice distribution, very hard to implement.
Not sure if this works, but could you use multiprocess to import opencv and run a function known to fail in 1.x in a separate process. Then if it works, write something to a file, and read that file. If you avoid any shared objects this may work.
Alternatively, locate the opencv header somehow, and parse it.
Cheers, Ralf
There are so many different ways that people can configure their system. I think it fair for us to say, "if you want to do X you must have Y, otherwise you have to do Z" On Wed, Nov 4, 2009 at 5:38 PM, Chris Colbert <sccolbert@gmail.com> wrote:
I would rather make a global module variable in the OpenCV files that a user can set to the path of their OpenCV 2.0 libs if they have more than one version installed.
I see three situations: 1) a user wants to use scikits and doesnt have opencv - so they follow the build instructions and build 2.0 - no problems 2) a user wants to use scikits and has opencv 1.x - so they remove 1.x and build 2.0 - no problems 3) a user wants to use scikits and has opencv 1.x but CANT get rid of it because they are using it for other things. - THIS user is a power user and shouldnt mind setting a variable in a file to point to their 2.0 libs.
Cheers!
Chris
On Wed, Nov 4, 2009 at 4:28 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
2009/11/4 Stéfan van der Walt <stefan@sun.ac.za>
2009/11/4 Chris Colbert <sccolbert@gmail.com>:
Im all for a big glaring "OpenCV >= 2.0 required if you want to use opencv extensions"
This does look like the most painless way forward. Chris, would you mind putting up a big notice in the OpenCV docs?
A notice is good but does not really solve the issue right? If you need to have 1.x on your computer for whatever reason, you get crashes anyway when running the tests.
I like Holger's option b:
b) Determine at run time if the user has OpenCV 1 installed and ABORT then in a pythonic fashion. I know of no portable way to pull this off; one could only check for relative positions of functions in the binaries or so. Nice code, nice distribution, very hard to implement.
Not sure if this works, but could you use multiprocess to import opencv and run a function known to fail in 1.x in a separate process. Then if it works, write something to a file, and read that file. If you avoid any shared objects this may work.
Alternatively, locate the opencv header somehow, and parse it.
Cheers, Ralf
On Wed, Nov 4, 2009 at 5:39 PM, Chris Colbert <sccolbert@gmail.com> wrote:
There are so many different ways that people can configure their system. I think it fair for us to say, "if you want to do X you must have Y, otherwise you have to do Z"
Sure.
On Wed, Nov 4, 2009 at 5:38 PM, Chris Colbert <sccolbert@gmail.com> wrote:
I would rather make a global module variable in the OpenCV files that a user can set to the path of their OpenCV 2.0 libs if they have more than one version installed.
I see three situations: 1) a user wants to use scikits and doesnt have opencv - so they follow the build instructions and build 2.0 - no problems
I assume you mean "if he needs this opencv functionality". Please keep it optional.
2) a user wants to use scikits and has opencv 1.x - so they remove 1.x and build 2.0 - no problems 3) a user wants to use scikits and has opencv 1.x but CANT get rid of it because they are using it for other things. - THIS user is a power user and shouldnt mind setting a variable in a file to point to their 2.0 libs.
Easy to do, and would only affect a few users. If this file is under version control that may be very annoying for developing though. If you set the variable you can never fast-forward anymore. Cheers, Ralf
2009/11/4 Ralf Gommers <ralf.gommers@googlemail.com>:
3) a user wants to use scikits and has opencv 1.x but CANT get rid of it because they are using it for other things. - THIS user is a power user and shouldnt mind setting a variable in a file to point to their 2.0 libs.
Easy to do, and would only affect a few users. If this file is under version control that may be very annoying for developing though. If you set the variable you can never fast-forward anymore.
The user already has a variable like this in LD_LIBRARY_PATH, so I don't think we need to do anything other than document the way we find the library. Stéfan
so let's say this: 1) If you want to use the opencv facilities, you need OpenCV >= 2.0 2) Because people may want more than one OpenCV version installed at a time, we will first make an attempt to find the variable OPENCV2 in LD_LIBRARY_PATH. - If the variable exists, but the dll loads fail, we abort the library import with a message to stdout. - if the variable does not exist, we assume that OpenCV 2.0 is the only version installed on the system and continue with the loading mechanism in place. If the user did not heed our instructions and instead is using OpenCV < 2.0, and something crashes. Shame on them. - if no library is found, fail gracefully as usual. How does that sound? Cheers! Chris 2009/11/4 Stéfan van der Walt <stefan@sun.ac.za>:
2009/11/4 Ralf Gommers <ralf.gommers@googlemail.com>:
3) a user wants to use scikits and has opencv 1.x but CANT get rid of it because they are using it for other things. - THIS user is a power user and shouldnt mind setting a variable in a file to point to their 2.0 libs.
Easy to do, and would only affect a few users. If this file is under version control that may be very annoying for developing though. If you set the variable you can never fast-forward anymore.
The user already has a variable like this in LD_LIBRARY_PATH, so I don't think we need to do anything other than document the way we find the library.
Stéfan
2009/11/5 Chris Colbert <sccolbert@gmail.com>:
2) Because people may want more than one OpenCV version installed at a time, we will first make an attempt to find the variable OPENCV2 in LD_LIBRARY_PATH. - If the variable exists, but the dll loads fail, we abort the library import with a message to stdout. - if the variable does not exist, we assume that OpenCV 2.0 is the only version installed on the system and continue with the loading mechanism in place. If the user did not heed our instructions and instead is using OpenCV < 2.0, and something crashes. Shame on them.
We can even simplify that: a) scikits.image.opencv requires opencv v2 b) scikits.image.opencv always loads the first opencv library that can be found on LD_LIBRARY_PATH Regards Stéfan
which is already the current behavior :) 2009/11/5 Stéfan van der Walt <stefan@sun.ac.za>:
2009/11/5 Chris Colbert <sccolbert@gmail.com>:
2) Because people may want more than one OpenCV version installed at a time, we will first make an attempt to find the variable OPENCV2 in LD_LIBRARY_PATH. - If the variable exists, but the dll loads fail, we abort the library import with a message to stdout. - if the variable does not exist, we assume that OpenCV 2.0 is the only version installed on the system and continue with the loading mechanism in place. If the user did not heed our instructions and instead is using OpenCV < 2.0, and something crashes. Shame on them.
We can even simplify that:
a) scikits.image.opencv requires opencv v2 b) scikits.image.opencv always loads the first opencv library that can be found on LD_LIBRARY_PATH
Regards Stéfan
participants (3)
-
Chris Colbert -
Ralf Gommers -
Stéfan van der Walt