dolfin team mailing list archive

[A Navaei <axnavaei@xxxxxxxxxxxxxx>]

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.

>
> 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
>
>
>