2009/2/24 Johan Hake <[email protected]>: > 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 >> [email protected] >> http://www.fenics.org/mailman/listinfo/dolfin-dev > > > _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
