Thread Subject: Any way to speed up drawing of tiny patch object?

Hey.

I'm creating a program in MATLAB where a grid is drawn on a
histological image and a pathologist will click within certain grid
cells based on the features appearing within the cell.

I have the entire thing finished but am looking for an optimization.
I decided to draw a translucent patch object (in this case, a square)
on top of any cell which is clicked. The time taken to draw square
between "clicking on a cell" and "being ready to click on another
cell" is more than one second -- and I'd like it to be faster (i.e.
appearing to be "instantaneous") since a pathologist's time is
precious, as it is (note that our dataset includes hundreds of images
which will be split into 48 cells, each). Here's the snippet of the
code used to generate the patch:

% Earlier in the program...
p_facecolour = [0 1 0]; p_facealpha = 0.2;

% p_x1, p_y1, p_x2, p_y2 are calculated based on [x,y] returned from
ginput(1).
x = [p_x1 p_x1 p_x2 p_x2];
y = [p_y1 p_y2 p_y2 p_y1];
h_patch_array(row_select, col_select) = ...
   patch(x, y, p_facecolour, ...
   'FaceAlpha', p_facealpha);

(NB: I save the handle into an array so that I can turn the
Visiblility of the square on and off, if required.)
Is it just the case that it takes > 1 second to draw a patch,
regardless of size? I tried some of the tips at http://preview.tinyurl.com/43pj3u
but they didn't seem to make a difference. I don't know if this
request seems ridiculous, but I wanted to be sure that I'm not missing
anything obvious.

Thanks for any help you can give, either to speed this up or with a
suggestion about another way to go about this.

- Chris

"Chris P." <chris.peressotti@gmail.com> wrote in message
<c99b0c35-4eca-4087-981d-
ac5489bd7849@p25g2000hsf.googlegroups.com>...
> Hey.
>
> I'm creating a program in MATLAB where a grid is drawn
on a
> histological image and a pathologist will click within
certain grid
> cells based on the features appearing within the cell.
>
> I have the entire thing finished but am looking for an
optimization.
> I decided to draw a translucent patch object (in this
case, a square)
> on top of any cell which is clicked. The time taken to
draw square
> between "clicking on a cell" and "being ready to click
on another
> cell" is more than one second -- and I'd like it to be
faster (i.e.
> appearing to be "instantaneous") since a pathologist's
time is
> precious, as it is (note that our dataset includes
hundreds of images
> which will be split into 48 cells, each). Here's the
snippet of the
> code used to generate the patch:
>
> % Earlier in the program...
> p_facecolour = [0 1 0]; p_facealpha = 0.2;
>
> % p_x1, p_y1, p_x2, p_y2 are calculated based on [x,y]
returned from
> ginput(1).
> x = [p_x1 p_x1 p_x2 p_x2];
> y = [p_y1 p_y2 p_y2 p_y1];
> h_patch_array(row_select, col_select) = ...
> patch(x, y, p_facecolour, ...
> 'FaceAlpha', p_facealpha);
>
> (NB: I save the handle into an array so that I can turn
the
> Visiblility of the square on and off, if required.)
> Is it just the case that it takes > 1 second to draw a
patch,
> regardless of size? I tried some of the tips at
http://preview.tinyurl.com/43pj3u
> but they didn't seem to make a difference. I don't know
if this
> request seems ridiculous, but I wanted to be sure that
I'm not missing
> anything obvious.
>
> Thanks for any help you can give, either to speed this
up or with a
> suggestion about another way to go about this.
>
> - Chris

Chris,
There are several ways to specify patches. The
documentation is not the greatest. One way is to specify
the faces and vertices. This example is 3D but applies:

% patch experiment
x = [0 -0.08 0.08];
y = [1.02 1.02 1.02];
z = [1 1.19 1.19];
vert = [x(1) y(1) z(1); x(2) y(2) z(2); x(3) y(3) z(3)];
faces = [1 2 3];
fp = patch('Faces',faces,'Vertices',vert,...
           'FaceColor',[1 0 0],'EdgeColor',[1 1 1]);
hold on

This might render quicker. When I get home I'll tic/toc a
couple different methods and post the render times to this
thread. I need this information as well.

Back in a few hours,
Scott

"Chris P." <chris.peressotti@gmail.com> wrote in message
<c99b0c35-4eca-4087-981d-
ac5489bd7849@p25g2000hsf.googlegroups.com>...
> Hey.
>
> I'm creating a program in MATLAB where a grid is drawn on
a
> histological image and a pathologist will click within
certain grid
> cells based on the features appearing within the cell.
>
> I have the entire thing finished but am looking for an
optimization.
> I decided to draw a translucent patch object (in this
case, a square)
> on top of any cell which is clicked. The time taken to
draw square
> between "clicking on a cell" and "being ready to click on
another
> cell" is more than one second -- and I'd like it to be
faster (i.e.
> appearing to be "instantaneous") since a pathologist's
time is
> precious, as it is (note that our dataset includes
hundreds of images
> which will be split into 48 cells, each). Here's the
snippet of the
> code used to generate the patch:
>
> % Earlier in the program...
> p_facecolour = [0 1 0]; p_facealpha = 0.2;
>
> % p_x1, p_y1, p_x2, p_y2 are calculated based on [x,y]
returned from
> ginput(1).
> x = [p_x1 p_x1 p_x2 p_x2];
> y = [p_y1 p_y2 p_y2 p_y1];
> h_patch_array(row_select, col_select) = ...
> patch(x, y, p_facecolour, ...
> 'FaceAlpha', p_facealpha);
>
> (NB: I save the handle into an array so that I can turn
the
> Visiblility of the square on and off, if required.)
> Is it just the case that it takes > 1 second to draw a
patch,
> regardless of size? I tried some of the tips at
http://preview.tinyurl.com/43pj3u
> but they didn't seem to make a difference. I don't know
if this
> request seems ridiculous, but I wanted to be sure that
I'm not missing
> anything obvious.
>
> Thanks for any help you can give, either to speed this up
or with a
> suggestion about another way to go about this.
>
> - Chris

The transparency may be what is taking so much
computational effort. Try with solid-colored patches... you
will probably see a significant speed-up. The transparent
patches may look nicer, but I've noticed that adding
transparent objects or modifiying the transparency of an
object can sometimes be slow.

Ken

Additionally, if you still want to mimic the appearance of
a transparent patch, without transparency, you could
probably make the face color of the patch the average of
the image voxel below it and a highlight color. In other
words, if the voxel color is an RGB vector ([r g b]), and
you want a red highlight ([1 0 0]), then make the patch
face color [(r+1)/2 g/2 b/2]. Just a thought...

Ken

> There are several ways to specify patches. The
> documentation is not the greatest. One way is to specify
> the faces and vertices.

I'd seen that (and figured out how it would be done) but didn't
explore it since it seemed to imply that it's faster only for a patch
with many faces... however, I decided to do my own tic-tocing and drew
the patch twice for each click -- once by giving the vertices directly
to patch (I call this "(x,y)", below), and once by creating vertices/
faces matrices and sending those to patch ("(v,f)", below). I did ten
measurements (just listing a few, below):

(x,y) (v,f) (v,f)/(x,y)
0.000802 0.000359 0.45
0.000809 0.000509 0.63
... ... ...
0.000965 0.00037 0.38
0.000972 0.000458 0.47

The avg of the last column is .48, so (v,f) takes approximately half
the time. This is academically interesting, but... these numbers show
me that it really ISN'T patch that's causing the problem! According
to these numbers, it's taking less than 1 ms to draw the patch, and
the pathologist won't notice the difference between 1 ms and 0.5 ms.

I'm picking these points within a "while" loop, so I placed my tic-toc
around the ginput statement such that "toc" would be a measure of the
entire time taken between picking a point, processing the result,
drawing the patch, and being ready to pick the next point:
fprintf('%2.2f seconds from ginput-to-ginput\n', toc);
[ginput_x,ginput_y,ginput_button] = ginput(1);
tic

and these times resulted:
0.000818 seconds from ginput-to-ginput
0.000778 seconds from ginput-to-ginput
0.000783 seconds from ginput-to-ginput

Again, WTF? These are < 1 ms! So I then rearranged my tic-toc like
so, and made sure I was ready to click the next next as soon as I saw
the crosshairs for ginput appear:
[ginput_x,ginput_y,ginput_button] = ginput(1);
fprintf('%2.2f seconds from ginput-to-AFTER-ginput\n', toc);
tic

and these times resulted:
1.38 seconds from ginput-to-AFTER-ginput
1.36 seconds from ginput-to-AFTER-ginput
1.35 seconds from ginput-to-AFTER-ginput

SO, the problem is somewhere in ginput itself, yes? Does anyone have
any ideas? (I'm going to go through ginput with a fine-toothed comb
right now, but I thought I'd give this update in case anyone has a
quick answer.)

Thanks for your help so far,

- Chris

> SO, the problem is somewhere in ginput itself, yes? Does anyone have any ideas?
> (I'm going to go through ginput with a fine-toothed comb
> right now, but I thought I'd give this update in case anyone has a
> quick answer.)

So I've traced the problem to a call to "waitforbuttonpress", which is
a built-in function, so I think that my optimization stops here (so
long as I want to use the mouse as the tool to select the cells, and I
don't see a better option). C'est la vie.

- Chris

> So I've traced the problem to a call
to "waitforbuttonpress", which is
> a built-in function, so I think that my optimization
stops here (so
> long as I want to use the mouse as the tool to select the
cells, and I
> don't see a better option). C'est la vie.
>
> - Chris

Have you thought of writing your own point selection
routine using the WindowButtonFcns of the figure and the
CurrentPoint property of the axes? You may be able to write
a simpler, bare-bones version that runs faster.

Ken

"Chris P." <chris.peressotti@gmail.com> wrote in message
<77d1cc7e-35a5-4f8f-8baa-dde45491f432@w7g2000hsa.googlegroups.com>...
> > SO, the problem is somewhere in ginput itself, yes?
Does anyone have any ideas?
> > (I'm going to go through ginput with a fine-toothed comb
> > right now, but I thought I'd give this update in case
anyone has a
> > quick answer.)
>
> So I've traced the problem to a call to
"waitforbuttonpress", which is
> a built-in function, so I think that my optimization stops
here (so
> long as I want to use the mouse as the tool to select the
cells, and I
> don't see a better option). C'est la vie.
>
> - Chris

It's atrocious that ginput takes so long. Use the
ButtonDownFcn property of the image to define your own
callback to select a cell.

@ Ken and Darik

I had _not_ thought to write my own callback... and I've got a little
bit of experience with that stuff, already. Thanks for the
suggestion!

- Chris

> I had _not_ thought to write my own callback... and I've got a little
> bit of experience with that stuff, already. Thanks for the
> suggestion!

I gave it a go and it doesn't seem to be any faster, somehow. Would
anyone looking at this thread care to have a look at my code to see
what I might be doing wrong?

- Chris

"Chris P." <chris.peressotti@gmail.com> wrote in message <c5f6b0dc-116b-4ce5-8153-ee33925804d6@a70g2000hsh.googlegroups.com>...
> > I had _not_ thought to write my own callback... and I've got a little
> > bit of experience with that stuff, already. Thanks for the
> > suggestion!
>
> I gave it a go and it doesn't seem to be any faster, somehow. Would
> anyone looking at this thread care to have a look at my code to see
> what I might be doing wrong?
>
> - Chris

I had the same problem and worked around it like this. I copied ginput and commented out the lines with uisuspend and uirestore in them and put those calls in my own code surrounding the ginput. Something like this:

state = uisuspend(gcf);
while(loop)
 [x y] = ginput_noui(1); % modified version which doesn't use uisuspend or uirestore
 loop = do_something(x,y);
end
uirestore(state);

this solved my problems, just make sure the uirestore gets called everytime or your gui will stop behaving properly.
Hope this works for you too,

Dirkjan Krijnders