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
Problem with Imhist method
16 次查看(过去 30 天)
显示 更早的评论
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
![](https://www.mathworks.com/matlabcentral/answers/uploaded_files/145835/image.png)
So the histogram is just a spike.
why does it not autorange the x-axis, and how too?
thanks Jason
采纳的回答
DGM
2024-5-20
编辑:DGM
2024-7-4
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')
![](https://www.mathworks.com/matlabcentral/answers/uploaded_files/1698861/image.png)
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')
![](https://www.mathworks.com/matlabcentral/answers/uploaded_files/1698866/image.png)
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
![](https://www.mathworks.com/matlabcentral/answers/uploaded_files/1698871/image.png)
The answer here demonstrates a few other features of the MIMT tool, though the question itself should probably be given some consideration.
0 个评论
更多回答(3 个)
Image Analyst
2014-10-23
编辑:Image Analyst
2014-10-23
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(:)));
0 个评论
Michael Haderlein
2014-10-23
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
Adam
2014-10-23
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.
2 个评论
Adam
2014-10-23
It's just a linear mapping if you are scaling upwards which you would be doing for filling a data type range.
另请参阅
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!