[Insight-users] help

degachi wided lion_dwided at yahoo.fr
Sat May 23 11:45:31 EDT 2009


Bonjour à tous le monde.j'ai deux problèmes, et je demande votre aide. Je sais pas comment accéder à un pixel d'une image en utilisant itk seulement et comment je peut séparer chaque région tous seul en utilisant l'algorithme d'EM-expectation maximisation.je vous remerci d'avance.

--- En date de : Sam 23.5.09, insight-users-request at itk.org <insight-users-request at itk.org> a écrit :

De: insight-users-request at itk.org <insight-users-request at itk.org>
Objet: Insight-users Digest, Vol 61, Issue 92
À: insight-users at itk.org
Date: Samedi 23 Mai 2009, 2h57

Send Insight-users mailing list submissions to
    insight-users at itk.org

To subscribe or unsubscribe via the World Wide Web, visit
    http://www.itk.org/mailman/listinfo/insight-users
or, via email, send a message with subject or body 'help' to
    insight-users-request at itk.org

You can reach the person managing the list at
    insight-users-owner at itk.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Insight-users digest..."


Today's Topics:

   1. Re: itk.PyBuffer memory leak (Ga?tan Lehmann)
   2. Processing of median filter in debug (Ivan Macia)
   3. Re: Processing of median filter in debug (John Drescher)
   4. Re: Processing of median filter in debug (Bill Lorensen)
   5. dependency on imview (Darren Weber)
   6. Attending? RSVP please, ITK Code Review, May 28-29,    2009 at
      NLM (Terry Yoo)
   7. Re: dependency on imview (Richard Beare)


----------------------------------------------------------------------

Message: 1
Date: Fri, 22 May 2009 18:56:35 +0200
From: Ga?tan Lehmann <gaetan.lehmann at jouy.inra.fr>
Subject: Re: [Insight-users] itk.PyBuffer memory leak
To: Rick Giuly <rgiuly at gmail.com>
Cc: ITK Users <insight-users at itk.org>
Message-ID: <69B55A56-B590-47FC-8363-3F0ED14C7863 at jouy.inra.fr>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed";
    DelSp="yes"


My test also work on the stable version of wrapitk (with a few changes  
in command manipulation).

I tried with the test you provided, and this time I get an error:

    RuntimeError: Contiguous array couldn't be created from input  
python object

This error is sent from PyBuffer when it can't convert the input  
python object to the expected type. Maybe the array returned by  
numpy.ones() is not a contigus array?

Ga?tan


Le 22 mai 09 ? 15:56, Ga?tan Lehmann a ?crit :

>
> Hi Rick,
>
> Yes, I looked at it in wrapitk *unstable* - it may not be the one  
> you're using.
> I can't reproduce the problem you have. Here is the test I've run:
>
> #!/usr/bin/env python
>
> import itk, sys, gc
> itk.auto_progress()
>
> # image size is 1 GB
> # IT = itk.Image.UC3
> # img = IT.New(Regions=1000)
>
> # image size is 1 GB
> IT = itk.Image.F3
> img = IT.New(Regions=[1000, 1000, 250])
>
> img.Allocate()
> img.FillBuffer(0)
>
> print img
>
> # exercise buffer conversion from itk to numpy
> for i in range(1000):
>  buf = itk.PyBuffer[IT].GetArrayFromImage(img)
> del buf
>
> # exercise buffer conversion from numpy to itk
>
> count = 0
>
> def callback():
>  global count
>  sys.stderr.write(str(count)+"\t")
>  if count%10 == 0:
>    sys.stderr.write("\n")
>  sys.stderr.flush()
>  count += 1
> com = itk.PyCommand.New()
> com.SetCommandCallable( callback )
>
> buf = itk.PyBuffer[IT].GetArrayFromImage(img)
>
> for i in range(1000):
>  bi = itk.PyBuffer[IT].GetImageFromArray(buf)
>  bi.AddObserver( itk.DeleteEvent(), com )
> del bi
>
> # force garbage collection
> gc.collect()
>
> sys.stderr.write(str(count)+"\n")
>
> sys.exit(abs(1000-count))
>
>
>
>
> I'm now looking at wrapitk stable. I'll let you know what I'll found.
>
> Ga?tan
>
>
> Le 22 mai 09 ? 06:16, Rick Giuly a ?crit :
>
>> Hi Ga?tan,
>>
>> Have you had a chance to look at this?
>>
>> thanks
>>
>> -rick
>>
>> Ga?tan Lehmann wrote:
>>> Le 13 mai 09 ? 10:35, Rick Giuly a ?crit :
>>>>
>>>> I've now tested invoking garbage collection with gc.collect() at  
>>>> every iteration and that didn't change the problem. So, my best  
>>>> guess would be that the image is not deleted when the python  
>>>> object is destroyed. Maybe a bug?
>>> Maybe - can you file a bug on ITK's bug tracker and assign it to me?
>>> I'll try to find a bit of time to investigate this in the next days.
>>>>
>>>>
>>>>
>>>> Ga?tan Lehmann wrote:
>>>>> Hi Rick,
>>>>> GetImageFromArray() returns a smart pointer to an image, so the  
>>>>> image should be deallocated once the python object is destroyed.
>>>>> Perhaps the problem is there: the garbage collection my not run  
>>>>> fast enough.
>>>>> The right way to go may be to implement PyBuffer as a filter  
>>>>> which reuse the output image, as all the filters in itk.
>>>>> For the Delete() method: you shouldn't use it in python (and I  
>>>>> can't see any case for use it but the internal memory management  
>>>>> in c++). In the latest version of wrapitk (the one hosted at  
>>>>> googlecode), Delete() and the other methods related to smart  
>>>>> pointers are hidden.
>>>>> Regards,
>>>>> Ga?tan
>>>>> Le 11 mai 09 ? 05:43, Rick Giuly a ?crit :
>>>>>>
>>>>>> Hello All,
>>>>>>
>>>>>> It seems that converter.GetImageFromArray(inputNumpyVolume)  
>>>>>> allocates memory in some way and never releases it. When I  
>>>>>> tried using Delete() the program actually crashed silently  
>>>>>> after one iteration.
>>>>>>
>>>>>> Test code is below. (I'm running this on ubuntu, and the itk  
>>>>>> package is from Paul Novo's site.)
>>>>>>
>>>>>> Is there some way to release memory?
>>>>>>
>>>>>>
>>>>>>
>>>>>> import itk
>>>>>> import numpy
>>>>>>
>>>>>> for i in range(10000):
>>>>>>
>>>>>> print i
>>>>>>
>>>>>> ImageType = itk.Image[itk.F, 3]
>>>>>> converter = itk.PyBuffer[ImageType]
>>>>>>
>>>>>> inputNumpyVolume = numpy.ones((100, 100, 200))
>>>>>> inputVolume = converter.GetImageFromArray(inputNumpyVolume)
>>>>>> #inputVolume.Delete()
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----------
>>>>>> Thanks,
>>>>>> --Rick
>>>>>> _____________________________________
>>>>>> Powered by www.kitware.com
>>>>>>
>>>>>> Visit other Kitware open-source projects at
>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>
>>>>>> Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ
>>>>>>
>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>> http://www.itk.org/mailman/listinfo/insight-users
>>>>
>>
>
> -- 
> Ga?tan Lehmann
> Biologie du D?veloppement et de la Reproduction
> INRA de Jouy-en-Josas (France)
> tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
> http://voxel.jouy.inra.fr  http://www.mandriva.org
> http://www.itk.org  http://www.clavier-dvorak.org
>

-- 
Ga?tan Lehmann
Biologie du D?veloppement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
http://voxel.jouy.inra.fr  http://www.mandriva.org
http://www.itk.org  http://www.clavier-dvorak.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: Ceci est une signature ?lectronique PGP
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090522/24f46772/attachment-0001.pgp>

------------------------------

Message: 2
Date: Fri, 22 May 2009 20:45:12 +0200
From: Ivan Macia <imacia at vicomtech.org>
Subject: [Insight-users] Processing of median filter in debug
To: Insight Users <insight-users at itk.org>
Message-ID:
    <a199a2980905221145s75446cd8x15d403ff6f669feb at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi,

I have been doing some 3D image processing with a Median filter. I added
some SimpleFilterWatcher to monitor progress. The input image was not too
large, about 250x40x175. I'm running an Intel Core 2 Quad Q6600 (4 cores) 3
Gb. RAM on WinXP SP3 and ITK 3.12 with VS2008.

The filter was running quite fast in release mode but I thought I had a
problem in debug since the progress did not update and it seemed to be
stuck. Now waiting a bit the progress started to grow at a very low pace.
The thing is that I changed the number of threads to a single thread and the
filter was running much faster in debug mode. In Release mode, as expected,
the it was more than twice faster. Just wondering, is it normal that the
cost of running four threads in debug mode makes it so slow? Is this related
to the IDE or OS?

Thanks in advance

Iv?n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090522/6d895d1f/attachment-0001.htm>

------------------------------

Message: 3
Date: Fri, 22 May 2009 14:55:15 -0400
From: John Drescher <drescherjm at gmail.com>
Subject: Re: [Insight-users] Processing of median filter in debug
To: Ivan Macia <imacia at vicomtech.org>
Cc: Insight Users <insight-users at itk.org>
Message-ID:
    <387ee2020905221155r45b71778uc140c771130dc57 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Fri, May 22, 2009 at 2:45 PM, Ivan Macia <imacia at vicomtech.org> wrote:
> Hi,
>
> I have been doing some 3D image processing with a Median filter. I added
> some SimpleFilterWatcher to monitor progress. The input image was not too
> large, about 250x40x175. I'm running an Intel Core 2 Quad Q6600 (4 cores) 3
> Gb. RAM on WinXP SP3 and ITK 3.12 with VS2008.
>
> The filter was running quite fast in release mode but I thought I had a
> problem in debug since the progress did not update and it seemed to be
> stuck. Now waiting a bit the progress started to grow at a very low pace.
> The thing is that I changed the number of threads to a single thread and the
> filter was running much faster in debug mode. In Release mode, as expected,
> the it was more than twice faster. Just wondering, is it normal that the
> cost of running four threads in debug mode makes it so slow? Is this related
> to the IDE or OS?
>
I have seen this myself and it forced me to debug in releasewithdeb
mode instead because instead of taking 30 seconds to process the
median filter on a 0.625 x 0.625 x 0.625  it ended up taking on the
order of 30 minutes.

John


------------------------------

Message: 4
Date: Fri, 22 May 2009 15:25:03 -0400
From: Bill Lorensen <bill.lorensen at gmail.com>
Subject: Re: [Insight-users] Processing of median filter in debug
To: John Drescher <drescherjm at gmail.com>
Cc: Insight Users <insight-users at itk.org>
Message-ID:
    <4db4735c0905221225p2b51f54cy386b46289377c8bf at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Yes, we have seen this with Debug mode. I didn't realize that the
number of threads affected it. I just thought it was slow. As John
mentioned, try RelWithDebinfo. That's how I normally debug.

Bill

On Fri, May 22, 2009 at 2:55 PM, John Drescher <drescherjm at gmail.com> wrote:
> On Fri, May 22, 2009 at 2:45 PM, Ivan Macia <imacia at vicomtech.org> wrote:
>> Hi,
>>
>> I have been doing some 3D image processing with a Median filter. I added
>> some SimpleFilterWatcher to monitor progress. The input image was not too
>> large, about 250x40x175. I'm running an Intel Core 2 Quad Q6600 (4 cores) 3
>> Gb. RAM on WinXP SP3 and ITK 3.12 with VS2008.
>>
>> The filter was running quite fast in release mode but I thought I had a
>> problem in debug since the progress did not update and it seemed to be
>> stuck. Now waiting a bit the progress started to grow at a very low pace.
>> The thing is that I changed the number of threads to a single thread and the
>> filter was running much faster in debug mode. In Release mode, as expected,
>> the it was more than twice faster. Just wondering, is it normal that the
>> cost of running four threads in debug mode makes it so slow? Is this related
>> to the IDE or OS?
>>
> I have seen this myself and it forced me to debug in releasewithdeb
> mode instead because instead of taking 30 seconds to process the
> median filter on a 0.625 x 0.625 x 0.625 ?it ended up taking on the
> order of 30 minutes.
>
> John
> _____________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-users
>


------------------------------

Message: 5
Date: Fri, 22 May 2009 15:46:14 -0700
From: Darren Weber <darren.weber.lists at gmail.com>
Subject: [Insight-users] dependency on imview
To: insight-users at itk.org
Message-ID:
    <b808b3510905221546n15c0d097jd12c59269ed60145 at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

How extensive is the dependency in ITK on imview?

For example, the tutorial here requires imview to display a 2D image:
http://farsight-toolkit.org/wiki/FARSIGHT_Tutorials/Quick_Start

Thanks, Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090522/dd152e52/attachment-0001.htm>

------------------------------

Message: 6
Date: Fri, 22 May 2009 18:15:41 -0400
From: Terry Yoo <tyoo at mail.nih.gov>
Subject: [Insight-users] Attending? RSVP please, ITK Code Review, May
    28-29,    2009 at NLM
To: insight-users <insight-users at itk.org>
Message-ID: <6C8A3626-B83C-4D86-B14A-DE99DCE649A6 at mail.nih.gov>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes


NLM is convening a meeting to collect input on the current status as  
well as input on future directions for ITK on May 28-29, 2009.  The  
announcement for this meeting was made as a Special Notice posted as  
FBO announcement number 09-104-CYC.

We are preparing to host this meeting.  We are seeking a head count as  
part of these preparations.  If you are planning to attend the ITK  
Code Review May 28-29, please RSVP by sending an e-mail to Terry Yoo a tyoo at mail.nih.gov

Thank you.

Terry S. Yoo, PhD
Office of High Performance Computing and Communications
National Library of Medicine
National Institutes of Health
tyoo at mail.nih.gov



On May 14, 2009, at 5:02 PM, Yoo, Terry (NIH/NLM/LHC) [E] wrote:
>
> The Special Notice has been posted on FBO. The announcement number
> 09-104-CYC.
>
> The National Library of Medicine, Office of High Performance
> Computing and Communications is seeking input regarding the
> current status of the Insight Toolkit (ITK) as well as input on
> future directions for this image-processing software library.
> We are holding a meeting to perform a code review, an
> informal audit of the state of ITK.  We intend to
> explore the elements of the library that are most in need
> of revision, the current stability of the library including
> a review of the policy for backward compatibility in ITK,
> the need for extending support in ITK for high performance
> computing environments, and the need for simplifying the
> use of ITK for entry-level programmers.  The goal is to
> prioritize development efforts for ITK, focusing the
> programming community on a shared plan.  This meeting will
> be held from 9AM, May 28, 2009, until Noon, May 29th, 2009,
> in the HPCC Collaboratory, National Library of Medicine, NIH
> Building 38A, Room B1N30E.  For more information, see the
> following URL:  http://visual.nlm.nih.gov/itk
>
> https://www.fbo.gov/index?s=opportunity&mode=form&id=0812333190b08edde0c3bec549eb11db&tab=core&_cview=0
>
>
> Terry S. Yoo, PhD
> Office of High Performance Computing and Communications
> National Library of Medicine
> National Institutes of Health
> tyoo at mail.nih.gov



------------------------------

Message: 7
Date: Sat, 23 May 2009 10:51:29 +1000
From: Richard Beare <richard.beare at gmail.com>
Subject: Re: [Insight-users] dependency on imview
To: Darren Weber <darren.weber.lists at gmail.com>
Cc: insight-users at itk.org
Message-ID:
    <779dabeb0905221751m27a8f11ftca986d05836d750f at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Not at all.

Imview is callable from the python interface, and maybe people have
added it to other language bindings too. There is an Imview package
that uses some of the image server capabilities of Imview - check
Gaetan's darcs site for that. Alternative viewers can be called
instead, by defining environment variables used by show2d.

An example from Gaetan:

It is also possible to use a different viewer in the itk.show2D()
function by defining the WRAPITK_SHOW2D_COMMAND environment. For
example, for imagej, I have:

 export WRAPITK_SHOW2D_COMMAND="/usr/java/jdk1.6.0/bin/java -Xmx1024m
-jar /home/glehmann/ImageJ/ij.jar %s  -run 'View 100%%' &"
 export WRAPITK_SHOW2D_LABEL_COMMAND="/usr/java/jdk1.6.0/bin/java
-Xmx1024m -jar /home/glehmann/ImageJ/ij.jar %s  -run 'View 100%%' -run
'3-3-2 RGB' &"
 export WRAPITK_SHOW2D_COMPRESS=off


The imview server binding has some advantages in that it allows a
closer coupling of imview and the interpreter which lets you build
prototype interactive applications, and better performance because
there are no intermediate files - there are some examples in the
source package. It will also work with 3D images. The downside is that
colour images aren't supported yet.

On Sat, May 23, 2009 at 8:46 AM, Darren Weber
<darren.weber.lists at gmail.com> wrote:
>
> How extensive is the dependency in ITK on imview?
>
> For example, the tutorial here requires imview to display a 2D image:
> http://farsight-toolkit.org/wiki/FARSIGHT_Tutorials/Quick_Start
>
> Thanks, Darren
>
>
> _____________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-users
>
>


------------------------------

_______________________________________________
Insight-users mailing list
Insight-users at itk.org
http://www.itk.org/mailman/listinfo/insight-users


End of Insight-users Digest, Vol 61, Issue 92
*********************************************



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090523/8d4617af/attachment-0001.htm>


More information about the Insight-users mailing list