GUI - Add ticks to slider bars and add hue color space to slider bars

I am doing an image processing project for myself to seperate fruits from the background by using a range of the hue value and the saturation value. I have implemented four sliders - one for the lower limit and one for the upper limit for both hue and saturation. However, I want to add two things to these sliders, namely firstly add ticks to the sliderbars, so that it is more user-friendly. Moreover, I want to add behind the sliderbars for the hue, the hue color space. How can I implement these two things?

This is how it so far looks like:

Example of a slidebar with ticks:

Below the most important part of the code for the hue bars:

h=struct; %Create structure to put all handles and data in 

h.hImage = hImage;
h.RGB_Image_Re = RGB_Image_Re;
h.f = figure(1);
set(gcf, 'Position',[450, 150, 800, 550]); %[450, 300, 800, 400])
h.ax = axes('Parent',h.f,'units','pixels','position',[120 290 290 215]);
h.h_im = imshow(h.RGB_Image_Re,'Parent',h.ax);
title(h.ax,'Initial color seperation: fruit');

h.ax2 = axes('Parent',h.f,'units','pixels','position',[450 290 290 215]);
h.h_im2 = imshow(h.RGB_Image_Re,'Parent',h.ax2);
title(h.ax2,'Initial color seperation: leaves, sky and logs');

%% Hue
%Initial values
Hue_min = 0;
Hue_max = 1;

%Slider for the lower limit of hue 
h.min_Slider = uicontrol('Parent',h.f,'Style','slider', ... % Create user interface control
    'Units','Pixels','Position',[221,260,419,23],...
    'value', Hue_min, 'min',0, 'max',1,...
    'Callback', @Slider);

% Label lower limit of slider
bl1 = uicontrol('Parent',h.f,'Style','text','Position',[190,255,23,23],...
                'String','0');
bl2 = uicontrol('Parent',h.f,'Style','text','Position',[640,255,23,23],...
                'String','1');
bl3 = uicontrol('Parent',h.f,'Style','text','Position',[340,225,100,23],...
                'String','Lower limit hue:');

%Slider for the upper limit of hue 
h.max_Slider = uicontrol('Parent',h.f,'Style','slider',... % Create user interface control
    'Units','Pixels','Position',[221,195,419,23],...
    'value', Hue_max, 'min',0, 'max',1,...
    'Callback', @Slider);

% Label upper limit of slider
bu1 = uicontrol('Parent',h.f,'Style','text','Position',[190,195,23,23],...
                'String','0');
bu2 = uicontrol('Parent',h.f,'Style','text','Position',[640,195,23,23],...
                'String','1');
bu3 = uicontrol('Parent',h.f,'Style','text','Position',[340,165,100,23],...
                'String','Upper limit hue:');

%% Callback
function Slider(hObj,~) 
h =             guidata(hObj);            
Hue_min =       round(h.min_Slider.Value,3);
Hue_max =       round(h.max_Slider.Value,3);

Current_Hue_min = uicontrol('Style', 'text',...
                               'Parent', h.f, ...              
                               'Position', [450,225,50,23],	...
                               'String', Hue_min);
                                                
Current_Hue_max = uicontrol('Style', 'text', ...
                               'Parent', h.f, ...             
                               'Position', [450,165,50,23],	...
                               'String', Hue_max);
                        

end

[Adam Danz]

Why not just use a slider (as you show in the second image)? That would solve the first problem.

https://www.mathworks.com/help/matlab/creating_guis/choose-components-for-your-app-designer-app.html?

[yanqi liu]

yes，sir，as Adam Danz said，use app designer or gui designer can get better process

[S.]

@Adam Danz How can I exactly change the uicontrol() function to the uislider() function to create the sliders? I create now h.min_Slider and the other sliders in that way.

I tried this:

h.min_Slider = uislider('Parent',h.f,'Limits', [0, 360], 'ValueChangedFcn', @Slider);

However, this is not supported with figures created by the figure function, which I am doing now. How should I change this? And how can I indicate that the limits indicated in the 'Limits' property has to do with the hue value? I don't know if I am missing something else to let it work.

[S.]

@yanqi liu if I use app desginer or gui designer I will not exactly know what the code is what will be produced, thats why I want to hard code it. Moreover, I already put a lot of effort now in it, so it would be hard to start over again for two small changes.

[DGM]

I'm not sure what changes would be required when adapting from a figure() based GUI to one built on uifigure(). I don't think you would need to deal with appdesigner, but it might take a bunch of work to replace all the controls.

Unless there are undocumented methods, uicontrol() sliders don't have ticks or tick labels. You can set the 'sliderstep' property, but that only affects the behavior when clicking on the buttons or in the gutter. It doesn't snap the slider when dragging the handle.

If an indicator of scale might suffice, you could create a set of small text objects below the slider. It'll probably be tedious to set up, but it's better than nothing. Just having values at the ends might be a start.

If you want to show a hue/saturation sweep, I'm not sure of the best way to pull that off. You can't do it in the slider gutter, and afaik, you can't make the gutter transparent such as would allow you to stack the slider on top of some sort of image object.

Lemme think about that.

[Adam Danz]

Well, you would need to redesign your app using the app designer framework (not necessarily using AppDesigner) within a uifigure to use the uislider.

Adding ticks to the uicontrol slider is a challange and would require centering an axes around the slider and then scaling the axis ticks so they center around the slider bar extents. I wouldn't waste time on that.

Instead, you could add a text box beside each slider that shows the slider's current value which would be updated by a slider callback function.

[Adam Danz]

Here's a quick demo. The text box updates when the slider reaches a new value.

fig = figure();

uip = uipanel(fig, 'Units','Normalized',...
    'Position', [0.15, 0.15, 0.7, 0.18]);

initialValue = 0.2;

uitxbox = uicontrol(uip,'Style','edit',...
    'String', sprintf('%.2f',initialValue), ...
    'Units','Normalized',...
    'Position', [0.1, 0.3, 0.1, 0.4]);

uislide = uicontrol(uip, 'Style', 'Slider', ...
    'Units','Normalized', ...
    'Position', [0.3, 0.3, 0.6, 0.4], ...
    'Min', 0, 'Max', 1, 'Value', initialValue, ...
    'Callback', @(h,~)set(uitxbox, 'String', sprintf('%.2f',h.Value)));

Answer 1

[DGM]

Attached is a script that creates a GUI with three HSV sliders and a basic CBF template. The sliders have tick labels, but no tick marks. Above each slider is a dynamic gradient. Grab a slider and you'll see the new HSV tuple dumped to console as it's updated.

This is a bit of a kludge, but it should at least demonstrate that some things are possible with regular figure() GUIs and uicontrol() objects.

[Adam Danz]

+1 @DGM

@S. to scale the color bands above the sliders so they terminate at the edges of the slider space rather than extending above the < > arrows where the slider cannot reach, you can either adjust the position or perhaps you can add dummy colors to the beginning and end that match the panel background. The first proposal is probably safer through if the slider is resized, it may be tricky to keep the color bands aligned with the inner slide area. In any case, bravo to DGM for doing the heavy lifting!

[DGM]

Here. I used the same margin parameter that's used to offset the ticks. That way the end of the colorbars should follow the centers of the end ticks. Everything is proportional though, so it doesn't always land exactly in the center of the handle if you resize the window to the extreme. It's better than before though.

Your idea of underlaying an axes object and using its ticks might have been a simpler approach, and it would allow the use of tick marks. If anything, this example could be modified by changing the geometry of the axes objects and changing the stacking order.

[Adam Danz]

Looks good! Looks like something for the file exchange!

[DGM]

I thought about it. Then I thought "but I avoid HSV like the plague; maybe I should make it work in a vast assortment of color models". Then I realized that I was going down that rabbit hole again and stopped.

Jokes aside, it kind of does need edit boxes and channel labels.

What might be better than scaling the colorbars to fit the limits of the handle travel might be to draw indicator lines in the axes themselves to show exactly where the selected color is.

[Adam Danz]

The indicator lines sound like a good idea and it's getting closer to the uislider available in the app designer framework. It also sounds like a lot of work but useful work.

[S.]

@DGM @Adam Danz Thanks, I will check both solutions out, think about it, and let you know if something is unclear.

@Adam Danz I already display the current values, but it is a good idea to put the current values in a checkbox for clarity.

Another small question, which I am struggling with now. I am trying to add a pushbutton to upload a new image in order to check the ranges of hue and saturation for multiple pictures in an easily way to set reasonable, soft ranges.

I have added the following to the function (this seems fine).

function [] = myGUI(hImage, sImage, RGB_Image_Re)
...
    PushButton = uicontrol(gcf,'Style', 'pushbutton', ...
    'String', 'Upload picture', ...
    'Position', [325,15,200,23], ...
    'Callback', @Pushbutton);
end

However, here is where I get stuck. The newly uploaded image after pushing the button should get some pre-processing in the main script, thats why you also see hImage, sImage, RGB_Image_Re as inputs in the function myGUI(...). Now it doesn't get these and I get the error ''Invalid or deleted object". Maybe it is possible to define at the start of the main script where you read in the image the pushbutton in some way? I want to do it in the most computationally efficient way that's why in first instance I did the pre-processing steps outside the function myGUI(...). Hope the story is clear.

function Pushbutton(hObj,~)
h = guidata(hObj); 

[FileName, PathName] = uigetfile({'*.JPG'});
axes(h.ax)
h.RGB_Image = imshow([PathName, FileName]);
axes(h.ax2)
h.RGB_Image = imshow([PathName, FileName]);
end

[Adam Danz]

😬

Problems.

1. It's rarely a good idea to use gcf in a function. Use the figure handle in myGUI().
2. guidata isn't doing what it appears you intended it to do. hObj is the pushbutton handle and h is empty - that's something you could see in debug mode. It looks like you want to pass in a strcture or object containing graphics handles for ax and ax2. If so, define the callback function in myGUI as 'callback',{@Pushbutton, h} where h is the structure/object. Then add the 3rd input to function Pushbutton(hObj,~,h) and get rid of the incorrectly used guidata.
3. Instead of making axes current prior to calling imshow, just use the axes handles, imshow(___,'Parent',h.ax)

Since this is quite off topic of the thread, please ask additional questions on this matter in a new thread.

[S.]

Ok! I will make a new thread! I have some follow-up questions.

p.s. If I use the figure handle, I assume you mean with that the beneath line of code, in myGUI() and run the script, the window explorer immedatialy opens and that is not a thing I want. It should open after clicking the pushbutton.

[FileName, PathName] = uigetfile({'*.JPG'});

[Adam Danz]

The figure handle comment refers to this line of code

PushButton = uicontrol(gcf,'Style', 'pushbutton', ...

where you should replace gcf with the figure handle.

[S.]

Ok clear! Only some problems with saving the figures using a pushbutton, but I opened another thread...

[S.]

@DGM I am trying to implement the ticks in my own GUI, but some things are not clear, because my slider bar has a different normalized position, namely: [0.25,0.45,0.5,0.04].

What is the abbrevation for the vector Plbl in your code stands for: Plbl = [0 Pslid(2)-0.025 0.05 0.025];?

The same holds for xpos, there seems to be a reasoning behind the formula, which I follow quite good, only I don't understand where Plbl(3)/2 comes from.

xpos = (lblmargin + (k-1)*(Pslid(3) - 2*lblmargin)/(nticks-1)) - Plbl(3)/2;
Plbl(1) = 0.125 + xpos;

Moreover, you set lblmargin to 0.055, but again how did you set this value. Lastly, you mention that lblmargin is the margin between LH ticklabel and LH corner of slider. What does LH stand for?

Lastly, within uicontrol you have

'Tag','slidicklabel'

However, if you remove this, I don't see any changes, so what is the function of it?

[DGM]

Plbl : Position of label

Plbl(1) is initially left zero since it will be incrementally calclulated within the loop anyway

Plbl(2) is just vertically offset from the prior object

Inside the loop, xpos is the base value of the calculated label x-offset with respect to the left-hand edge of the slider.

Breaking down this line:

xpos = (lblmargin + (k-1)*(Pslid(3) - 2*lblmargin)/(nticks-1)) - Plbl(3)/2;

We start at the left-hand edge of the slider, offset right by lblmargin and then by an integer multiple of the distance between labels. Finally, offset left by half the width of the label, so that everything is aligned to the label centers instead of the edge.

The horizontal margins around the slider are 0.125. This is the same value used to shift xpos in the line:

Plbl(1) = 0.125 + xpos;

I could've probably written that in a more obvious form, but I was in a hurry.

I picked lblmargin just by trial and error. The value of lblmargin is essentially the width of the slider arrow button plus half the width of the slider handle. I don't know if that can reliably be calculated from the slider properties. I don't think that it can.

LH: left-hand

The tag property of the slider tick label (and other objects) is the name given to the object handle in the handles struct. Since it's not adjusted anywhere after the fact, it doesn't really matter, but I think it's good practice to at least make sure everything in the handles struct is named. That way any time they need to be read or written elsewhere in the code, it's reasonably clear which object is being accessed. I'm sure there are other ways, but that's how I tend to do it.

As an example of why you might need to change the labels programmatically, consider the case if you wanted to make the code support models other than HSV.

[S.]

It's completely clear! I am now implementing the color bar, only for the hue value (and maybe the saturation afterwards) and it is not necessary that it changes the color if you change the saturation. It is even not possible to change the color, as I have a slider for the lower bound and upper bound (i.e. a range) for both the hue and saturation, which makes it impossible. So only an image of the colorbars above the sliders is enough. If you can explain a bit what you did there, that would be nice.

Here are already some questions:

How did you define the values for cboxsize? It's not really clear to me.

What does the following line of code do? In my code I defined the position of the sliders in uicontrol and not in a seperate axes(). How can I change it to my code? Moreover, what you are doing at aximg and how did you define the values of the vector: [1 3 2]?

hax = handles.axes1(c);
aximg = repmat(permute(tp,[1 3 2]),cboxsize);

[DGM]

The parameter cboxsize specifies the size of the colorbar image. The colorbar image will be scaled to fit the axes object regardless of cboxsize, but cboxsize determines how the colors are quantized. Since the image is 32px wide, there will be 32 color steps. You could make this coarser or finer. The height of the image doesn't need to be 5. The image is invariant along its height, so it doesn't really matter. You could make it 2 or 1.

When starting the update function, the test point is a 1x3 HSV tuple where H is in degrees. Since hsv2rgb() expects normalized inputs, the first step is to create a normalized copy.

tp = testpoint./axrange(:,2)'; % normalize

One by one, each of the three axes objects are selected

for c = 1:3
    hax = handles.axes1(c);

This colorbar image is generated by permuting the test point tuple from 1x3 to 1x1x3 so that it forms a single-pixel HSV image. It is subsequently replicated to the geometry specified in cboxsize. The result is a 5x32 uniform-color image.

    % create image and update
    aximg = repmat(permute(tp,[1 3 2]),cboxsize);

In order to convert the uniform color to a sweep, one channel (the channel which this colorbar represents) is replaced by a simple unit-ramp.

    aximg(:,:,c) = repmat(linspace(0,1,cboxsize(2)),cboxsize(1),1);

Then the image is converted to RGB and displayed in the current axes. The 'axis off' gets rid of the box and ticks around the colorbar.

    aximg = hsv2rgb(aximg);
    image(hax,aximg);
    axis(hax,'off');
end

You could choose to make the colorbars static if you want. You'd have to pick some starting color tuple that you like and then just construct the bars once during figure setup. All that would be needed is to simply not call updatecolorbars() during the slider callback.

[S.]

It's again quite clear. I have some small follow-up questions to visualize it better for myself:

So in the below line the single-pixel HSV is created. Do you mean with this just one specific hue color from the testpoint (in this case hue is taken as example) and that this is duplicated 35 times?

aximg = repmat(permute(tp,[1 3 2]),cboxsize);

And that in the next step the hue value (for example) is linearly divided in 35 values between 0 and 1?

aximg(:,:,1) = repmat(linspace(0,1,cboxsize(2)),cboxsize(1),1);

[DGM]

Yeah, basically.

tp = [0.25 1 0.5];
cboxsize = [2 8];

aximg = repmat(permute(tp,[1 3 2]),cboxsize)

aximg = 
aximg(:,:,1) =

    0.2500    0.2500    0.2500    0.2500    0.2500    0.2500    0.2500    0.2500
    0.2500    0.2500    0.2500    0.2500    0.2500    0.2500    0.2500    0.2500


aximg(:,:,2) =

     1     1     1     1     1     1     1     1
     1     1     1     1     1     1     1     1


aximg(:,:,3) =

    0.5000    0.5000    0.5000    0.5000    0.5000    0.5000    0.5000    0.5000
    0.5000    0.5000    0.5000    0.5000    0.5000    0.5000    0.5000    0.5000

aximg(:,:,1) = repmat(linspace(0,1,cboxsize(2)),cboxsize(1),1)

aximg = 
aximg(:,:,1) =

         0    0.1429    0.2857    0.4286    0.5714    0.7143    0.8571    1.0000
         0    0.1429    0.2857    0.4286    0.5714    0.7143    0.8571    1.0000


aximg(:,:,2) =

     1     1     1     1     1     1     1     1
     1     1     1     1     1     1     1     1


aximg(:,:,3) =

    0.5000    0.5000    0.5000    0.5000    0.5000    0.5000    0.5000    0.5000
    0.5000    0.5000    0.5000    0.5000    0.5000    0.5000    0.5000    0.5000

[S.]

Clear! Maybe you have a proper answer on my other topic aswell on saving the subplots seperately as .jpg with a save button: link to save button topic (if you have time of course).

[S.]

One very last small confusion;

You mentioned on 4th March:

guidata isn't doing what it appears you intended it to do. hObj is the pushbutton handle and h is empty - that's something you could see in debug mode. It looks like you want to pass in a strcture or object containing graphics handles for ax and ax2. If so, define the callback function in myGUI as 'callback',{@Pushbutton, h} where h is the structure/object. Then add the 3rd input to function Pushbutton(hObj,~,h) and get rid of the incorrectly used guidata.

------

My confusion:

If I use function Pushbutton(hObj,~,h) with h as an third input, hObj is redundant and can be replaced by ~, so function Pushbutton(~,~,h), if I am correctly?

However, if I define the callback function in myGUI as 'callback', @Pushbutton, the function Pushbutton(hObj,~) and h = guidata(hObj) within that function, the result is the same.

Therefore, what's the difference between both ways (if there is a difference) and which one might be faster? And can yo usu for other UI components hObj (i.e. a different name is not necessary as the function refers to the correct handle, for example function Slider(hObj,~) and function SaveButton(hObj,~), hObj refers to the slider handle in the Slider(hObj,~) function and to the save button handle in the SaveButton(hObj,~)).

[DGM]

Bear in mind that I'm not exactly an authority on best practices here, so take my recommendations with a grain of salt.

In the case of function Pushbutton(hObj,~,h), hObj is the handle to the button object, and h is the handles struct. So they're not really redundant, but it's true that you don't need hObj within the scope of the CBF, so you can omit it with a tilde.

In the case where the CBF has no additional parameter, you can still fetch the handles struct like you show since it's stored in the figure object. I guess that guidata() doesn't care whether it's fed a figure handle or the handle of a descendant object. To me, that seems really confusing, but maybe I guess it's a convenience.

As to what's fastest, I don't know. I'm not really sure how I'd go about testing the response time to a GUI control interaction. I imagine most people would suggest to use guidata() as in the second example. It's just not the way I'm used to doing it.

Within the scope of each CBF, you can call hObj whatever you want. Those variables only exist within the scope of the respective function, so they don't conflict even if they're all named the same.

[S.]

So if you mention in the general function: guidata(h.f, h), with h.f the parent figure and h the structure with data and inside the callback function function Pushbutton(hObj, ~), h = guidata(h0bj) then you feed the handle of the button object, but it retrieves the data of the parent figure and therefore the structure h, if I understand it correctly.

[DGM]

I think that's the behavior I'm seeing.