Problem with Imhist method

I have an image Zoom:

Zoom =

    326    313    269    237    255    329
    332    271    304    256    332    302
    330    320    265    215    274    316
    233    219    218    224    221    224
    260    224    203    226    193    210
    272    231    219    227    205    227

when I perform

figure
imhist(Zoom)

the histogram is defaulting in the x-axis to x10^4

So the histogram is just a spike.

why does it not autorange the x-axis, and how too?

thanks Jason

[Jason]

Just to add, I often use 12 bit images. Occasionally I will use the sum of 3, 12 bit images, so I need the capability to handle both. I would like to limit the number of bins to say 100, but have the x-axis represent the actual intensity, with the max of the x-axis being soemthing related to the max value of intensity in data set

Answer 1

[DGM]

I saw this last night and threw together a demo when I was making the demos for the webdocs. The majority of the work here was trying to not do it the easy way.

IPT imhist() is very limited in what it can do. Trying to make it do anything else is usually a waste of time. If you don't need the matching colorbar setup, it's a wheel that's actually easier to reinvent using basic histogram tools.

That said, I just updated MIMT imhistFB(). What used to be an incomplete replacement for the IPT counterpart now adds a bunch of extra functionality and avoids a handful of bugs otherwise present in imhist().

So let's say we have a uint12-scale image as represented in uint16. That's not unreasonable, though we have to accept that it is necessarily going to be improperly scaled for its class.

% we have some image which is properly-scaled for its class
inpict_u8 = imread('cameraman.tif');
N = 256; % imhist() default

% here, we're working in uint12-scale, but we don't have a uint12 numeric class
% so we have to create a mis-scaled image in something wide enough (e.g. uint16)
ir = [0 2^8-1];
or = [0 2^12-1];
scalefactor = diff(or)/diff(ir);
inpict_u12 = cast((double(inpict_u8) - ir(1))*scalefactor + or(1),'uint16');

% IPT imhist() needs images to be scaled properly for their class
% both axes limits and bin location get determined by class,
subplot(4,1,1)
imhist(inpict_u8,N) % works with uint8-scale uint8
title('IPT imhist() works with a properly-scaled image')

% so adjusting xlim alone isn't enough to fix imhist() when the image is mis-scaled
subplot(4,1,2)
kscale = 2^16/2^12; % interval scale factor (this cannot always be correct)
Nadjusted = N*kscale; % need to use more bins to have the same density
imhist(inpict_u12,Nadjusted) 
xlim(or) % need to reset the xlimits obviously
ylim(ylim().*[1 sqrt(kscale)]) % but we need to rescale ylimits too!
title('Trying to make IPT imhist() work with an improperly-scaled image')
% that's okay, but try it with small N and you'll find out how wrong the scaling factor gets.
% since N and Nadj must both be integers, it's not always possible to adjust N to compensate for scale.
% ... and the colorbar is still wrong.
himg = findobj(gcf,'type','image');
set(himg(1),'cdata',kscale*get(himg(1),'cdata')); % not quite, but close.
% this will need extra work in older versions.

% if you're going to just live without the colorbar,
% you could reinvent the wheel using histc()/histcounts() and stem().
% that would arguably be less work than trying to fix imhist().
subplot(4,1,3)
os = 0.5*diff(or)/(N-1);
breakpoints = linspace(or(1)-os,or(2)+os,N+1).';
centers = linspace(or(1),or(2),N).';
counts = histcounts(inpict_u12,breakpoints);
stem(centers,counts,'marker','none');
xlim(or);
ylim([0 2.5*sqrt(counts*counts.'/numel(counts))]); % this is why we had to rescale before
title('It''s easier to just use histcounts() and stem()')
	
% but i already did all that.
% MIMT imhistFB() has a bunch of extra functionality that imhist() doesn't.
% it does this sort of thing easily.
subplot(4,1,4)
imhistFB(inpict_u12,N,'range',or) % MIMT's imhist() replacement
title('But MIMT imhistFB() is easiest')

What if you were wanted to pull your hair out and deal with signed integers? While we all know that int16 is the only signed-integer numeric class that most IPT/base tools regard as "images", IPT imhist() does actually support int8/int32. While it's good to know we don't need it to hold int12, at least we have support for more width when needed. This broader class support is more typical among MIMT tools, imhistFB() included.

In either case, neither tool is going to know that the content of a mis-scaled image is intended to be 12b-scale. So if you cram int12 into int16, we could do the same rescaling rigamarole as before, but the punchline is still the same.

% we have some image which is properly-scaled for its class
inpict_u8 = imread('cameraman.tif');
inpict_i16 = im2int16(inpict_u8); % imhist can do int16
N = 256; % imhist() default

% here, we're working in int12-scale, but we don't have a int12 numeric class
% so we have to create a mis-scaled image in something wide enough (e.g. int16)
ir = [0 2^8-1];
or = [-2^11 2^11-1];
scalefactor = diff(or)/diff(ir);
inpict_i12 = cast((double(inpict_u8) - ir(1))*scalefactor + or(1),'int16');

% IPT imhist() needs images to be scaled properly for their class
% both axes limits and bin location get determined by class,
subplot(4,1,1)
imhist(inpict_i16,N) % works with int16-scale int16
title('IPT imhist() works with a properly-scaled image')

% so adjusting xlim alone isn't enough to fix imhist() when the image is mis-scaled
subplot(4,1,2)
kscale = 2^16/2^12; % interval scale factor (this cannot always be correct)
Nadjusted = N*kscale; % need to use more bins to have the same density
imhist(inpict_i12,Nadjusted) 
xlim(or) % need to reset the xlimits obviously
ylim(ylim().*[1 sqrt(kscale)]) % but we need to rescale ylimits too!
title('Trying to make IPT imhist() work with an improperly-scaled image')
% that's okay, but try it with small N and you'll find out how wrong the scaling factor gets.
% since N and Nadj must both be integers, it's not always possible to adjust N to compensate for scale.
% ... and the colorbar is still wrong.
himg = findobj(gcf,'type','image');
strimg = kscale*(get(himg(1),'cdata')-0.5)+0.5;
set(himg(1),'cdata',strimg); % not quite, but close.
% this will need extra work in older versions.

% if you're going to just live without the colorbar,
% you could reinvent the wheel using histc()/histcounts() and stem().
% that would arguably be less work than trying to fix imhist().
subplot(4,1,3)
os = 0.5*diff(or)/(N-1);
breakpoints = linspace(or(1)-os,or(2)+os,N+1).';
centers = linspace(or(1),or(2),N).';
counts = histcounts(inpict_i12,breakpoints);
stem(centers,counts,'marker','none');
xlim(or);
ylim([0 2.5*sqrt(counts*counts.'/numel(counts))]); % this is why we had to rescale before
title('It''s easier to just use histcounts() and stem()')

% but i already did all that.
% MIMT imhistFB() has a bunch of extra functionality that imhist() doesn't.
% it does this sort of thing easily.
subplot(4,1,4)
imhistFB(inpict_i12,N,'range',or) % MIMT's imhist() replacement
title('But MIMT imhistFB() is easiest')

Even if you used int32 (or int64) as the parent class in a feverish attempt to consume more RAM, the call to imhistFB() isn't any different. This would require a bunch of extra adjustments to the plot manipulation if using imhist(). (and imhist() wouldn't support 64b integer classes).

% we have some image which is properly-scaled for its class
inpict_u8 = imread('cameraman.tif');
N = 256; % imhist() default

% use int32 this time instead
% since we're using MIMT, let's just use imcast() to rescale.
inpict_i12 = cast(imcast(inpict_u8,'uint8','int12'),'int32');

% similarly, we can use MIMT imclassrange(), since it now
% supports non-native integer scales too
or = imclassrange('int12'); % don't need to remember [-2^(n-1) 2^(n-1)-1]
imhistFB(inpict_i12,N,'range',or) % still the same

The answer here demonstrates a few other features of the MIMT tool, though the question itself should probably be given some consideration.

https://www.mathworks.com/matlabcentral/answers/2120156-why-does-imhist-do-this

Answer 2

[Image Analyst]

It's using the max of the data type, which is uint16. You can set the x axis to the max of the image varaible after you call imhist() like this:

xlim([0, max(Zoom(:)));

Answer 3

[Michael Haderlein]

The x scale depends on the data type of the image. I guess in your case, Zoom is of uint16? Then, the limits of the data are [0 65535] and that's the limits of the axes.

Now, the question is, how do to better in your case. Converting to the next smaller data type (uint8) won't help a lot as you have numbers too big for uint8 (must be max 255). Depending on your specific problem, I'd

- either normalize to max=1:

 imhist(Zoom/max(Zoom(:)))

- or use the "normal" hist function:

 hist(Zoom(:),1:max(Zoom(:)))

Best regards,

Michael

[Jason]

OK, Im playing with the following, but its not quite there:

%Automate x-axis labels---------------------------------------
[maxval1,idx]=double(max(ROI(:)))

XTck=get(handles.axes6,'XTick');
t_lim = 1e3*ceil(maxval/1000)       % get axis limit: 5000
t_ax  = 0:t_lim;
n_int = 20;                          % define # of intervals
t_int = t_lim/n_int;
tt    = t_ax(rem(t_ax,t_int)==0);   % find tick locations
ttlab = num2cell(tt)               % and generate tick labels
%---------------------------------------------------------------
[counts,x] = imhist(ROI,n_int);
set(handles.axes6,'XTick', tt,'XTickLabel',ttlab);
xlim([0 maxval])

Answer 4

[Adam]

I'm not familiar with imhist, but from a quick look it appears to always use the data type limits for its histogram range so I guess you would need to scale your data up to make better use of the available data range for a histogram using imhist.

[Jason]

But then, the histrogram doesn't tell me the frequency of the "actual" intesnity values?

[Adam]

It's just a linear mapping if you are scaling upwards which you would be doing for filling a data type range.