[Vv] vv day

[Simon Rit]

Great!
About the memory bug, we had checked with Joel that VtkImageReslice
did not use twice the memory so I doubt that this is the problem.
Anyhow, it's easy to turn it off for testing and I could put it back
to "CLITK_EXPERIMENTAL"as it used to be. Let me know if you are not
working on it, I could try.
About point 2 (compilation time), have you considered to investigate
itk explicite instantiation?
About point 3 (tools), image arithm was crashing on my laptop in
Beijing, I haven't done the test on linux... I have added it to the
todo list
About point 9 (fusion win/lev), it would be great to do it for overlay
as well (ctrl+click?)

It looks to me that the rest of the points are long shot objectives
and could be part of the internship if get an intern.
Good work!
Simon

On Wed, Oct 6, 2010 at 7:44 AM, David Sarrut
<David.Sarrut at creatis.insa-lyon.fr> wrote:
> 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> 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>
>> To: "vv at creatis.insa-lyon.fr" <vv at creatis.insa-lyon.fr>,        Gauthier
>>        BOUILHOL <gauthier.bouilhol at gmail.com>, Loic Grevillot
>>        <loic.grevillot at gmail.com>,     Louise Grezes-Besset
>>        <louise.grezesbesset at gmail.com>
>> Subject: [Vv] vv day!
>> Message-ID: <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/rio
>> http://www.creatis.insa-lyon.fr/rio/vv
>> ------------------------------
>> _______________________________________________
>> vv mailing list
>> vv at creatis.insa-lyon.fr
>> http://www.creatis.insa-lyon.fr/mailman/listinfo/vv
>> End of vv Digest, Vol 7, Issue 11
>> *********************************
>>
>> _______________________________________________
>> vv mailing list
>> vv at creatis.insa-lyon.fr
>> http://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"
> _________________________________
>
> _______________________________________________
> vv mailing list
> vv at creatis.insa-lyon.fr
> http://www.creatis.insa-lyon.fr/mailman/listinfo/vv
>
>