hobject issue with function

Hello, I have a function (localThresholdnTiles) that I call in which I pass an image and the number of tiles I want to subdivide the image upto to perform my own binarize function on. When I run the contents of the function below under a pushbutton callback (using GUIDE), it all works fine.

However, when I call the fucntion from a pushbutton callback e.g

centroids=localThresholdnTiles(handles,4, 4, IM)    %(Im has already been defined)

I get the error message.

BLOCKPROC encountered an error while evaluating the user-supplied function handle, FUN.

The cause of the error was:

Undefined function or variable 'hObject'.

function [centroids]=localThresholdnTiles(handles,xtiles, ytiles, image)
%local thresholding - splits image up into xtiles by y tiles

Image=double(image);          %Force image to double precision
[rows,cols]=size(Image);

% Number of tiles or chunks you want it divide up into. (xtiles, ytiles)  
nx=floor(cols/xtiles);    ny=floor(rows/ytiles);     %Numbers pixels per tile to maintain integer number of tiles
figure
imshow(Image)

%Use blockproc ro run "myOperation" on each tile.
Binary1=blockproc(Image,[nx, ny],@(x) myOperation(hObject, eventdata, handles, x.data))

[Rik]

I don't see why this function would work as a callback. Callback functions have a syntax like this:

function SomeCallback(hObject,EventData)

Any other input is generally obtained by using handles=guidata(hObject). This function might work as a nested function, but I don't expect it to work as a Callback.

[Jason]

Hi Rik, using GUIDE, whenever you create a push button, the code it executes is in the format below. Its under the pushbutton code I want to execute my function

centroids=localThresholdnTiles(handles,4, 4, IM).

I include handles as I want to have access to components on my gui

function pushbutton_Callback(hObject, eventdata, handles)

But it seems when I nest Blocproc this way it doesn't like it.

[Rik]

I know what GUIDE does. It creates that by doing this:

CallbackFunction=@(hObject,EventData) ActualFunction(hObject,EventData,guidata(hObject));

What input does your myOperation function require? Does it actually need the handles struct?

Also, I stand by my suspicion that this wouldn't run correctly as a callback the way you posted the function until I see any evidence otherwise.

[Jason]

Heres my full code under the pushbutton callback:

function pushbuttonFindSpots_Callback(hObject, eventdata, handles)
 IM=getimage(handles.axes4);    %get image from axes component
 IM=IM-min(IM(:));               %Background subtract
 
 %Run my binarise image using blockproc to perform local thresholding for binarisation
 centroids=localThresholdnTiles(handles,4, 4, IM)  

Where

 function [centroids]=localThresholdnTiles(handles,xtiles, ytiles, image)
 %local thresholding - splits image up into xtiles by y tiles

 Image=double(image);          %Get Image
 [rows,cols]=size(Image);

 % Number of tiles or chunks you want it divide up into. (xtiles, ytiles)  
 nx=floor(cols/xtiles);    ny=floor(rows/ytiles);     %Numbers pixels per tile to maintain integer number of tiles
 Binary1=blockproc(Image,[nx, ny],@(x) myOperation(handles, x.data))
 regmax = imregionalmax(Binary1);
 s = regionprops(regmax,double(Image), 'WeightedCentroid','Area');
 centroids = cat(1, s.WeightedCentroid);
 areas=cat(1,s.Area)
 centroids(:,3)=areas;

and the binarise function in blockproc is

function [ix]=myOperation(handles, tile)
      %Create Binary Image
      f=str2double(get(handles.editThreshn,'String'));
      level=mean(tile(:))+f*std(tile(:));  
      ix=tile;
      ix(ix<level)=0;
      ix(ix>level)=1;          %ix is now a binary image

I have taken out the hobject and eventdata from blockproc and it works.

[Adam]

The original error was simply exactly what the message said - hObject does not exist in the context in which you referred to it. Irrespective of any callback semantics that is just standard function scoping of variables. If they don't exist in the function scope then they can't be used.

I would strongly advise against passing 'handles' around to external functions in general though. It makes no sense for the function to be external, for a start, if one of its arguments is a christmas tree struct full of goodness knows what fields that it doesn't need.

Either keep the function within your GUIDE file (where passing the figure handle to callbacks is usually safer than defining the callback with 'handles') or keep it external, but remove 'handles' and replace it with whatever is actually needed by the function rather than an entire struct full of GUI components.

[Jason]

Hi Adam, thanks for your comments. So are you saying its better not to do this:

function [ix]=myOperation(handles, tile)
      %Create Binary Image
      f=str2double(get(handles.editThreshn,'String'));
      level=mean(tile(:))+f*std(tile(:));  
      ix=tile;
      ix(ix<level)=0;
      ix(ix>level)=1;          %ix is now a binary image

but instead do this:

function [ix]=myOperation(handles,f, tile)
      %Create Binary Image
            level=mean(tile(:))+f*std(tile(:));  
      ix=tile;
      ix(ix<level)=0;
      ix(ix>level)=1;          %ix is now a binary image

      %where f is defined outside the function via
      %f=str2double(get(handles.editThreshn,'String'));

[Jason]

Just to add, I often have several GUI compoents that I need to be inputted into a fucntion. The function could be called many times. This means I will have a lot of pre-assigning to do before each time it is called which is why I tended to include handles inside my finctions:

e.g. theres 3 componets I need to access in this fucntion popupmenu14, axes4 and checkbox22. Surely having all this outside the function is messy?

Thanks for any comments

Jason

removeLines(handles);            
contents=get(handles.popupmenu14,'String');
str=contents{get(handles.popupmenu14,'Value')};   %Select which spot finding method to use

IM=getimage(handles.axes4);
[rows,cols]=size(IM);
IM=IM-min(IM(:));  %Background subtract

val=get(handles.checkbox22,'Value');  %see if median filter required
if val==1
   IM=medfilt2(IM, [3 3]);
end  

[Rik]

Almost. Since you don't need the handles struct, you don't need to input it anyway:

function [ix]=myOperation(f, tile)
      %Create Binary Image
      level=mean(tile(:))+f*std(tile(:));  
      ix=tile;
      ix(ix<level)=0;
      ix(ix>level)=1;          %ix is now a binary image
      %where f is defined outside the function via
      %f=str2double(get(handles.editThreshn,'String'));

[Adam]

I assume in your example of the previous comment you intended to remove 'handles' as an argument to the function when you added 'f'?

How you design something depends on how reusable you want it to be, how robust, how fussy you want to be and a whole raft of other things. There's no one right answer (though plenty of wrong answers as well as multiple 'right' answers!) to how to design something.

If I am running an algorithm that may be run multiple times though I usually like it to be as general as possible in its usage - e.g. I would want to be able to call it from the command line with hard-coded inputs for paramaters (or inputs taken from variables in the current workspace similarly) .

In your latter case you limit your function's usefulness by making it so tightly coupled to your UI that it makes no sense for it to be external because anything that uses it would have to pass in a struct that contains fields 'popupmenu14', 'axes4' and 'checkbox22' that are of the correct type.

Instead passing in contents, hAxes (a handle to your axes) and val would make the function much more general purpose as these can now be gathered from anywhere by the calling code. Even better would probably be to pass in IM rather than hAxes since that is all you use the axes for. They can be passed in from existing variables or from this same GUI or from a totally different GUI that you may design. Also if you write tests for your algorithm then these tests can create data that can be used as inputs which cannot be done if it is required to be this big handles struct.

It is analagous to tight coupling vs loose coupling when doing object-oriented programming. Factoring algorithms out into separate functions is good, but if their inputs are so tightly linked to the UI that you factored them out from then all you have really done is make your original function look shorter by moving some code out that still cannot be used from any other place.

[Jason]

I assume in your example of the previous comment you intended to remove 'handles' as an argument to the function when you added 'f'? yes thats correct.

Many thanks for your and everyone elses comments.

I wish I could accept more than one answer. Adam has been very informative about my style but it was Rik who originally asked about the handles argument and if it was needed which led me to remove it and see my code work. (Sorry Adam)

Actually, I cannot see the "Accept this answer" for Rik?

Jason

Answer 1

[Rik]

I'll post it as an answer so you can accept it.

The root cause of your problem is that your call in blocproc assumed that a handles variable would exist. Since that is neither the case nor needed, the functions can be modified to skip it. (I would also suggest changing your function name to something that describes its purpose, like ConvertToBinaryDouble)

 function [centroids]=localThresholdnTiles(handles,xtiles, ytiles, image)
 %local thresholding - splits image up into xtiles by y tiles
 Image=double(image);          %Get Image
 [rows,cols]=size(Image);
 % Number of tiles or chunks you want it divide up into. (xtiles, ytiles)  
 nx=floor(cols/xtiles);    ny=floor(rows/ytiles);     %Numbers pixels per tile to maintain integer number of tiles
 Binary1=blockproc(Image,[nx, ny],@(x) myOperation(str2double(get(handles.editThreshn,'String')), x.data))
 regmax = imregionalmax(Binary1);
 s = regionprops(regmax,double(Image), 'WeightedCentroid','Area');
 centroids = cat(1, s.WeightedCentroid);
 areas=cat(1,s.Area)
 centroids(:,3)=areas;
 end
 
 function [ix]=myOperation(f, tile)
      %Create Binary Image
      level=mean(tile(:))+f*std(tile(:));  
      ix=tile;
      ix(ix<level)=0;
      ix(ix>level)=1;          %ix is now a binary image
      %where f is defined outside the function via
      %f=str2double(get(handles.editThreshn,'String'));
 end