Fwd: mayavi - subclassing ImagePlaneWidget Module

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: mayavi - subclassing ImagePlaneWidget Module

M Trumpis
<sent from wrong address>

Hi all.. I've been playing around with plotting rgba values directly
into an ImagePlaneWidget. So far, I've learned that I can

1) create a 4-scalar-component ImageData source, type "unsigned_char"
2) plot this through an ImagePlaneWidget by bypassing the color mapping, ie:

In [18]: ipw.ipw.lookup_table = None

In [19]: ipw.ipw.color_map.lookup_table = None

I've sub-classed ArraySource to create a special purpose rgba source,
whose scalar_data array accepts data shaped (nx, ny, [nz], 4).

I'm looking for guidance subclassing the mayavi ImagePlaneWidget
"Module". Easiest solution looks like over-riding update_pipeline(),
so that it does not assign the lookup tables. But it seems like a
waste to create the LUTs in the first place. Is there a way to turn
off the ModuleManager colormapping right from the start? Is that a bad
idea?

Mike
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: mayavi - subclassing ImagePlaneWidget Module

Gael Varoquaux
On Wed, Mar 10, 2010 at 04:14:58PM -0800, M Trumpis wrote:
> <sent from wrong address>

> Hi all.. I've been playing around with plotting rgba values directly
> into an ImagePlaneWidget. So far, I've learned that I can

> 1) create a 4-scalar-component ImageData source, type "unsigned_char"
> 2) plot this through an ImagePlaneWidget by bypassing the color mapping, ie:

> In [18]: ipw.ipw.lookup_table = None

> In [19]: ipw.ipw.color_map.lookup_table = None

> I've sub-classed ArraySource to create a special purpose rgba source,
> whose scalar_data array accepts data shaped (nx, ny, [nz], 4).

> I'm looking for guidance subclassing the mayavi ImagePlaneWidget
> "Module". Easiest solution looks like over-riding update_pipeline(),
> so that it does not assign the lookup tables. But it seems like a
> waste to create the LUTs in the first place. Is there a way to turn
> off the ModuleManager colormapping right from the start? Is that a bad
> idea?

Hey Mike,

Quickly (MICCAI deadline tonight...): it seems absolutely right to want
to use IPW without creating and using a LUT. I thought that there was a
design flaw that prevented doing this properly in Mayavi a few releases
ago, but I thought that we had fixed that:
https://svn.enthought.com/enthought/changeset?new=24169%40Mayavi%2Ftrunk%2Fenthought%2Fmayavi%2Fmodules%2Fimage_plane_widget.py&old=23011%40Mayavi%2Ftrunk%2Fenthought%2Fmayavi%2Fmodules%2Fimage_plane_widget.py

I have never had time to use it this way, the I don't really know how
good or bad the fix is.

In general, I am very much interested by the usage pattern that you
expose above (we might have some comon applications :)). Would you mind
sharing your code, as well as your finding on what could be changed in
Mayavi to make your life easier.

Cheers,

Gaël
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: mayavi - subclassing ImagePlaneWidget Module

M Trumpis
Hey

On Wed, Mar 10, 2010 at 11:53 PM, Gael Varoquaux
<[hidden email]> wrote:

>
> On Wed, Mar 10, 2010 at 04:14:58PM -0800, M Trumpis wrote:
> > <sent from wrong address>
>
> > Hi all.. I've been playing around with plotting rgba values directly
> > into an ImagePlaneWidget. So far, I've learned that I can
>
> > 1) create a 4-scalar-component ImageData source, type "unsigned_char"
> > 2) plot this through an ImagePlaneWidget by bypassing the color mapping, ie:
>
> > In [18]: ipw.ipw.lookup_table = None
>
> > In [19]: ipw.ipw.color_map.lookup_table = None
>
> > I've sub-classed ArraySource to create a special purpose rgba source,
> > whose scalar_data array accepts data shaped (nx, ny, [nz], 4).
>
> > I'm looking for guidance subclassing the mayavi ImagePlaneWidget
> > "Module". Easiest solution looks like over-riding update_pipeline(),
> > so that it does not assign the lookup tables. But it seems like a
> > waste to create the LUTs in the first place. Is there a way to turn
> > off the ModuleManager colormapping right from the start? Is that a bad
> > idea?
>
> Hey Mike,
>
> Quickly (MICCAI deadline tonight...): it seems absolutely right to want
> to use IPW without creating and using a LUT. I thought that there was a
> design flaw that prevented doing this properly in Mayavi a few releases
> ago, but I thought that we had fixed that:
> https://svn.enthought.com/enthought/changeset?new=24169%40Mayavi%2Ftrunk%2Fenthought%2Fmayavi%2Fmodules%2Fimage_plane_widget.py&old=23011%40Mayavi%2Ftrunk%2Fenthought%2Fmayavi%2Fmodules%2Fimage_plane_widget.py
>
> I have never had time to use it this way, the I don't really know how
> good or bad the fix is.
>

I noticed the "use_lookup_table". The problem I have with it is with a
usage like this:

ipw = mlab.pipeline.image_plane_widget(src)
ipw.use_lookup_table = False
ipw.ipw.color_map.lookup_table = None
ipw.ipw.lookup_table = None
mlab.show()

somehow the LUTs get restored. I haven't found what over-rides the
use_lookup_table option. Anyway, re-implementing update_pipeline()
with a few deletions is working.

>
> In general, I am very much interested by the usage pattern that you
> expose above (we might have some comon applications :)). Would you mind
> sharing your code, as well as your finding on what could be changed in
> Mayavi to make your life easier.
>

Take a look at this for now.. you can run the mayavi_tools.py script
to get an example. This is looking better than having multiple IPWs in
the same space, but it ain't fast!

https://cirl.berkeley.edu/trac/browser/bic/scratch/nm/nutmeg/vis/mayavi_tools.py
https://cirl.berkeley.edu/trac/browser/bic/scratch/nm/nutmeg/vis/rgba_blending.py

(watch out there is some weave in there)

Mike

> Cheers,
>
> Gaël
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: mayavi - subclassing ImagePlaneWidget Module

Gael Varoquaux
On Thu, Mar 11, 2010 at 03:38:08PM -0800, M Trumpis wrote:
> I noticed the "use_lookup_table". The problem I have with it is with a
> usage like this:

> ipw = mlab.pipeline.image_plane_widget(src)
> ipw.use_lookup_table = False
> ipw.ipw.color_map.lookup_table = None
> ipw.ipw.lookup_table = None
> mlab.show()

> somehow the LUTs get restored. I haven't found what over-rides the
> use_lookup_table option. Anyway, re-implementing update_pipeline()
> with a few deletions is working.


> > In general, I am very much interested by the usage pattern that you
> > expose above (we might have some comon applications :)). Would you mind
> > sharing your code, as well as your finding on what could be changed in
> > Mayavi to make your life easier.


> Take a look at this for now.. you can run the mayavi_tools.py script
> to get an example. This is looking better than having multiple IPWs in
> the same space, but it ain't fast!

> https://cirl.berkeley.edu/trac/browser/bic/scratch/nm/nutmeg/vis/mayavi_tools.py
> https://cirl.berkeley.edu/trac/browser/bic/scratch/nm/nutmeg/vis/rgba_blending.py

Cool. The modifications you had to make to ImagePlaneWidget and
ArraySource seem quite OK to me. I think it should be possible to modify
the upstream objects so that there is a flag (and it actually works) to
avoid avoid you having to subclass. If you can send a patch along it
would be great; I'll try to keep this on the top of my TODO list, as it
seems that we have some easy wins here.

> (watch out there is some weave in there)

Yeah, and it actually does not build on my box :( :

usr/lib/python2.6/dist-packages/scipy/weave/blitz/blitz/mathfunc.h: In
static member function ‘static long int blitz::_bz_abs<long int>::apply(long int)’:
/usr/lib/python2.6/dist-packages/scipy/weave/blitz/blitz/mathfunc.h:45:
error: ‘labs’ is not a member of ‘std’

See you,

Gaël
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: mayavi - subclassing ImagePlaneWidget Module

M Trumpis
On Thu, Mar 11, 2010 at 10:36 PM, Gael Varoquaux
<[hidden email]> wrote:

> On Thu, Mar 11, 2010 at 03:38:08PM -0800, M Trumpis wrote:
>> I noticed the "use_lookup_table". The problem I have with it is with a
>> usage like this:
>
>> ipw = mlab.pipeline.image_plane_widget(src)
>> ipw.use_lookup_table = False
>> ipw.ipw.color_map.lookup_table = None
>> ipw.ipw.lookup_table = None
>> mlab.show()
>
>> somehow the LUTs get restored. I haven't found what over-rides the
>> use_lookup_table option. Anyway, re-implementing update_pipeline()
>> with a few deletions is working.
>
>
>> > In general, I am very much interested by the usage pattern that you
>> > expose above (we might have some comon applications :)). Would you mind
>> > sharing your code, as well as your finding on what could be changed in
>> > Mayavi to make your life easier.
>
>
>> Take a look at this for now.. you can run the mayavi_tools.py script
>> to get an example. This is looking better than having multiple IPWs in
>> the same space, but it ain't fast!
>
>> https://cirl.berkeley.edu/trac/browser/bic/scratch/nm/nutmeg/vis/mayavi_tools.py
>> https://cirl.berkeley.edu/trac/browser/bic/scratch/nm/nutmeg/vis/rgba_blending.py
>
> Cool. The modifications you had to make to ImagePlaneWidget and
> ArraySource seem quite OK to me. I think it should be possible to modify
> the upstream objects so that there is a flag (and it actually works) to
> avoid avoid you having to subclass. If you can send a patch along it
> would be great; I'll try to keep this on the top of my TODO list, as it
> seems that we have some easy wins here.
>

will work on that..

>> (watch out there is some weave in there)
>
> Yeah, and it actually does not build on my box :( :
>
> usr/lib/python2.6/dist-packages/scipy/weave/blitz/blitz/mathfunc.h: In
> static member function ‘static long int blitz::_bz_abs<long int>::apply(long int)’:
> /usr/lib/python2.6/dist-packages/scipy/weave/blitz/blitz/mathfunc.h:45:
> error: ‘labs’ is not a member of ‘std’
>

Oh boy.. I have seen that before. But I have no recollection of how
I've fixed it. There are no modifications in my scipy trunk. Do you
know if you have run any other blitz-converted weave code?

Mike

> See you,
>
> Gaël
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: mayavi - subclassing ImagePlaneWidget Module

Gael Varoquaux
On Thu, Mar 11, 2010 at 10:43:38PM -0800, M Trumpis wrote:
> > Yeah, and it actually does not build on my box :( :

> > usr/lib/python2.6/dist-packages/scipy/weave/blitz/blitz/mathfunc.h: In
> > static member function ‘static long int blitz::_bz_abs<long int>::apply(long int)’:
> > /usr/lib/python2.6/dist-packages/scipy/weave/blitz/blitz/mathfunc.h:45:
> > error: ‘labs’ is not a member of ‘std’


> Oh boy.. I have seen that before. But I have no recollection of how
> I've fixed it. There are no modifications in my scipy trunk. Do you
> know if you have run any other blitz-converted weave code?

Probably a missing dep. Don't worry too much, its not important (at least
for me).

Gaël
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: mayavi - subclassing ImagePlaneWidget Module

Gael Varoquaux
In reply to this post by Gael Varoquaux
On Fri, Mar 12, 2010 at 07:36:05AM +0100, Gael Varoquaux wrote:
> Cool. The modifications you had to make to ImagePlaneWidget and
> ArraySource seem quite OK to me. I think it should be possible to modify
> the upstream objects so that there is a flag (and it actually works) to
> avoid avoid you having to subclass. If you can send a patch along it
> would be great; I'll try to keep this on the top of my TODO list, as it
> seems that we have some easy wins here.

Yesterday, I was sitting in a meeting and I had a go at fixing the
support of 'user_lookup_table' in ImagePlaneWidget. It seems to be
working for me with the attached patch. Would you care to review/test it?

Gaël

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev

image_plane_widget.py.diff (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Fwd: Fwd: mayavi - subclassing ImagePlaneWidget Module

M Trumpis
sent from wrong address again...


Hi Gael, very sorry to let this drop off the face of the earth for the
past few weeks. I've been running on a parallel track for a little
while now, but I wish to resurrect this thread..

On Sat, Mar 13, 2010 at 12:09 PM, Gael Varoquaux
<[hidden email]> wrote:

> On Fri, Mar 12, 2010 at 07:36:05AM +0100, Gael Varoquaux wrote:
>> Cool. The modifications you had to make to ImagePlaneWidget and
>> ArraySource seem quite OK to me. I think it should be possible to modify
>> the upstream objects so that there is a flag (and it actually works) to
>> avoid avoid you having to subclass. If you can send a patch along it
>> would be great; I'll try to keep this on the top of my TODO list, as it
>> seems that we have some easy wins here.
>
> Yesterday, I was sitting in a meeting and I had a go at fixing the
> support of 'user_lookup_table' in ImagePlaneWidget. It seems to be
> working for me with the attached patch. Would you care to review/test it?
>

Ok.. it looks like your small patch is working out. I've been using it
in my development code since you've sent it without trouble. So that's
great, thank you! I will work on the ArraySource patch on my end this
morning.

Now going a little deeper, there is another issue that's been causing
me some concern:

Suppose I have an RGBA source created, with an image_plane_widget
(IPW) displaying cuts into it. Either by design or benign oversight,
if I simply change the "scalar_data" from the source in-place, then
the vtk pipeline updates the changes very quickly. (BUT, it requires
interacting with each widget before the newly inserted images
re-draw--still very quickly).

However, if I do the right thing and call update() on the source, then
there is a huge lag before drawing. I tracked this down to bookkeeping
by the Module Manager, which listens for the "data_changed" event, and
wants to scan the whole array for the scalar range for the purpose of
color mapping. In particular, practically the entire time is spent in
_get_np_arr(self, arr) in module_manager.py

Anyway, given the case where I don't want the Module Manager to handle
color mapping, I haven't got a good idea for cleanly disconnecting the
Module Manager from the data_changed event. Any thoughts on your end?
I think the way to go for this case might be not to use the
mlab.pipeline approach, since the Module Manager seems a burden.

Kind regards,

Mike

> Gaël
>
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
>
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: mayavi - subclassing ImagePlaneWidget Module

M Trumpis
In reply to this post by Gael Varoquaux
>
> Cool. The modifications you had to make to ImagePlaneWidget and
> ArraySource seem quite OK to me. I think it should be possible to modify
> the upstream objects so that there is a flag (and it actually works) to
> avoid avoid you having to subclass. If you can send a patch along it
> would be great; I'll try to keep this on the top of my TODO list, as it
> seems that we have some easy wins here.
>

Ok.. here's a patch to the array_source.py allowing for 4-dimensional
rgba byte arrays. The one ambiguity here is when a user passes in a 3D
array like this:

a = np.empty((10,20,4), 'B')

I am kind of assuming that if it's uint8, and the last dimension is
length-4, then treat it as an rgba byte array. It's always possible
that someone just wants to plot that type and shape of array! You
could have a "color_mapped" Trait, so that

ArraySource(color_mapped=True, scalar_data=np.empty((10,20,4), 'B'))

disambiguates the situation

Mike

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev

array_source.py.diff (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Fwd: mayavi - subclassing ImagePlaneWidget Module

Gael Varoquaux
In reply to this post by M Trumpis
On Thu, Apr 01, 2010 at 10:44:25AM -0700, M Trumpis wrote:
> Hi Gael, very sorry to let this drop off the face of the earth for the
> past few weeks. I've been running on a parallel track for a little
> while now, but I wish to resurrect this thread..

Don't worry, I know this feeling...

> On Sat, Mar 13, 2010 at 12:09 PM, Gael Varoquaux
> <[hidden email]> wrote:
> > On Fri, Mar 12, 2010 at 07:36:05AM +0100, Gael Varoquaux wrote:
> >> Cool. The modifications you had to make to ImagePlaneWidget and
> >> ArraySource seem quite OK to me. I think it should be possible to modify
> >> the upstream objects so that there is a flag (and it actually works) to
> >> avoid avoid you having to subclass. If you can send a patch along it
> >> would be great; I'll try to keep this on the top of my TODO list, as it
> >> seems that we have some easy wins here.

> > Yesterday, I was sitting in a meeting and I had a go at fixing the
> > support of 'user_lookup_table' in ImagePlaneWidget. It seems to be
> > working for me with the attached patch. Would you care to review/test it?


> Ok.. it looks like your small patch is working out. I've been using it
> in my development code since you've sent it without trouble.

Excellent. I've committed it. Thanks for your feedback.

> Now going a little deeper, there is another issue that's been causing
> me some concern:

> [snip]

> Anyway, given the case where I don't want the Module Manager to handle
> color mapping, I haven't got a good idea for cleanly disconnecting the
> Module Manager from the data_changed event. Any thoughts on your end?
> I think the way to go for this case might be not to use the
> mlab.pipeline approach, since the Module Manager seems a burden.

The module manager is a core element of the Mayavi architecture.
Currently, you cannot really use Mayavi without defining module managers
for each module. I believe that in certain cases, like the one that you
just outlined, it is a burden, and the module manager should probably be
rendered optional. However, that would require a lot of rework to Mayavi
and I believe that neither of us have time right now.

My thoughts are that the two issues that you have been having recently
seem to stress that the module manager is useless and almost harmfull
when dealing with data that actually expresses color information. In both
cases, the solution seems to be to turn off the module manager. Here is
what I suggest: if the data is of the right type propose to the user to
switch of the module manager.

This change could be done at the module manager. You can have a look at
enthought/mayavi/modules/image_actor (lines around 64 and 100) to have an
idea how the data type check can be enforced. A traits could be added to
the module manager to turn it off. With luck, it should enable to clean
up/simplify the relevant parts in image_actor and image_plane_widget, for
which the corresponding traits could be delegated to the module manager
trait.

Do you think you can cook up a patch for this? I can provide help/advice,
but I will be very busy in the next month because I am hunting currently
hunting for a position.

Basically, what we are getting at, is that Mayavi does not have good
handling for color datasets. You have started adding required features
with your ArraySource patch (I'll look at it right after I finish this
mail), and we can add on demand what is needed as we discover the flawds.
At some point, I'll probably sprint with whoever is willing to help me to
wrap up all these patches in a consistent functionnality, but having
people discovering problems and sending in patches will help me a lot.

Thanks,

Gaël
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: mayavi - subclassing ImagePlaneWidget Module

Gael Varoquaux
In reply to this post by M Trumpis
On Thu, Apr 01, 2010 at 12:27:34PM -0700, M Trumpis wrote:

> > Cool. The modifications you had to make to ImagePlaneWidget and
> > ArraySource seem quite OK to me. I think it should be possible to modify
> > the upstream objects so that there is a flag (and it actually works) to
> > avoid avoid you having to subclass. If you can send a patch along it
> > would be great; I'll try to keep this on the top of my TODO list, as it
> > seems that we have some easy wins here.


> Ok.. here's a patch to the array_source.py allowing for 4-dimensional
> rgba byte arrays.

Looks good to me. A few comments at the end of the mail.

> The one ambiguity here is when a user passes in a 3D array like this:

> a = np.empty((10,20,4), 'B')

> I am kind of assuming that if it's uint8, and the last dimension is
> length-4, then treat it as an rgba byte array. It's always possible
> that someone just wants to plot that type and shape of array! You
> could have a "color_mapped" Trait, so that

> ArraySource(color_mapped=True, scalar_data=np.empty((10,20,4), 'B'))

> disambiguates the situation

I'd rather have a simple rule: RGBA arrays need to have 4 dimensions. If
you want to create a 'flat' RGBA array, passed in an 'empty' dimension,
such as:

a = np.empty((10, 20, 1, 4), 'B')

Comments on the patch: the functionnality it good, IMHO. The only thing
that worries me is that we can easily slip into 'magic' functionnality,
added in to special-case a need. This functionnality might never be
discovered by other users. Mayavi is already pretty challenging to use
:). To prevent this from happening, could you please:

    1) Update the docstring of ArraySource

    2) Line 28 of array_source.py: tell why you want dtype='B': to give
       RGBA color information, coded as 4 unsigned integers components ranging
       from 0 to 255.

    3) Could you also add a full example of using ArraySource and
       ImagePlaneWidget to examples/mayavi/advanced_visualization/. That
       way users can use this example to discover this functionnality,
       and how to use it. Also, we can use the example to guide API
       design in an 'example-driven-development' way, that I have found
       very effective. I am sending an example that I have personnaly
       been using for this. It shows immediatly a problem that the VTK
       pipeline is unhappy when adding additional image plane widgets. I
       am not sure where the problem lies, but it will be interesting to
       keep an eye on it, as we progress on adding RGBA support.

Thanks a lot for your contributions,

Gaël

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev

activation_map.py (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: mayavi - subclassing ImagePlaneWidget Module

M Trumpis
On Sat, Apr 3, 2010 at 12:55 PM, Gael Varoquaux
<[hidden email]> wrote:

> On Thu, Apr 01, 2010 at 12:27:34PM -0700, M Trumpis wrote:
>
>> > Cool. The modifications you had to make to ImagePlaneWidget and
>> > ArraySource seem quite OK to me. I think it should be possible to modify
>> > the upstream objects so that there is a flag (and it actually works) to
>> > avoid avoid you having to subclass. If you can send a patch along it
>> > would be great; I'll try to keep this on the top of my TODO list, as it
>> > seems that we have some easy wins here.
>
>
>> Ok.. here's a patch to the array_source.py allowing for 4-dimensional
>> rgba byte arrays.
>
> Looks good to me. A few comments at the end of the mail.
>
>> The one ambiguity here is when a user passes in a 3D array like this:
>
>> a = np.empty((10,20,4), 'B')
>
>> I am kind of assuming that if it's uint8, and the last dimension is
>> length-4, then treat it as an rgba byte array. It's always possible
>> that someone just wants to plot that type and shape of array! You
>> could have a "color_mapped" Trait, so that
>
>> ArraySource(color_mapped=True, scalar_data=np.empty((10,20,4), 'B'))
>
>> disambiguates the situation
>
> I'd rather have a simple rule: RGBA arrays need to have 4 dimensions. If
> you want to create a 'flat' RGBA array, passed in an 'empty' dimension,
> such as:
>
> a = np.empty((10, 20, 1, 4), 'B')
sounds good. That simplifies the validation a bit--now there are just
two branches (if dtype.char=='B' ... else ...)

>
> Comments on the patch: the functionnality it good, IMHO. The only thing
> that worries me is that we can easily slip into 'magic' functionnality,
> added in to special-case a need. This functionnality might never be
> discovered by other users. Mayavi is already pretty challenging to use
> :). To prevent this from happening, could you please:
>
>    1) Update the docstring of ArraySource
>
>    2) Line 28 of array_source.py: tell why you want dtype='B': to give
>       RGBA color information, coded as 4 unsigned integers components ranging
>       from 0 to 255.
>
both done

>    3) Could you also add a full example of using ArraySource and
>       ImagePlaneWidget to examples/mayavi/advanced_visualization/. That
>       way users can use this example to discover this functionnality,
>       and how to use it. Also, we can use the example to guide API
>       design in an 'example-driven-development' way, that I have found
>       very effective. I am sending an example that I have personnaly
>       been using for this. It shows immediatly a problem that the VTK
>       pipeline is unhappy when adding additional image plane widgets. I
>       am not sure where the problem lies, but it will be interesting to
>       keep an eye on it, as we progress on adding RGBA support.
>
I couldn't figure out what the problem was there either. I haven't
encountered the problem before, and the good news is when I swap out
the tvtk ImageData for a patched ArraySource, the error messages
disappear.

For an example, I've just changed up your activation_map.py script.
For illustrative purposes, I added another component to the data, on
which I contour, and then color the surface of the contour with the
original RGBA color data.

> Thanks a lot for your contributions,

of course! once again, sorry for the multi-week lag. By the way, is
this too late for the ETS release?

Mike

>
> Gaël
>
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
>

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev

array_source.py.diff (9K) Download Attachment
rgba_activation_map.py (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: mayavi - subclassing ImagePlaneWidget Module

Gael Varoquaux
Hey Mike,

I won't be able to put in some time to think on these issues for a little
while. On the other hand, I believe that Prabhu is around Berkeley. If
you find time to talk to him about the specific problems you have
encountered, it would be useful.

Cheers,

Gaël

On Wed, May 26, 2010 at 11:33:57AM -0700, M Trumpis wrote:
> On Sat, Apr 3, 2010 at 12:55 PM, Gael Varoquaux
> <[hidden email]> wrote:
> > On Thu, Apr 01, 2010 at 12:27:34PM -0700, M Trumpis wrote:

> >> > Cool. The modifications you had to make to ImagePlaneWidget and
> >> > ArraySource seem quite OK to me. I think it should be possible to modify
> >> > the upstream objects so that there is a flag (and it actually works) to
> >> > avoid avoid you having to subclass. If you can send a patch along it
> >> > would be great; I'll try to keep this on the top of my TODO list, as it
> >> > seems that we have some easy wins here.


> >> Ok.. here's a patch to the array_source.py allowing for 4-dimensional
> >> rgba byte arrays.

> > Looks good to me. A few comments at the end of the mail.

> >> The one ambiguity here is when a user passes in a 3D array like this:

> >> a = np.empty((10,20,4), 'B')

> >> I am kind of assuming that if it's uint8, and the last dimension is
> >> length-4, then treat it as an rgba byte array. It's always possible
> >> that someone just wants to plot that type and shape of array! You
> >> could have a "color_mapped" Trait, so that

> >> ArraySource(color_mapped=True, scalar_data=np.empty((10,20,4), 'B'))

> >> disambiguates the situation

> > I'd rather have a simple rule: RGBA arrays need to have 4 dimensions. If
> > you want to create a 'flat' RGBA array, passed in an 'empty' dimension,
> > such as:

> > a = np.empty((10, 20, 1, 4), 'B')

> sounds good. That simplifies the validation a bit--now there are just
> two branches (if dtype.char=='B' ... else ...)


> > Comments on the patch: the functionnality it good, IMHO. The only thing
> > that worries me is that we can easily slip into 'magic' functionnality,
> > added in to special-case a need. This functionnality might never be
> > discovered by other users. Mayavi is already pretty challenging to use
> > :). To prevent this from happening, could you please:

> >    1) Update the docstring of ArraySource

> >    2) Line 28 of array_source.py: tell why you want dtype='B': to give
> >       RGBA color information, coded as 4 unsigned integers components ranging
> >       from 0 to 255.


> both done

> >    3) Could you also add a full example of using ArraySource and
> >       ImagePlaneWidget to examples/mayavi/advanced_visualization/. That
> >       way users can use this example to discover this functionnality,
> >       and how to use it. Also, we can use the example to guide API
> >       design in an 'example-driven-development' way, that I have found
> >       very effective. I am sending an example that I have personnaly
> >       been using for this. It shows immediatly a problem that the VTK
> >       pipeline is unhappy when adding additional image plane widgets. I
> >       am not sure where the problem lies, but it will be interesting to
> >       keep an eye on it, as we progress on adding RGBA support.


> I couldn't figure out what the problem was there either. I haven't
> encountered the problem before, and the good news is when I swap out
> the tvtk ImageData for a patched ArraySource, the error messages
> disappear.

> For an example, I've just changed up your activation_map.py script.
> For illustrative purposes, I added another component to the data, on
> which I contour, and then color the surface of the contour with the
> original RGBA color data.

> > Thanks a lot for your contributions,

> of course! once again, sorry for the multi-week lag. By the way, is
> this too late for the ETS release?

> Mike


> > Gaël

> > _______________________________________________
> > Enthought-Dev mailing list
> > [hidden email]
> > https://mail.enthought.com/mailman/listinfo/enthought-dev





> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev


--
    Gael Varoquaux
    Research Fellow, INRIA
    Laboratoire de Neuro-Imagerie Assistee par Ordinateur
    NeuroSpin/CEA Saclay , Bat 145, 91191 Gif-sur-Yvette France
    Phone:  ++ 33-1-69-08-78-35
    Mobile: ++ 33-6-28-25-64-62
    http://gael-varoquaux.info
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev