[Vv] vv day

Thu Oct 14 11:01:14 CEST 2010

  Here are a few patches against VTK5.6.0 to help debug the memory leak, 
assuming it is on the VTK side of vv. To apply them,

git apply *.patch

just make sure you are on the right tag of VTK beforehand.

joel

On 10/12/2010 11:30 PM, Simon Rit wrote:
> Hi,
> As promised, I have looked at the memory problem. There are actually
> two problems in my opinion:
> - the current implementation of vtkImageReslice creates an additional
> full image in memory. There are 2 reasons: I introduced a
> vtkGridTransform which triggers a full update systematically (see
> this->ResliceTransform->IsA("vtkHomogeneousTransform") in
> vtkImageReslice::RequestUpdateExtent). I removed this one. The second
> reason is the first mImageReslice->Update() in vvImage::AddImage which
> by default computes everything. I'm currently trying to figure out a
> solution to that problem, I don't see an easy one so far. I have
> disabled image reslicing for the time being so no more affine
> transformations (see define in vvImage.cxx).
>
> - the way we manage the whole itk to vtk conversion is probably
> suboptimal. Currently, we read an ITK image, use an importer to VTK
> called itk::ImageToVTKImageFilter, create a vtkImageData and do a
> DeepCopy from the output of the importer to the image (see
> vvFromITK.h). That means that we have an ITK image, a nice converter
> to VTK with callbacks and delete those two to create a vtkImageData.
> Joel had tried a ShallowCopy instead of a DeepCopy but that doesn't
> work, I think that it's because the itk pipeline (reader and importer)
> is deleted at the end of vvImageReader. I suggest to change the
> philosophy of vvImage by storing a pointer to the importer in vvImage.
> Then we have a pointer to an itk image (input of the importer) and a
> vtk image (output of the importer). There is an article by Enquobahrie
> and Ibanez with such a philosophy, that could be a nice solution:
> http://www.insight-journal.org/browse/publication/146
> In this way, we would never have to copy data when we go back and
> forth between itk and vtk since we would have both without doubling
> the memory.
>
> I'll work on the first point, feel free to comment and/or implement the second!
> Simon
>
> On Wed, Oct 6, 2010 at 9:52 AM, Simon Rit
> <simon.rit at creatis.insa-lyon.fr>  wrote:
>> 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
>>>
>>>
> _______________________________________________
> vv mailing list
> vv at creatis.insa-lyon.fr
> http://www.creatis.insa-lyon.fr/mailman/listinfo/vv

-- 
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-instrumentation-to-correct-leaks.patch
Type: text/x-patch
Size: 1574 bytes
Desc: not available
URL: <http://www.creatis.insa-lyon.fr/pipermail/vv/attachments/20101014/3d050ce2/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-more-instrumentation.patch
Type: text/x-patch
Size: 2816 bytes
Desc: not available
URL: <http://www.creatis.insa-lyon.fr/pipermail/vv/attachments/20101014/3d050ce2/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-more-instrumentation.patch
Type: text/x-patch
Size: 922 bytes
Desc: not available
URL: <http://www.creatis.insa-lyon.fr/pipermail/vv/attachments/20101014/3d050ce2/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-even-more-instrumentation.patch
Type: text/x-patch
Size: 3384 bytes
Desc: not available
URL: <http://www.creatis.insa-lyon.fr/pipermail/vv/attachments/20101014/3d050ce2/attachment-0003.bin>