[Vv] vv day

David Sarrut David.Sarrut at creatis.insa-lyon.fr
Wed Oct 6 07:44:55 CEST 2010


Hello,

some information about the vv-(half)-day yesterday.

We made list of tasks that we think important and start working on the two
first points, but it is still not finished. We plan another vv-day,
next *Wednesday 13th
October*. If you want to join, just drop us a line with the task that you
want to study. Minutes are here : http://www.creatis.insa-lyon.fr/rio/vv/dev
.

Here we try to focus on VV *consolidation* not features improvement (which
can be the subject of another meeting).

*1) Correct memory bugs*
Two problems (related probably). The memory is not free when an image is
closed (both 3D and 4D). It uses twice the amount of memory needed by the
image. I started working on that, but it is still not clear where is the
problem. It can be maybe related to the  VtkImageReslice because it used to
work in the past, but maybe not. Moreover, on some computer, 3D images does
not seems to use twice the memory ... (with same vtk/itk versions).

*2) CMAKE & compilation improvement*
The first goal is to allow the compilation of vv without requiring to build
segmentation/registration/tools stuffs. [Joel is working on that, should be
commit soon. ]

The second goal is to allow the compilation of vv without compiling the
vv-tools (*and* without compiling the dependence of those tools). This is
important : it drastically speed up the compilation when developing, notably
because of the high compilation-time of "resample" or "convert". [Joel start
working on that ]

The question is still open to reduce the compilation time (slow down the
development cycle), which is really high for the filters that manage a lot
of image types (for example, "resample" or "convert" can manage 2D, 3D, 4D
images with 8 PixelTypes). The explicit instanciation in
clitkImageToImageFilterBase does not seems to really speed up the process.
For the moment, it is decided to at least isolate the code that take longer
to compile in order to disable it temporarily when developing.

Idea ?  Comments ?

*3) TOOLS consolidation*

- ToolMIP : correct bug, allow to choose axe and work with 3D images. [Joel
start working on that ]
 - ToolRemove ImageResample and replace by ResampleImage, allow auto gauss.
- ToolRegistrationTool has bug that must be corrected

*4) Useless Render*
The main issue is a lag with the zoom&pan when images are linked. It is
probably related to too much Render call. More generally, how the rendering
is manage needs a cleanup.

*5) Dashboard*
Joel set up cdash : http://public.kitware.com/dashboard.php?name=itk (search
for cepe and vv)
It works, compile all nights, but there are still difficulties with "upload"
from the hospital, maybe it will migrate to a CREATIS computer.
The idea is to build vv agains the Git ITK in order to be ready for the
future ITK v4. Presently, it does not compile : there is a problem with gdcm
includes. The question was asked to Mathieu Malaterre, we are waiting for a
solution.

*6) Migrate to GIT instead of CVS*
(with http://www.ohloh.net/ support ?)

*7) Error management*
Set every error with clitkExceptionMacro (inherit from itkException but does
not require an itk object to be called). It can contribute to clean the
code.

*8) Set all the tools in VV with the AutoTool principles*
AutoTool is like module or a plugin, but statically compiled. See
http://www.creatis.insa-lyon.fr/rio/clitk#VV_-_Auto_tools_part_1:_How-To

By using this principle, in particular for Fusion/Overlay etc, it can
largely contribute to clean the code. However, it is a long task.

*9) Main interface*
- add a grey scale (like 'ventilation')
- Fusion : add shift+right/click to change window/level. Add transparent
color (?).

*10) Command line has been improved, now "state-based" principle. More easy
to add new options. *

David


On Wed, Sep 29, 2010 at 15:24, Arnaud GELAS <arnaud_gelas at hms.harvard.edu>wrote:

>  Great!!!
>
> That would be great:
>
>    - to create a dashboard on my.cdash.org, to track possible build
>    failures due to some change of API in vtk/itk libraries
>     - to build every night vv
>        - on Mac, Windows, Linux
>          - with vtk release version / vtk git version
>          - with itk latest release version / itk git version
>        - to make vv one reference application for the ITKv4 effort by
>    reporting every night the results of build with ITK git version
>     - to extract components that could be reusable by (shared with)  other
>    projects, and in order to make joint projects / developments
>
> Cheers,
> Arnaud
>
>
> On 09/29/2010 08:01 AM, Simon Rit wrote:
>
> Sounds like a good initiative!
> I'm not sure what you have in mind but it would be nice to have:
> - a major code clean up. Remove everything that is unused and
> reorganize large code files in a readable way.
> - fix of memory leaks, try to do ShadowCopy instead of DeepCopy (see
> change of Joel which I have removed because it was causing rigid
> registration crashes)
> - organize rendering in a supportable way to avoid useless renders.
>
> About Kumar's email:
> - point 1: there is no solution, if you want two images to be fused,
> there has to be some blending... (cf my previous answer to Kumar). The
> only thing that could be done is to have some transparent colors on
> the fusion image.
> Kumar, what do you mean by "The interplay between the Base image
> Window/Level and overlay Window/Level is also not appropriate" ? For
> fusion, they are separated. For image overlay, we could do the same
> thing...
> - point 3: I agree, we should be able to disable all options to have a light vv.
>
> Cheers,
> Simon
>
> On Wed, Sep 29, 2010 at 12:45 PM, Dr.KUMAR RAJAMANI<k_rajamani at cb.amrita.edu> <k_rajamani at cb.amrita.edu> wrote:
>
>  Dear Joel, David
> Glad to hear about the code sprint
>
> The issues that matter most
>
> 1. The Display Window in VV is not perfect,
> Especially so in the Overlay/Fusion Mode
> The display is not bright and the the colormaps do not also
> address the brightness aspects
> There should be provision for non-linear correction of Window/Levels
> (Example Gamma Correction)
> There could be a widget to graphically control the Window/Level and also
> the mapping of intensity levels
>
> The interplay between the Base image Window/Level and overlay Window/Level
> is also not appropriate
>
> 2. There could be tool to draw ROI in a image
> ROI tools would add lot of value for VV tool
>
> 3. Registration Codes are now made mandatory in the current cvs version
> This could be made optional in the CMAKE files,
> Then only those interested need to recompile ITK with the flags
>
> If I get more thoughts I shall share them in subsequent emails
>
> Warm Regards
> Kumar
>
>
>
> From: Jo?l Schaerer <joel.schaerer at gmail.com> <joel.schaerer at gmail.com>
> To: "vv at creatis.insa-lyon.fr" <vv at creatis.insa-lyon.fr> <vv at creatis.insa-lyon.fr> <vv at creatis.insa-lyon.fr>,        Gauthier
>        BOUILHOL <gauthier.bouilhol at gmail.com> <gauthier.bouilhol at gmail.com>, Loic Grevillot
>        <loic.grevillot at gmail.com> <loic.grevillot at gmail.com>,     Louise Grezes-Besset
>        <louise.grezesbesset at gmail.com> <louise.grezesbesset at gmail.com>
> Subject: [Vv] vv day!
> Message-ID: <4CA30557.6060102 at gmail.com> <4CA30557.6060102 at gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
>  Hi all,
>
> With David we have scheduled to work on vv on Tuesday, October 5th in the manner
> of a "code sprint": we block the day to try to improve vv as much as possible!
> You are of course welcome to join us, but could you please tell us what are the
> issues that matter the most to you? This way we can set up a list of priorities
> and avoid wasting our time :)
>
> Thanks,
>
> joel
>
> --
> Jo?l Schaerer, PhD
> Post-doctoral researcher
>
> Centre de lutte contre le cancer L?on B?rard
> Service de radioth?rapie
> 28 rue La?nnec
> 69373 LYON CEDEX 08
>
> Tel: 04 78 78 51 50
>      06 26 65 29 54
> http://www.creatis.insa-lyon.fr/riohttp://www.creatis.insa-lyon.fr/rio/vv
>
>
>
> ------------------------------
>
> _______________________________________________
> vv mailing listvv at creatis.insa-lyon.frhttp://www.creatis.insa-lyon.fr/mailman/listinfo/vv
>
>
> End of vv Digest, Vol 7, Issue 11
> *********************************
>
>
>  _______________________________________________
> vv mailing listvv at creatis.insa-lyon.frhttp://www.creatis.insa-lyon.fr/mailman/listinfo/vv
>
>
>
> _______________________________________________
> vv mailing list
> vv at creatis.insa-lyon.fr
> http://www.creatis.insa-lyon.fr/mailman/listinfo/vv
>
>


-- 
David Sarrut, Phd
Chargé de recherche CNRS
Centre de lutte contre le cancer Léon Bérard
28 rue Laënnec, 69373 Lyon cedex 08
Laboratoire CREATIS-LRMN UMR CNRS 5220, Inserm U 630
Tel : 04 78 78 51 51 / 06 74 72 05 42
http://www.creatis.insa-lyon.fr/rio
_________________________________
 "2 + 2 = 5,  for extremely large values of 2"
_________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.creatis.insa-lyon.fr/pipermail/vv/attachments/20101006/b7556278/attachment.html>


More information about the vv mailing list