#288: Pull Request: exp/magick-improvements
--------------------------+-----------------------
Reporter: levill_r | Owner: levill_r
Type: pull-request | Status: new
Priority: major | Milestone: Olena 2.1
Component: Milena | Version: 2.0
Keywords: i/o |
--------------------------+-----------------------
PR sent by Guillaume Lazzara.
This branch adds support for 16-bit value types with !GraphicsMagick as
well as a new routine to read meta-data from an image file before loading
the (whole) actual data.
Be careful, these changes have not been tested on OS X (with
!GraphicsMagick or !ImageMagick from the !MacPorts).
--
Ticket URL: <https://trac.lrde.epita.fr/olena/ticket/288>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient image processing platform
#296: Adress recent GCC warnings regarding unused local typedefs
----------------------+------------------------
Reporter: levill_r | Owner: Olena Team
Type: defect | Status: new
Priority: major | Milestone: Olena 2.1
Component: Milena | Version: 2.0
Keywords: |
----------------------+------------------------
GCC's `-Wunused-local-typedefs` option (which seems to be hooked to
`-Wall` since version 4.8) triggers a lot of messages regarding Milena's
code (and probably Scribo's as well).
Some cases are easy to solve (typedefs actually used nowhere), while
others are more delicate to handle, as `typedef` is used as a concept
checking mechanism within Milena's concept classes. See how other projects
doing concept checking with typedefs handled this issue. I guess we may
be able to leverage GCC attributes to solve this.
--
Ticket URL: <https://trac.lrde.epita.fr/olena/ticket/296>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient image processing platform
#297: Stop using mln_VAR in installed libraries
-------------------------+------------------------
Reporter: levill_r | Owner: Olena Team
Type: defect | Status: new
Priority: major | Milestone: Olena 2.1
Component: Milena | Version: 2.0
Keywords: portability |
-------------------------+------------------------
The `mln_VAR` macro defined in source:milena/mln/core/var.hh relies on the
non-standard `typeof` keyword. It should only be used in client code, not
in library code. Ensure installed headers do not make use of this
feature.
--
Ticket URL: <https://trac.lrde.epita.fr/olena/ticket/297>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient image processing platform
#290: Check Olena with Cppcheck
----------------------+------------------------
Reporter: levill_r | Owner: Olena Team
Type: task | Status: new
Priority: major | Milestone: Olena 2.1
Component: Olena | Version: 2.0
Keywords: |
----------------------+------------------------
Check the whole code base with Cppcheck (http://cppcheck.sourceforge.net/)
and use the report(s) produced by this tool to make changes to the code if
they are deemed relevant.
--
Ticket URL: <https://trac.lrde.org/olena/ticket/290>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient image processing platform
#292: Migrate Olena's Web site to the new (MediaWiki-based) Web server
----------------------+------------------------
Reporter: levill_r | Owner: Olena Team
Type: task | Status: new
Priority: major | Milestone: Olena 2.1
Component: Web | Version: 2.0
Keywords: |
----------------------+------------------------
This is a big task, that we should of course discuss and break into
smaller tasks.
Let's target the Olena 2.1 release.
--
Ticket URL: <https://trac.lrde.epita.fr/olena/ticket/292>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient image processing platform
#286: Fix the Olena port on MacPorts
----------------------+------------------------
Reporter: levill_r | Owner: Olena Team
Type: defect | Status: new
Priority: critical | Milestone: Olena 2.1
Component: Milena | Version: 2.0
Keywords: |
----------------------+------------------------
The `olena` port from the !MacPorts does not compile anymore. I believe
that the required fixes have been applied in the current `master` branch.
There used to be a dependency issue with Tesseract too, but I guess this
has been fixed as well with recent updates to the `tesseract` port.
We should check that the port builds fine with a tarball rolled from
`master` before shopping [milestone:"Olena 2.1" Olena 2.1] (hopefully very
soon). What is the best approach to check !MacPorts candidates locally?
(Maybe setting up a local repository?) I (Roland) would like to get some
advice about this. Thanks in advance!
--
Ticket URL: <https://trac.lrde.epita.fr/olena/ticket/286>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient image processing platform
#298: Make Swilena work with SWIG 2.0.9+
----------------------+------------------------
Reporter: levill_r | Owner: Olena Team
Type: defect | Status: new
Priority: critical | Milestone: Olena 2.1
Component: Swilena | Version: 2.0
Keywords: |
----------------------+------------------------
The Swilena test suite fails when the wrappers are generated with a
version of SWIG equal to or greater than 2.0.9. This problem has been
observed with SWIG 2.0.9, 2.0.11 and 3.0.0. It works fine with SWIG 2.0.7
though.
Try to compare the generated wrappers (C++ and Python files) in order to
highlight the issue.
--
Ticket URL: <https://trac.lrde.epita.fr/olena/ticket/298>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient image processing platform
#291: Improve the MinGW build on TeamCity
------------------------------------+------------------------
Reporter: levill_r | Owner: Olena Team
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Olena | Version: 2.0
Keywords: continuous integration |
------------------------------------+------------------------
The current MinGW build running on the !TeamCity server
(http://teamcity.lrde.epita.fr/viewType.html?buildTypeId=bt11) is limited
to the compilation of a subset of Olena: many features are disabled as we
cannot run programs built by `i686-w64-mingw32-c++` or even link them with
most of our external dependencies (such as !GraphicsMagick).
Likewise, the rebuilding of the documentation is circumvented by
`touch`-ing timestamps and output files generated by locally-built Milena
programs.
Could we use Wine (http://www.winehq.org/) to run binaries built by
`i686-w64-mingw32-c++`? Or run them on a Windows host (either an actual
machine or a VM)?
Here is a summary of things that could be improved:
* Do not run programs in `milena/doc/` — or have them run in the host
environment (Windows). This is currently circumvented by not passing
`--enable-apps` to `configure`.
* Do not use the `random()` function (used at least in `milena/apps/mesh-
segm-skel/`) as MinGW does not provide it.
* Enable support for !GraphicsMagick (or !ImageMagick) and Qt.
* Enable the `make check` and `make distcheck` TeamCity build steps.
* More generally, be able to pass `--enable-all` to `configure`.
--
Ticket URL: <https://trac.lrde.epita.fr/olena/ticket/291>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient image processing platform
#285: Overhaul the Olena configurations on TeamCity
-------------------------+----------------------
Reporter: levill_r | Owner: levill_r
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Milena | Version: 2.0
Keywords: |
-------------------------+----------------------
* Factor common parts using a template (see HAVM's, MonoBURG's and
Nolimips' configurations).
* Use uniform names/identifiers (likewise).
* We may want to remove some unused or redundant configurations.
* The set of compatible agents for all configurations is relatively
small; try to install missing requirements and/or make the necessary
changes in the project to work around/get rid of these dependencies (e.g.
Swig ≠ 2.0.9).
--
Ticket URL: <https://trac.lrde.epita.fr/olena/ticket/285>
Olena <http://olena.lrde.epita.fr>
Olena, a generic and efficient image processing platform
