dolfin team mailing list archive

[A Navaei <axnavaei@xxxxxxxxxxxxxx>]

2009/2/24 Kent Andre <kent-and@xxxxxxxxx>:
>
> This looks very good!!
> I could not find this demo in the svn repository ?
> Is debiosee a separate project?

Which repository did you search for? The itk-dolfin interface from
wrapitk in going to be removed, you should use debiosee by itself from
now. The link to the code is given at the beginning of the demo wiki.

>
> How do you go from the functional to the weak form, differentiate ?

Yes, like dealing with any other PDEs, simply perform variational
differentiation leading to the Euler-Lagrange equation and you will
have the weak form.


-Ali

>
> Kent
>
>
> On ti., 2009-02-24 at 00:08 +0000, 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.
>>
>> 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.
>>
>> 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?
>>
>>
>> -Ali
>> _______________________________________________
>> DOLFIN-dev mailing list
>> DOLFIN-dev@xxxxxxxxxx
>> http://www.fenics.org/mailman/listinfo/dolfin-dev
>
>