From: Corey Kelly on
ImageAnalyst <imageanalyst(a)mailinator.com> wrote in message <fc52d984-1a2f-41a8-87c1-3901e7ebb10b(a)v37g2000vbv.googlegroups.com>...
> On May 20, 10:07 pm, "Corey Kelly" <ckell...(a)uoguelph.ca> wrote:
> > That would be my "Step 3." The part I'm having more trouble is allowing the user to interactively choose the (x,y). I'm basically looking at a high resolution image stack, and choosing the ROIs which will then be processed. The ROIs are only easily identified if the image is scrolling through the time frames.
> ------------------------------------------------------------------
> Why don't you average together all your frames, or take the max or min
> of them. That might make it easier to decide where to locate your
> points or ROI than just looking at a single time point image. You'll
> probably get a better signal - more contrast with less noise.
>
> Then you can use ginput(), imrect(), imellipse(), or something like
> that.

This is where it gets fairly complicated, and the reason that I'm making the ROI choice interactive. The points which I'm interested in are not characterized by a certain brightness or shape, but rather by a characteristic brightness oscillation along the time axis. I've experimented with extracting these points programmatically, but I couldn't develop a method which was robust enough. This is why I've resorted to choosing the points by hand.
I've been reading the Image Processing Toolbox documentation and I'll likely end up using impoint() and/or imellipse(), but I'm quite certain that the ROI placement will have to be by mouse point. I don't think it would be a difficult problem with a static image, but should I expect a lot of trouble trying to add ROIs to my axes if they contain something like an implay() ?
Thanks for your interest in my problem.
From: Walter Roberson on
Corey Kelly wrote:
> If anybody can help with any
> of the remaining problems, I'd appreciate it!
>
> 1. Image sequence (already in memory) is shown in a window, looping
> through frames.

put up the first image and remember the handle. pause() briefly. For the
remainder of the show, each time you want to change the image, set() the
CData property of the image handle to the new data, and then pause()
briefly. The pause is important because it has the side effect of doing
drawnow() -- and, of course, of giving the user a chance to do
something, since callbacks will not interrupt until a pause() or drawnow() .

> 2. When the user clicks on the image, the image coordinates of the mouse
> pointer are stored to memory.

ginput(1)

except I think that probably would wait rather than continuing to show
the image, so you probably want to instead turn some Hittest properties
off and use a ButtonPressCallbackFcn (figure level possibly).
From: Corey Kelly on
Walter Roberson <roberson(a)hushmail.com> wrote in message <CqmJn.8839$%u7.3596(a)newsfe14.iad>...
> Corey Kelly wrote:
> > If anybody can help with any
> > of the remaining problems, I'd appreciate it!
> >
> > 1. Image sequence (already in memory) is shown in a window, looping
> > through frames.
>
> put up the first image and remember the handle. pause() briefly. For the
> remainder of the show, each time you want to change the image, set() the
> CData property of the image handle to the new data, and then pause()
> briefly. The pause is important because it has the side effect of doing
> drawnow() -- and, of course, of giving the user a chance to do
> something, since callbacks will not interrupt until a pause() or drawnow() .
>
> > 2. When the user clicks on the image, the image coordinates of the mouse
> > pointer are stored to memory.
>
> ginput(1)
>
> except I think that probably would wait rather than continuing to show
> the image, so you probably want to instead turn some Hittest properties
> off and use a ButtonPressCallbackFcn (figure level possibly).

Excellent! I was just reading the help for ginput(). A few questions, though. First, you say that callbacks will not interrupt intil a pause() or drawnow(). Does this mean that if a callback occurs at any other time, it isn't processed, or just that it is processed at the next instance of pause or drawnow?
Next, as I'm fairly new with GUIs, I'm not sure what you mean by the CData property. I seem to have my images displaying properly without the use of this property.
Finally, regarding your last comment, where might I read about Hittest, and the use of a ButtonPressCallbackFcn?
Thank you so much for your time and suggestions!
From: Walter Roberson on
Corey Kelly wrote:

> Excellent! I was just reading the help for ginput(). A few questions,
> though. First, you say that callbacks will not interrupt intil a pause()
> or drawnow(). Does this mean that if a callback occurs at any other
> time, it isn't processed, or just that it is processed at the next
> instance of pause or drawnow?

It depends on the properties associated with the callback.

http://www.mathworks.com/access/helpdesk/help/techdoc/creating_guis/bq61qtj-1.html

"If theInterruptible property of the object whose callback is executing
is on, the callback can be interrupted. However, it is interrupted only
when it, or a function it triggers, calls drawnow, figure, getframe,
pause, or waitfor. Before performing their defined tasks, these
functions process any events in the event queue, including any waiting
callbacks. If the executing callback, or a function it triggers, calls
none of these functions, it cannot be interrupted regardless of the
value of its object's Interruptible property."

> Next, as I'm fairly new with GUIs, I'm not sure what you mean by the
> CData property. I seem to have my images displaying properly without the
> use of this property.

When you create an image, the picture gets saved as the CData property
of the image object.

http://www.mathworks.com/access/helpdesk/help/techdoc/ref/image_props.html#CData

You can change the displayed image by changing the CData property of the
existing image. This is faster than deleting the old image and creating
a new one. In general, if you have an existing object (image, surface,
line plot) and you want to replace it with another item of the same
variety, then it is more efficient to change the properties of the
existing object than to create a new one.

> Finally, regarding your last comment, where might I read about Hittest,
> and the use of a ButtonPressCallbackFcn?

The following describes it better:
http://www.mathworks.com/support/solutions/en/data/1-1B03X/?solution=1-1B03X

I see that images do have a ButtonDownFcn callback:

http://www.mathworks.com/access/helpdesk/help/techdoc/ref/image_props.html

Not sure where I came up with the name ButtonPressFcnCallback :(

From: Corey Kelly on
Walter Roberson <roberson(a)hushmail.com> wrote in message <D4nJn.8843$%u7.6021(a)newsfe14.iad>...
> Corey Kelly wrote:
>
> > Excellent! I was just reading the help for ginput(). A few questions,
> > though. First, you say that callbacks will not interrupt intil a pause()
> > or drawnow(). Does this mean that if a callback occurs at any other
> > time, it isn't processed, or just that it is processed at the next
> > instance of pause or drawnow?
>
> It depends on the properties associated with the callback.
>
> http://www.mathworks.com/access/helpdesk/help/techdoc/creating_guis/bq61qtj-1.html
>
> "If theInterruptible property of the object whose callback is executing
> is on, the callback can be interrupted. However, it is interrupted only
> when it, or a function it triggers, calls drawnow, figure, getframe,
> pause, or waitfor. Before performing their defined tasks, these
> functions process any events in the event queue, including any waiting
> callbacks. If the executing callback, or a function it triggers, calls
> none of these functions, it cannot be interrupted regardless of the
> value of its object's Interruptible property."
>
> > Next, as I'm fairly new with GUIs, I'm not sure what you mean by the
> > CData property. I seem to have my images displaying properly without the
> > use of this property.
>
> When you create an image, the picture gets saved as the CData property
> of the image object.
>
> http://www.mathworks.com/access/helpdesk/help/techdoc/ref/image_props.html#CData
>
> You can change the displayed image by changing the CData property of the
> existing image. This is faster than deleting the old image and creating
> a new one. In general, if you have an existing object (image, surface,
> line plot) and you want to replace it with another item of the same
> variety, then it is more efficient to change the properties of the
> existing object than to create a new one.
>
> > Finally, regarding your last comment, where might I read about Hittest,
> > and the use of a ButtonPressCallbackFcn?
>
> The following describes it better:
> http://www.mathworks.com/support/solutions/en/data/1-1B03X/?solution=1-1B03X
>
> I see that images do have a ButtonDownFcn callback:
>
> http://www.mathworks.com/access/helpdesk/help/techdoc/ref/image_props.html
>
> Not sure where I came up with the name ButtonPressFcnCallback :(

This will all be very useful. I'm away from my code right now, or else I'd be trying these things out right now.
Once again, thanks! I'll let you know how it all goes.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11
Prev: mbuild -setup doesn't see my compiler
Next: Using imcontrast