#107: Case of fastest images in data::transform
---------------------+------------------------------------------------------
Reporter: duhamel | Owner: Olena Team
Type: task | Status: new
Priority: major | Milestone: Olena 2.1
Component: Milena | Version: 1.0
Keywords: |
---------------------+------------------------------------------------------
Comment(by lazzara):
An implementation of data::transform is now provided for fastest image.
I am wondering though if it is more a fast version than a fastest one.
Can someone confirm that ?
--
Ticket URL: <https://trac.lrde.org/olena/ticket/107#comment:2>
Olena <http://olena.lrde.epita.fr>
Olena, a software platform dedicated to image processing.
#103: mln/arith/revert.hh : move implementation in mln/fun/v2v/revert.hh
-------------------------+--------------------------------------------------
Reporter: duhamel | Owner: Olena Team
Type: enhancement | Status: new
Priority: minor | Milestone: Olena 2.1
Component: Milena | Version: 1.0
Keywords: |
-------------------------+--------------------------------------------------
Comment(by lazzara):
Yes, I think it is relevant since using a function allows to perform the
image transformation with data::transform.
data::transform is already specialized for many properties.
Relying on fun::v2v::revert would then avoid writing another dispatch
which would probably not be exhaustive.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/103#comment:2>
Olena <http://olena.lrde.epita.fr>
Olena, a software platform dedicated to image processing.
#259: Generate a PDF versions of RST files
---------------------------+------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: task | Status: new
Priority: minor | Milestone: Olena 2.1
Component: Olena | Version: 2.0
Keywords: documentation |
---------------------------+------------------------------------------------
Files such as `README` or `HACKING` are written in reStructuredText (RST):
it should be easy to generate a PDF version from these plain-text files.
We should hook the action of building these PDFs to a Make target (such as
`doc`).
Note that in some branches (e.g. `autoconfiscate-subprojects`), there are
several instances of `README` (one in the top-level directory and one per
sub-project).
--
Ticket URL: <https://trac.lrde.org/olena/ticket/259>
Olena <http://olena.lrde.epita.fr>
Olena, a software platform dedicated to image processing.
#94: Create Olena Debian package(s) for amd64
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: task | Status: new
Priority: minor | Milestone: Olena 2.1
Component: Olena | Version: 2.0
Keywords: |
----------------------+-----------------------------------------------------
Comment(by lazzara):
Packages are now available in the download page: http://www.lrde.epita.fr
/cgi-bin/twiki/view/Olena/Download
We support Debian Wheezy amd64 and Ubuntu Precise (12.x) i386/amd64 with
the following packages :
- olena, meta-package
- olena-dev: milena and scribo headers + documentation
- olena-bin: Various tools based on scribo, including scribo-cli and
scribo-viewer.
Debian and Ubuntu packages can share the same configuration files for
generating Debian source packages (required for making final packages).
Ubuntu packages are generated from the launchpad.net platform:
https://launchpad.net/~olena/+archive/ppa.
Debian packages have been generated by hand.
TODO :
- Write documentation on how to generate packages.
- Make the process fully automatic ?
- Cross-compile packages for Debian i386
--
Ticket URL: <https://trac.lrde.org/olena/ticket/94#comment:5>
Olena <http://olena.lrde.epita.fr>
Olena, a software platform dedicated to image processing.
#208: Fix dependencies of the HTML documentation generation?
----------------------+-----------------------------------------------------
Reporter: levill_r | Owner: Olena Team
Type: defect | Status: new
Priority: minor | Milestone: Olena 1.1
Component: Milena | Version: 1.0
Keywords: doc |
----------------------+-----------------------------------------------------
The generation of the HTML documentation requires a file named `html.sty`,
which is not provided by HeVeA, but by latex2html. Is that right? I
thought we only had a dependency on the former, not the latter.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/208>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#219: Add \internal in the documentation of internal code
---------------------+------------------------------------------------------
Reporter: lazzara | Owner: Olena Team
Type: defect | Status: new
Priority: major | Milestone: Olena 1.1
Component: Milena | Version: 1.0
Keywords: |
---------------------+------------------------------------------------------
Currently, in order to not expose the internal code in the user
documentation, everything in the internal and trait namespaces is ignored
during the doc generation.
The main issue is that inherited members are not shown in the
documentation of the classes exposed to the user.
The only way to ask Doxygen to show inherited members and not to show
internal documentation is to add \internal in the documentation of
internal code.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/219>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient C++ image processing library.
#45: Check if a point belong to an image during forward.
-----------------------+----------------------------------------------------
Reporter: anonymous | Owner: Olena Team
Type: task | Status: new
Priority: minor | Milestone: Olena 2.1
Component: Milena | Version: 1.0
Keywords: has |
-----------------------+----------------------------------------------------
Comment(by lazzara):
I don't think so. Canvas are just ways of browsing the image and so
getting information from a functor. 'They just do their job' according to
the functor output.
The functor is supposed to be smart enough and know where it is located
while computing something.
If it is not the case, browsing canvas suppose that the iteration is
performed over all the sites included in the domain. Browsing is
straightforward : no iteration over a window or a neighborhood. So there
is no reason that a site does not belong to the image.
I suggest that we close this ticket as 'wontfix'.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/45#comment:1>
Olena <http://olena.lrde.epita.fr>
Olena, a software platform dedicated to image processing.