[Vv] vv day

Tue Oct 12 23:30:43 CEST 2010

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