I have been trying to make this on FreeBSD 8.2 and 9.1 with no luck. I
have tried both IM and GM and I have yet to figure out why I am getting
this error when it is correct type. Gxx is 4.2.1
Just wondering if anyone else has run into this problem before...If so is
their a patch to get around this?
Hi everybody,
I've recently made some changes regarding Milena's header mln/version.hh
[1]. This file is produced from milena/mln/version.hh.in, and was
originally generated in the *build tree* by configure. With the recent
changes in `master', this file is now generated in the *source tree*, by
make.
If your Olena build tree is different from your Olena source tree (i.e.
if you've invoked configure from a directory other than the one where it
resides), you'll have to manually remove the old generated
milena/mln/version.hh file from your build tree. E.g. if you previously
configured Olena in the following manner:
cd ~/src/olena
mkdir _build
cd _build
../configure
you'll need to remove mln/version.hh from the build dir this way:
rm ~/src/olena/_build/milena/mln/version.hh
If you configured the source tree to be the build tree (i.e. by running
`./configure' from the source tree), you don't need to do anything special.
Notes:
[1] See
http://git.lrde.epita.fr/?p=olena.git;a=commit;h=5158238ced7f9256ca51e68dc4….
--
Roland Levillain
EPITA Research and Development Laboratory (LRDE)
14-16, rue Voltaire - FR-94276 Le Kremlin-Bicêtre Cedex - France
Phone: +33 1 53 14 59 45 - Fax: +33 1 53 14 59 22 - www.lrde.epita.fr
Hi,
I am Paula, image processing student, and I am working with Olena. I have a
doubt: I want to create a RGB image and I want to give each pixel a
certain color.
I do the following:
image2d <value::rgb8> imagePrueb(rows,cols);
fill(imagePrueb, literal::white);
This way, the problem is the whole image has the same color... How can I
set the desired color to each pixel?
Thank you.
Best regards.
Paula.
Salut tout le monde,
j'ai voulu tester ce week-end la démo en ligne de dématérialisation (
http://olena.lrde.epita.fr/demos/document_segmentation.php) de document
pour récupérer mon image en pdf mais ça a finit en erreur :
"PDF output : /tmp/web_app147489430652208889c261d3.66045018.pdf"Ooops!
Something went wrong. Please contact us in order to fix that!
olena(a)lrde.epita.fr. Thank you!
Ca fait la même chose si je lance la démo avec les images proposées sur le
site.
Je n'ai pas de problème par contre avec la démo sur les documents
historiques.
Bon courage et à bientôt. :)
A+
Shalom Olena team,
At Ben-Gurion University in Israel we evaluating binarization
approaches for ancient Torah Scrolls right now.
You SauvoulaMS approach :"Efficient Multiscale Sauvola's
Binarization". seems to be very accurate even despite of inhomogeneous
background!
So we would be really gad to use it and see how it performs ahead of
others Binarization algorithms.
I already installed Olena 2.0 under Ubuntu.
Could you help me out with a little code SauvolaMs example ?
For example how could I apply a SauvolaMs on a single page .tiff
format and/or on many pages in .tiff stacks ?
best regards
Albert Berman, MSc
Ben-Gurion University of the Negev
Phone: +972-8-6477320 (office)
Phone: +972-8-6477311 (lab)
Fax: +972-8-6477627
P.O.B. 653
Beer Sheva 84105
Israel
Helo epita,
I trying to get running the olena on ubuntu in order to test SauvolaMs
myself,
but by compiling the"3.2 First generic algorithm" from the tutorial
I am always getting the same error :
milena_one.cc:14:25: fatal error: tests/data.hh: No such file or directory
what I am doing wrong ?
best regards
Albert Berman
Hi everybody,
Starting today, we are changing our branching and committing policy.
The branch `master', which used to be used to tag the latest release
(currently, Olena 2.0) will be used as a stable integration branch.
This role was previously played by the branch `next'. This change is
motivated by the fairly recent introduction of TeamCity
(http://teamcity.lrde.epita.fr) as continuous integration solution at
LRDE and by the fact that `master' should provide more up-to-date (yet
stable) contents.
As this was the case for `next', no patches should be push directly into
`master'. (Actually, the Git central repository will forbid any change
to `master', except for members of the maintainer team, which is
currently reduced to me & myself.) New changes shall be sent through
another branch (either an existing one or a new one), preferably on top
of `master' to make future integration easier.
Any integration effort into `master' shall start with a pull request,
either informally, by contacting a (the) maintainer, or better, by
creating a pull-request ticket on Trac (use
https://trac.lrde.epita.fr/olena/newticket and set the type to
`pull-request'). Patches will be reviewed and integrated trough a merge
or a rebase action onto `master'. Things will get a little clearer and
simpler when GitLab is officially deployed and used at LRDE.
The fate of the branch `next' has not been completely decided yet. It
will probably be used as an antechamber for `master', for short fix
patches only. Other contributions should be recorded into branches with
relevant names, so as to make branch management easier.
I'll try to put more useful information regarding Git usage in `HACKING'
(http://git.lrde.epita.fr/?p=olena.git;a=blob;f=HACKING) ASAP.
--
Roland Levillain
EPITA Research and Development Laboratory (LRDE)
14-16, rue Voltaire - FR-94276 Le Kremlin-Bicêtre Cedex - France
Phone: +33 1 53 14 59 45 - Fax: +33 1 53 14 59 22 - www.lrde.epita.fr