haskell-opencv-contrib

[tolysz]

I am assuming that this repo assumes only "core" opencv libraries It would be nice to have more repos for other ones: really it should be per optional modules the opencv can have. eg: haskell-opencv-contrib-bgsegm, haskell-opencv-cuda, haskell-opencv-contrib-xphoto.

Or should we have flags inside this module to support those additional (optional) modules?

[roelvandijk]

I would prefer flags for easy development and maintenance.

[tolysz]

Flags are fine, they will introduce some CPP. Ideally, modules will be selected in .cabal. We can refactor some stuff to have only 1 CPP fer flag per module maximum.

module OpenCV (
    , module X
    ) 
import OpenCV.Calib3d as X

[tolysz]

I had a stab at this, I try to put CPP only where there was no choice. PR https://github.com/LumiGuide/haskell-opencv/pull/60

[tolysz]

I would like to add a couple modules more :) @roelvandijk could you review the above PR (and suggest where to place various bits of the extra modules). ;) The plan is to add something before HaskellX...

[roelvandijk]

I discussed this with @basvandijk a bit. I now think the optional modules are a bad idea. Instead I propose an additional package: opencv-extra or opencv-contrib. This new package depends on opencv and extends it with all the contrib modules. If there any non-technical issues with extra modules, such as patent difficulties, we can always add some cabal flags to the new package in order to optionally disable such modules. The new package can happily live in the current haskell-opencv repository.

I will write the initial code and expose it in a branch. I'll also look at integrating your bgsegm code in the new package. Then we can start adding more stuff.

[tolysz]

Maybe it would be better to have: LumiGuide/haskell-opencv-extra allowing for permissions to be different? Stack should be fine building them together anyway. It would allow moving the main package with breaking changes forward without too much hustle. .travis will have a different requirements anyway

[roelvandijk]

I would like to have them in the same repo for now because some code will be shared. Some header files and the example extraction template-haskell code that currently lives in the doc directory.

I also foresee refactoring that will change both packages at the same time. Having them in the same repo gives nice atomic commits.

[tolysz]

From my perspective, anything that works will be fine, once we see more patterns/structure we can always refactor.

[roelvandijk]

I now have a working opencv-extra package in the feat-opencv-extra branch. It includes your bgsegm commit.

It still needs stack support which is what I want to try and add next.

Can you work with this? You could try and port your xphoto code to this new package. After we fix all problems you encounter we can merge the new package into master.

[tolysz]

I can look into stack, and I can add XPhoto. The problem will be with the haddock as the extract images require to have all methods in scope. It is almost as if we need extract-images-extra.

For Stack it should be enough to add it in the main (opencv stack.yaml) (and we can drop all fixed packages if we use resolver lts-7.2)

[roelvandijk]

It would be very helpful if you would do those things :-)

For the image extractor: I will have to separate concerns. There are 3 parts. 1 - The ExampleExtractor module 2 - Some global constants like colors and example images 3 - The opencv-doc-images executable, which combines the above parts and also adds some special documentation images.

I want to re-use the first 2 parts in opencv-extra. I also think the ExampleExtractor module can be made to not depend on OpenCV. It only needs the library in order to render the images. The (name of the) render function can simply be passed as an argument.

[tolysz]

done. so if you could fix haddock we are home :)

[tolysz]

Hacked the opencv-doc-images, haddock should work

[tolysz]

For travis we could always add a trampoline :) (eg. https://github.com/tolysz/reflex-starter/blob/lts-7.1/init.sh ) Once on master, we have a script which will exit 0 after installing all libraries and env. Then one manual restart, and we have a nice cache ;)

[roelvandijk]

Everything is now in master. Thanks!

I will refactor some things in the future, mainly the documentation part. And a cleaner separation between opencv and opencv-extra. But that should not cause problems with the bindings code like bgsegm and xphoto.

[tolysz]

How about the trampoline, It would only require restarts only if the cache is gone? Let me set up Travis on my account, as it is easier to show than explain.

[tolysz]

Fixed: https://travis-ci.org/tolysz/haskell-opencv/builds/164629078 (needs to be restarted manually 1st time, but then it should build quick)

[tolysz]

Should we add this module to the documentation?

[tolysz]

I have been working on tracking module. The basic (single) tracking works. I will make PR once is somehow more in shape ( https://github.com/tolysz/haskell-opencv/tree/feat-opencv-extra-tracker ). It uses Rect2d which is not compatible with Rect2i... thus will need to add some haskell wrappers rather than crude casts.

[roelvandijk]

We support 3 template instantiations of cv::Rect_<typename>. Do you need anything that is not offered by the OpenCV.Core.Types.Rect module?

[tolysz]

I need some conversion functions between them i.e. Rect2i <-> Rect2d <-> Rect2f

[roelvandijk]

Something like this? (untested)

fmapRect :: forall a b. (IsRect Rect a, IsRect Rect b) => (a -> b) -> Rect a -> Rect b
fmapRect f r = toRect hrB
  where
    hrA :: HRect a
    hrA = fromRect r

    hrB :: HRect b
    hrB = fmap f hrA

or shorter

fmapRect :: forall a b. (IsRect Rect a, IsRect Rect b) => (a -> b) -> Rect a -> Rect b
fmapRect f = toRect . fmap f . fromRect

Even better would be to have

instance Functor Rect where ...

[roelvandijk]

I'm closing this issue. opencv-extra exists and all the rectangle stuff is also available.