#74: Review the trunk/milena/mln/morpho directory -----------------------+---------------------------------------------------- Reporter: levill_r | Owner: levill_r Type: task | Status: assigned Priority: critical | Milestone: Olena 1.0 Component: Milena | Version: 1.0 Resolution: | Keywords: -----------------------+---------------------------------------------------- Old description: New description: This synthetic ticket pertains to source:trunk/milena/mln/morpho * Fix documentation. * Check style, layout, and typo. * Add trace(s) in algorithms. * Move specializations to the `*.spe.hh` files. * Check `all.hh` presence. * Move the tests to its own specific directory. * Add the potential missing unit tests and full tests. Also, in particular: * Ensure dual operators have « symmetrical » definitions. For instance, source:trunk/milena/mln/morpho/dilation.hh and source:trunk/milena/mln/morpho/erosion.hh are really different! * Remove anything related to so-called « attached neighborhoods » (as far as I can remember, only source:trunk/milena/mln/morpho/dilation.hh uses the)m; we'll get back to this later, for Olena 1.1 (see #130). * (From #131:) Files source:trunk/milena/mln/morpho/opening_area.hh, source:trunk/milena/mln/morpho/opening_attribute.hh, etc. and their routines are called `opening_area` and `opening_attribute`, which is not elegant. Of course the goal is to put forward the « opening » term; but IMHO, we should use namespaces to do this, not prefixes. Or rename them to `area_opening` and `attribute_opening`, which are much more natural. Comment (by levill_r): Move some naming remarks from #131 to this ticket. -- Ticket URL: <https://trac.lrde.org/olena/ticket/74#comment:3> Olena <http://olena.lrde.epita.fr> Olena, a generic and efficient C++ image processing library.