I have tried researching (google, FEX, and help) what window/level tools are available in/for Matlab. However, sadly, the only window/level tool I found was the one integrated into imtool and also imcontrast. These can't possibly be the only place in matlab where one can easily implement interactive window/level functionality? What if someone would want to use this functionality without invoking imtool or imcontrast?
Eric Diaz
Any knowledge regarding this topic would be appreciated, thanks in advance.
ImageAnalyst <imagea...@mailinator.com> wrote in message <3a249b1d-fc08-4cac...@k19g2000yqm.googlegroups.com>...
Thanks in advance,
Eric Diaz
yes... fully agree...
now, just so CSSMers get your record:
what have YOU done so far to solve YOUR particular problem...
us
To be quite honest, I am just so frustrated with TMW for not providing such a simple tool (eventhough it is incorporated into imtool and imcontrast) that I didn't bother trying to recreate the wheel. I have other more important things to do that build a window/level tool, or try and figure out how to copy the essential code from Matlab's imtool/imcontrast .m files. So, I submitted an enhancement request to TMW because it is just retarded that this function is not available.
I'm surprised nobody has posted a FEX file on the topic nor anyone in the community has the desire to contribute ideas (other than ImageAnalyst and his "extremely informative" suggestion).
So, there ya' have it.
"us " <u...@neurol.unizh.ch> wrote in message <hsfk9p$pc$1...@fred.mathworks.com>...
Which kind of computer work is it that you do, where the existence of
"window/level" tools is fundamental and pervasive enough that people
could be assumed to have a solid grasp of what they are?
> What if someone would want to use this functionality without invoking
> imtool or imcontrast?
I don't know yet *what* functionality that is, but is there a particular
_reason_ that imtool and imcontrast must be avoided? Some constraint
that you are under? E.g., are you needing something that will work in a
standalone GUI and there is some reason imtool and imcontrast are not
compliable?
"In medical imaging the brightness/contrast control is called the "window/level" control, and there is a reasonably standard set of mouse motions for changing the window and level. These mouse motions are supported by imtool [imcontrast]".
ref: http://blogs.mathworks.com/steve/2006/02/17/all-about-pixel-colors-window-level/
"Using the Window/Level tool, you can change the contrast and brightness of an image by simply dragging the mouse over the image. Moving the mouse horizontally affects contrast; moving the mouse vertically affects brightness. Note that any contrast adjustments you make using the Window/Level tool are reflected immediately in the Adjust Contrast tool. For example, if you increase the brightness, the window in the Adjust Contrast moves over the histogram. "
ref: http://www.mathworks.com/access/helpdesk/help/toolbox/images/f10-44495.html
Apparently TMW knows all about this function but just hasn't implemented it in a more user friendly manner.
> I don't know yet *what* functionality that is, but is there a particular
> _reason_ that imtool and imcontrast must be avoided? Some constraint
> that you are under? E.g., are you needing something that will work in a
> standalone GUI and there is some reason imtool and imcontrast are not
> compliable?
I just don't want to have to use imtool or imcontrast. Personally, I like to use imagesc (not imtool), and I don't want to have to go to the command line to type an extra command "imcontrast" to accomplish what I could accomplish with a flick of the mouse. This function is simple and useful enough that it should be easily implementable in any figure via the toolbar, for example; it has nothing to do with noncompliance of these tools nor standalone guis. I should be able to do this in any figure window.
> I just don't want to have to use imtool or imcontrast. Personally, I
> like to use imagesc (not imtool), and I don't want to have to go to the
> command line to type an extra command "imcontrast" to accomplish what I
> could accomplish with a flick of the mouse. This function is simple and
> useful enough that it should be easily implementable in any figure via
> the toolbar, for example; it has nothing to do with noncompliance of
> these tools nor standalone guis. I should be able to do this in any
> figure window.
Are you aware that you can set the root property DefaultFigureCreateFcn
and that the function you nominate there can add arbitrary toolbar
entries using uipushtool ?
> "In medical imaging the brightness/contrast control is called the
> "window/level" control, and there is a reasonably standard set of
> mouse motions for changing the window and level.
Interestingly, I have never encountered this term before, even though we
do a fair bit of medical imaging work. We do, though, tend to build our
own imaging tools, and the work I do tends to be more on MRS or on
features already extracted from images (MRI, infra red)
> Are you aware that you can set the root property DefaultFigureCreateFcn
> and that the function you nominate there can add arbitrary toolbar
> entries using uipushtool ?
>
I was not aware of that. I will look into that. hmmm...when I type in inspect(0), I don't see a DefaultFigureCreateFcn property. That's odd. I suppose it is just the same as the CreateFcn. Do you mean that the nominated function should be a uipushtool pushbutton?
> Interestingly, I have never encountered this term before, even though we
> do a fair bit of medical imaging work. We do, though, tend to build our
> own imaging tools, and the work I do tends to be more on MRS or on
> features already extracted from images (MRI, infra red)
That is interesting. Perhaps the vernacular isn't as common in all fields, however it is the vernacular of medical imagers. I suppose you would not need it for MRS (I assume you mean MR spectroscopy). Not sure what you mean by features already extracted...
Thanks for the tips.
That naming convention indicates that it's not a property of the root object
itself but the syntax to set the default value all figures that are children
of root (i.e. all of them) should use for their CreateFcn property when they
are created. That syntax is described in this section of the documentation:
http://www.mathworks.com/access/helpdesk/help/techdoc/creating_plots/f7-21465.html
--
Steve Lord
sl...@mathworks.com
comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ
a hint:
- to look at all/defined settings, use these
get(0,'factory')
get(0,'default')
us
>> Are you aware that you can set the root property
>> DefaultFigureCreateFcn and that the function you nominate there can
>> add arbitrary toolbar entries using uipushtool ?
> I was not aware of that. I will look into that. hmmm...when I type in
> inspect(0), I don't see a DefaultFigureCreateFcn property. That's odd.
> I suppose it is just the same as the CreateFcn.
Sorry, lost track of this conversation when I moved between home and work.
Steve appears to have pointed you to the correct section of the documentation
for this functionality.
You can see the default properties that have been changed by using
get(0,'Default')
and you can see the factory defaults figure properties via
get(0,'FactoryFigure')
> Do you mean that the
> nominated function should be a uipushtool pushbutton?
There are two functions involved here, and I am not sure which of the two you
mean by 'nominated'. The first function is the one you would code as
'DefaultFigureCreateFcn'; that function I would have call uipushtool() in
order to add a reference to the second function as a figure pushbutton .
The second function involved is the one that would actually get invoked when
the button is pushed, and it would invoke the window/leveler functionality.
For example, instead of having to type imcontrast at the command window, the
second function could invoke imcontrast on your behalf, done via a mouse movement.
It might possibly be as simple as coding the uipushtool pushbutton callback as
{@(src,event) imcontrast(src)}
>> Interestingly, I have never encountered this term before, even though
>> we do a fair bit of medical imaging work. We do, though, tend to build
>> our own imaging tools, and the work I do tends to be more on MRS or on
>> features already extracted from images (MRI, infra red)
> That is interesting. Perhaps the vernacular isn't as common in all
> fields, however it is the vernacular of medical imagers. I suppose you
> would not need it for MRS (I assume you mean MR spectroscopy). Not sure
> what you mean by features already extracted...
Yes, MRS is MR Spectroscopy.
When I refer to working on "features already extract from images", what I mean
is most of the projects I have worked on do not use raw medical images, but
instead work on information that someone else (using some other tool) has
extracted from images. When we do work with images it is commonly a time
course, and we internally treat the data as multidimensional points with each
pixel corresponding to one feature. Our tools are not sensitive to scaling and
translation -- provided, of course, that reasonable precision is maintained.
Our tools do have problems if you do the equivalent of setting the contrast to
the maximum or minimum ;-)
Thanks for the tips on the create Fcn. I'll check these out.
Dear Walter,
> There are two functions involved here, and I am not sure which of the two you
> mean by 'nominated'. The first function is the one you would code as
> 'DefaultFigureCreateFcn'; that function I would have call uipushtool() in
> order to add a reference to the second function as a figure pushbutton .
>
> The second function involved is the one that would actually get invoked when
> the button is pushed, and it would invoke the window/leveler functionality.
> For example, instead of having to type imcontrast at the command window, the
> second function could invoke imcontrast on your behalf, done via a mouse movement.
>
> It might possibly be as simple as coding the uipushtool pushbutton callback as
> {@(src,event) imcontrast(src)}
>
Thanks, I'll look into this. It seems I was thinking the same thing but worded it rather poorly, since I haven't actually done it before (meaning changed default figure create fcns nor added pushbuttons to guis before)....
Fortunately, as TMW is generally quick about responding to suggestions for improvement, a technical support service request [THREAD ID: 1-CSP7JB] has already begun on this topic and I have pointed Manu Raghavan from TMW to this discussion, so that I don't have to repeat the ideas and what others have said on here. Hopefully, TMW can help get this squared away.
It may be simply a race between my frustration level and TMW's speed at solving the problem at this point, because I'll start to code if it takes too long. It's really upsetting that this feature isn't available, especially since imageJ has had it for a very long time (since 2002 at least) ref: http://rsbweb.nih.gov/ij/plugins/window-level.html. I have often wondered if I should just abandon Matlab for image processing since imageJ seems to be doing circles around Matlab's image processing toolbox.
> When I refer to working on "features already extract from images", what I mean
> is most of the projects I have worked on do not use raw medical images, but
> instead work on information that someone else (using some other tool) has
> extracted from images. When we do work with images it is commonly a time
> course, and we internally treat the data as multidimensional points with each
> pixel corresponding to one feature. Our tools are not sensitive to scaling and
> translation -- provided, of course, that reasonable precision is maintained.
> Our tools do have problems if you do the equivalent of setting the contrast to
> the maximum or minimum ;-)
Yes, well I would expect your tools not to be sensitive to scaling/translation of intensity but I am a bit surprised if you mean not sensitive to scaling/translation of geometry over a time course. Typically geometric insensitivity requires application of some sort of registration transform beforehand. Anyway, window/level functionality is more for easing eye-brain processing, not so much pixel feature computations.
Thanks for your input.
Best regards
/jonas
"Eric Diaz" wrote in message <hsiau3$6hk$1...@fred.mathworks.com>...