dolfin team mailing list archive

[A Navaei <axnavaei@xxxxxxxxxxxxxx>]

2009/2/24 Johan Hake <hake@xxxxxxxxx>:
> On Tuesday 24 February 2009 16:17:43 A Navaei wrote:
>> 2009/2/24 Johan Hake <hake@xxxxxxxxx>:
>> > On Tuesday 24 February 2009 01:08:11 A Navaei wrote:
>> >> Finally after all those long discussions on the best way of
>> >> architecturing variational image processing problems based on dolfin,
>> >> a minimal demo showing how to solve a classical motion estimation PDE
>> >> is available now -- thanks for all the support. Detailed explanation
>> >> is given here:
>> >>
>> >> http://code.google.com/p/debiosee/wiki/DemosOptiocFlowHornSchunck
>> >>
>> >> Currently, the c++ implementation is done and the python wrapper is on
>> >> the way.
>> >
>> > Cool!
>> >
>> >> I have tried to perform sub-classing as much as possible and leave the
>> >> rest to be implemented outside of the main classes. While this works,
>> >> there is a tiny problem which I'm not quite happy about. Here is
>> >> what's happening:
>> >>
>> >> [ITK-backend]
>> >>
>> >>       v
>> >> [GenericImage]-------\
>> >>
>> >>       v              |
>> >> [ImageToMesh]        |
>> >>
>> >>       v              |
>> >> [FunctionSpace]      |
>> >>
>> >>       v              |
>> >> [ImageFunction]<-----/
>> >>
>> >> If you still cannot see what's happening, get a monospace font :) What
>> >> I don't like is the right branch connecting GenericImage to
>> >> ImageFunction. There should be a way of making sure that the two
>> >> branches are initiated from the same image source, or this could be a
>> >> source of error. Simply encapsulating this in a class takes away the
>> >> freedom of defining a general problem away from the user.
>> >
>> > Just a thought:
>> >
>> > Would it help to let GenericImage also be a dolfin::Mesh? Then in
>> > ITKImage you copy paste the algorithm for creating a
>> > UnitCube/UnitSquare/Rectange/Box (the algorithms are actually not very
>> > large).
>>
>> I understand that implemented algorithms are short, but maybe it's not
>> a good practice to copy/paste the code (even if it's a short code). We
>> should think of a more creative way of doing this.
>
> Sure ;)
>
> One alternative could be to inherit UnitSquare directly but then we need to
> put the creation algorithm in, e.g., an init function (protected such ;) ).
> This will then be called in the constructor, and we also need an empty
> constructor to be called by the inherited mesh, which may or may not make any
> sense at all.

This looks like something feasible to me. What about having a virtual
Mesh::Init() called in Mesh() so that the subclasses just have to
override Init()? Then in the ImageMesh case, the parent Init() should
be also called and the extra branch in the diagram will disappear.

In case you missed the other question, is the information about number
of cells in each dimension lost in UnitSquare or can it be retrieved?

-Ali

>
> Johan
>
>> > This means that you do not have to pass the ImagePointerType to
>> > ImageFunction, but only the FunctionSpace containing the ITKImage as a
>> > mesh?
>>
>> This would help getting rid of the extra branch, but, like I
>> mentioned, we need a better way of doing this.
>>
>> > Johan
>> >
>> >> Another problem is converting images back from functions. To do that,
>> >> we need image dimension, size and data pointer. Of these, it seems
>> >> that there is no way to re-construct image size from a given function
>> >> (any Function, not just ImageFunction, eg the solution of a PDE)
>> >> asuming that the corresponding mesh is a structured grid. For
>> >> instance, does UnitSquare store the input parameters from which the
>> >> image size can be restored?
>>
>> Would it make sense to have UnitSquare and UnitCube to store the
>> square/cube size in each dimension as attributes?
>>
>>
>> -Ali
>>
>> >> -Ali
>> >> _______________________________________________
>> >> DOLFIN-dev mailing list
>> >> DOLFIN-dev@xxxxxxxxxx
>> >> http://www.fenics.org/mailman/listinfo/dolfin-dev
>
>
>