<div>Hello, </div><div><br></div><div>some information about the vv-(half)-day yesterday. </div><div><br></div><div>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 <b>Wednesday 13th October</b>. If you want to join, just drop us a line with the task that you want to study. Minutes are here : <a href="http://www.creatis.insa-lyon.fr/rio/vv/dev">http://www.creatis.insa-lyon.fr/rio/vv/dev</a>. </div>
<meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br></div><div>Here we try to focus on VV <b>consolidation</b> not features improvement (which can be the subject of another meeting).</div><div><br>
</div><div><b>1) Correct memory bugs</b></div><div>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).</div>
<div><br></div><div><b>2) CMAKE & compilation improvement</b></div><div>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. ]</div>
<div><br></div><div>The second goal is to allow the compilation of vv without compiling the vv-tools (<i>and</i> 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 ]</div>
<div><br></div><div>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. </div>
<div><br></div><div>Idea ? Comments ?</div><div><br></div><div><b>3) TOOLS consolidation</b></div><div><br></div><div>- ToolMIP : correct bug, allow to choose axe and work with 3D images. [Joel start working on that ]</div>
<div>
- ToolRemove ImageResample and replace by ResampleImage, allow auto gauss. </div><div>- ToolRegistrationTool has bug that must be corrected</div><div><br></div><div><b>4) Useless Render</b></div><div>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. </div>
<div><br></div><div><b>5) Dashboard</b></div><div>Joel set up cdash : <a href="http://public.kitware.com/dashboard.php?name=itk" target="_blank">http://public.kitware.com/dashboard.php?name=itk</a> (search for cepe and vv)</div>
<div>It works, compile all nights, but there are still difficulties with "upload" from the hospital, maybe it will migrate to a CREATIS computer. </div>
<div>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.</div>
<div><br></div><div><b>6) Migrate to GIT instead of CVS</b></div><div>(with <a href="http://www.ohloh.net/">http://www.ohloh.net/</a> support ?)</div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>
<br></div><div><b>7) Error management</b></div><div>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. </div>
<div><br></div><div><b>8) Set all the tools in VV with the AutoTool principles</b></div><div>AutoTool is like module or a plugin, but statically compiled. See <a href="http://www.creatis.insa-lyon.fr/rio/clitk#VV_-_Auto_tools_part_1:_How-To">http://www.creatis.insa-lyon.fr/rio/clitk#VV_-_Auto_tools_part_1:_How-To</a></div>
<meta http-equiv="content-type" content="text/html; charset=utf-8"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br></div><div>By using this principle, in particular for Fusion/Overlay etc, it can largely contribute to clean the code. However, it is a long task. </div>
<div><br></div><div><b>9) Main interface</b></div><div>- add a grey scale (like 'ventilation')</div><div>- Fusion : add shift+right/click to change window/level. Add transparent color (?).</div><div><br></div><div>
<b>10) Command line has been improved, now "state-based" principle. More easy to add new options. </b></div>
<div><br></div><div>David</div><div><br></div><br><div class="gmail_quote">On Wed, Sep 29, 2010 at 15:24, Arnaud GELAS <span dir="ltr"><<a href="mailto:arnaud_gelas@hms.harvard.edu" target="_blank">arnaud_gelas@hms.harvard.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#ffffff" text="#000000">
Great!!!<br>
<br>
That would be great:<br>
<ul>
<li>to create a dashboard on <a href="http://my.cdash.org" target="_blank">my.cdash.org</a>, to track possible build
failures due to some change of API in vtk/itk libraries<br>
</li>
<ul>
<li>to build every night vv <br>
</li>
<ul>
<li>on Mac, Windows, Linux</li>
<li>with vtk release version / vtk git version</li>
<li>with itk latest release version / itk git version</li>
</ul>
</ul>
<li>to make vv one reference application for the ITKv4 effort by
reporting every night the results of build with ITK git version<br>
</li>
<li>to extract components that could be reusable by (shared with)
other projects, and in order to make joint projects /
developments</li>
</ul>
Cheers,<br><font color="#888888">
Arnaud</font><div><div></div><div><br>
<br>
On 09/29/2010 08:01 AM, Simon Rit wrote:
<blockquote type="cite">
<pre>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
<a href="mailto:k_rajamani@cb.amrita.edu" target="_blank"><k_rajamani@cb.amrita.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre>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 <a href="mailto:joel.schaerer@gmail.com" target="_blank"><joel.schaerer@gmail.com></a>
To: <a href="mailto:vv@creatis.insa-lyon.fr" target="_blank">"vv@creatis.insa-lyon.fr"</a> <a href="mailto:vv@creatis.insa-lyon.fr" target="_blank"><vv@creatis.insa-lyon.fr></a>, Gauthier
BOUILHOL <a href="mailto:gauthier.bouilhol@gmail.com" target="_blank"><gauthier.bouilhol@gmail.com></a>, Loic Grevillot
<a href="mailto:loic.grevillot@gmail.com" target="_blank"><loic.grevillot@gmail.com></a>, Louise Grezes-Besset
<a href="mailto:louise.grezesbesset@gmail.com" target="_blank"><louise.grezesbesset@gmail.com></a>
Subject: [Vv] vv day!
Message-ID: <a href="mailto:4CA30557.6060102@gmail.com" target="_blank"><4CA30557.6060102@gmail.com></a>
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
<a href="http://www.creatis.insa-lyon.fr/rio" target="_blank">http://www.creatis.insa-lyon.fr/rio</a>
<a href="http://www.creatis.insa-lyon.fr/rio/vv" target="_blank">http://www.creatis.insa-lyon.fr/rio/vv</a>
------------------------------
_______________________________________________
vv mailing list
<a href="mailto:vv@creatis.insa-lyon.fr" target="_blank">vv@creatis.insa-lyon.fr</a>
<a href="http://www.creatis.insa-lyon.fr/mailman/listinfo/vv" target="_blank">http://www.creatis.insa-lyon.fr/mailman/listinfo/vv</a>
End of vv Digest, Vol 7, Issue 11
*********************************
</pre>
</blockquote>
<pre>_______________________________________________
vv mailing list
<a href="mailto:vv@creatis.insa-lyon.fr" target="_blank">vv@creatis.insa-lyon.fr</a>
<a href="http://www.creatis.insa-lyon.fr/mailman/listinfo/vv" target="_blank">http://www.creatis.insa-lyon.fr/mailman/listinfo/vv</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
vv mailing list<br>
<a href="mailto:vv@creatis.insa-lyon.fr" target="_blank">vv@creatis.insa-lyon.fr</a><br>
<a href="http://www.creatis.insa-lyon.fr/mailman/listinfo/vv" target="_blank">http://www.creatis.insa-lyon.fr/mailman/listinfo/vv</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>David Sarrut, Phd<br>Chargé de recherche CNRS<br>Centre de lutte contre le cancer Léon Bérard<br>28 rue Laënnec, 69373 Lyon cedex 08<br>Laboratoire CREATIS-LRMN UMR CNRS 5220, Inserm U 630<br>
Tel : 04 78 78 51 51 / 06 74 72 05 42<br><a href="http://www.creatis.insa-lyon.fr/rio" target="_blank">http://www.creatis.insa-lyon.fr/rio</a><br>_________________________________<br> "2 + 2 = 5, for extremely large values of 2"<br>
_________________________________<br>