#242: Operator+(object, builtin) does not work as expected since g++ 4.5
-------------------------+------------------------
Reporter: lazzara | Owner: Olena Team
Type: defect | Status: closed
Priority: critical | Milestone: Olena 2.1
Component: Milena | Version: 1.0
Resolution: worksforme | Keywords:
-------------------------+------------------------
Changes (by levill_r):
* status: new => closed
* resolution: => worksforme
* milestone: => Olena 2.1
Comment:
`g++-4.5` is no longer available on Debian GNU/Linux stable (7.2) and I
cannot reproduce the problem with `g++-mp-4.5` from the !MacPorts on OS X
10.8 (Mountain Lion); the problem may have been fixed since it has been
reported; closing.
--
Ticket URL: <https://trac.lrde.epita.fr/olena/ticket/242#comment:1>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient image processing platform
#295: Morpher applying a function with memoization
--------------------------------------------------+------------------------
Reporter: levill_r | Owner: Olena Team
Type: task | Status: new
Priority: trivial | Milestone:
Component: Milena | Version: 2.0
Keywords: laziness non-strictness call-by-need |
--------------------------------------------------+------------------------
In addition to our morpher(s) performing point-site-wise function
application, we should experiment with a version providing a memoization
mechanism, and evaluate the potential gains on various use cases
(especially when working on a subset of an image).
We should start by implementing a read-only morpher and see whether a
read/write version is feasible or even relevant.
--
Ticket URL: <https://trac.lrde.epita.fr/olena/ticket/295>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient image processing platform
#294: Streamline and improve morphers
-------------------------+------------------------
Reporter: levill_r | Owner: Olena Team
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Milena | Version: 2.0
Keywords: |
-------------------------+------------------------
Foreword: this should of course be done both in the code *and* in the
documentation (e.g. in a section "Guidelines for future morphers").
Some reflexions:
* We must carefully set a policy regarding embedded images (are they
copied into morphers or manipulated through references/pointers?)
* Hence a potential directive in the documentation regarding the
implementation/manipulation of all images in Milena: should they all be
manipulated by copies, but behaved as smart pointers, sharing data?
* Does this mean we should never manipulate images through references
(within morphers, but also elsewhere) and let the smart (tracked) pointer
do the job of allocating/freeing memory?
* Also, what about the constness of embeded images? All morphers are
currently not equal before this aspect.
--
Ticket URL: <https://trac.lrde.epita.fr/olena/ticket/294>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient image processing platform
#293: Experiment with Vagrant
--------------------------------------------+------------------------
Reporter: levill_r | Owner: Olena Team
Type: proposal | Status: new
Priority: trivial | Milestone:
Component: Olena | Version: 2.0
Keywords: virtual machine virtualization |
--------------------------------------------+------------------------
Vagrant makes VM instantiation, use and disposal easy:
http://www.vagrantup.com/
We should definitely have a look at it, and possibly consider using it in
Olena's test suite(s) (e.g. as part of the continuous integration
service).
--
Ticket URL: <https://trac.lrde.epita.fr/olena/ticket/293>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient image processing platform
#232: Update contributors' list on Olena's Web site
-----------------------+------------------------
Reporter: levill_r | Owner: Olena Team
Type: task | Status: new
Priority: critical | Milestone: Olena 2.1
Component: Web | Version: 1.0
Resolution: | Keywords:
-----------------------+------------------------
Changes (by levill_r):
* cc: demoulins (added)
* milestone: Olena 2.2 => Olena 2.1
Old description:
> This page :
>
> https://www.lrde.epita.fr/cgi-bin/twiki/view/Olena/Contributors
>
> should be updated with the latest version (e.g., from branch `next`) of
> this file :
>
> source:AUTHORS
>
> Better: write a script to automate the conversion, so as to simplify the
> process of updating this page down to a copy-and-paste operation.
New description:
This page :
http://www.lrde.epita.fr/cgi-bin/twiki/view/Olena/Contributors
should be updated with the latest version of this file (i.e., from
`master`):
source:AUTHORS
Better: write a script to automate the conversion, so as to simplify the
process of updating this page down to a copy-and-paste operation.
We should look at other LRDE projects to see how they handle this issue.
Handling this together with the migration to the new (!MediaWiki-based)
Web server (see #292) would be a good idea.
--
Comment:
* s/https/http/
* s/next/master/
* Mention other projects.
* CC Clément.
--
Ticket URL: <https://trac.lrde.epita.fr/olena/ticket/232#comment:3>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient image processing platform
#289: Integrate features developed during the work on the wavelet-based text/non-
text classification
----------------------+------------------------
Reporter: levill_r | Owner: Olena Team
Type: task | Status: new
Priority: minor | Milestone: Olena 2.2
Component: Milena | Version: 2.0
Keywords: |
----------------------+------------------------
Raphaël Boissel sent the following list of features to me (Roland) :
* Conversion of an image with Cartesian coordinates to an image with
polar ones.
* Addition of a class dedicated to processing signals, providing:
* basic math operations;
* a wavelet transform;
* a Fast Fourier Transform (FFT);
* signal import/export routines for popular formats (Matlab, structSVM,
…).
This ticket is a reminder. We should probably split it to track the
progress made on each feature.
Who wants to work on this? Has any preliminary integration work been
started on the Milena source tree?
--
Ticket URL: <https://trac.lrde.epita.fr/olena/ticket/289>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient image processing platform
#199: Stop using recursive Makefiles in tests
-----------------------+------------------------
Reporter: levill_r | Owner: Olena Team
Type: task | Status: new
Priority: minor | Milestone: Olena 2.1
Component: Milena | Version: 2.0
Resolution: | Keywords:
-----------------------+------------------------
Comment (by levill_r):
Comment from Akim (http://lists.lrde.epita.fr/pipermail/olena-
bugs/2013-September/000164.html) on this topic:
{{{
Automake 1.14 makes things much easier than before, you should
really have a look at %D% and %C%. You might also want to have
a look at these patches in V2. As you can see, you can make this
incremental: first use %C% and %D%, then remove a Makefile. I
felt safer this way.
commit 949d412f9934b448737d489bce9885b2a3c935c6
Author: Akim Demaille <akim(a)lrde.epita.fr>
Date: Mon Sep 23 17:02:13 2013 +0200
build: remove last recursive Makefile
* tests/Makefile.am: Rename as...
* tests/local.mk: this.
Adjust dependencies.
commit 224ec2280d051bea141c90f9dad1db734f668784
Author: Akim Demaille <akim(a)lrde.epita.fr>
Date: Mon Sep 23 14:48:10 2013 +0200
build: use Automake 1.14's %C% and %D%
* configure.ac: Require 1.14.
* tests/demo/local.mk, tests/rat/local.mk, tests/tafkit/local.mk,
* tests/unit/local.mk: Avoid naming the current directory, using
%D% and %C%.
}}}
--
Ticket URL: <https://trac.lrde.org/olena/ticket/199#comment:4>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient image processing platform