Images don't show properly with imshow after certain calculation

Hello all,

The question is I need to calculate the matrix of a uint8 image. After the calculation (one order difference of the field) and normalization, I tried to figure out the image with imshow, however, the reults is a white blank or no longer smooth. The figure1.jpg can be any picture as you can find.

I should clarify that the values are uint8 after imread and I used "im2double" to transfer the type to double. The final imshow image is black and the final image will looks like some discrete dots when the matrix times 255.

clear all
deltax = 1;
deltay = 1;
AmpDistribution = imread('figure1.jpg')
 AmpDistributionDouble = im2double(AmpDistribution);
AmpDistributionDouble(isnan(AmpDistributionDouble))=0;
[MSize, NSize, VSize] = size(AmpDistributionDouble);
DiffoverA = zeros(MSize,NSize,VSize);
for i = 2: MSize-1
    for j = 2:NSize-1
        for k = 1:VSize
         DiffoverA(i,j,k) = (( AmpDistributionDouble(i+1,j,k) -AmpDistributionDouble(i,j,k))./(deltax) + (AmpDistributionDouble(i,j+1,k) -AmpDistributionDouble(i,j,k))./(deltay^2 ));
        end
    end
end
DiffoverA(isnan(DiffoverA))=0;
DiffoverA(DiffoverA==inf)=0;
MinValue = min(DiffoverA,[],'all');
MaxValue = max(DiffoverA,[],'all');
NormDelta = 255*(DiffoverA -abs(MinValue))/(MaxValue + abs(MinValue));
figure(1)
image(AmpDistribution);
figure(2)
imshow(AmpDistributionDouble,[]); 
figure(3)
imshow(NormDelta,[]);
shading interp

Answer 1

[Bjorn Gustavsson]

When you do things like this the errors are always (in my experience) in different normalizations and type-castings. To work these out I always go to the stage of looking at the individual R/G/B-planes of my images and check where they lie in intensity. Typically something like this:

subplot(2,2,1)
imagesc(NormDelta(:,:,1)),colorbar
subplot(2,2,2)
imagesc(NormDelta(:,:,2)),colorbar
subplot(2,2,3)
imagesc(NormDelta(:,:,3)),colorbar
subplot(2,2,4)
manualScale = @(I) (I-min(I(:)))/(max(I(:))-min(I(:)));
imagesc(manualScale(NormDelta))

Then you'll see where your normalised NormDelta are in intensity.

Finally: Your normalization step looks "very peculiar" to me, but I cant say if that is what you want.

HTH

[Walker]

Thank you very much for your help. I'll try to check every channel of the image. Since I found there are some negative values in my matrix, I would like to transofrm the data from uint8 to double format between 0-1. I have also tried the normalization like yours. However, after certation calculation, the values will be beyond that domain [0,1].

Anyway, maybe I should check the matrix for each channel . Thank you again.

[Bjorn Gustavsson]

Xinyuan, if we look at the normalization you do:

NormDelta = 255*(DiffoverA -abs(MinValue))/(MaxValue + abs(MinValue));

it behaves strangely for cases where MinValue are smaller than zero (if lets say it is -4, then you subtract abs(-4) from DiffoverA - which makes its smallest value now be -8, then you divide with the difference between the biggest value in DiffoverA and abs(-4), if that is 14, it will be 10 after subtracting abs(-4), after the division your ratio will be between -8/(18) and 10/18). If you use the normalization I've used you should be fine with values between 0 and 1.

I typically try to stay away from the int-types, if those are used one always have to remember checking for over-flows and wrappings...

[Walker]

Hi, Bjorn, thank you very much for your reply.

Actually I would like to calculat the matrix obeys the following eq.1

,

where

In the aforementioned simplified script, A(x,y) is replaced with the matrix of AmpDistributionDouble.

I are sorry that I did not show some complicated details in the first verison script. I thought this part should be correct. However, I have tried many times and found maybe it is because that there is a division of A(x,y). Since A(x,y) has some zeros values which results in inf and Nan values and I have set them both to be 0. These resutls in some isolated non-zero values.

[Bjorn Gustavsson]

No, no, no, no...

...you (or someone else that's very kind) pay good money for matlab, it provides you with a range of efficient functions for calculations of most everything. You should learn to be "productively lazy" and find ways to use matlab's built-in functions to do the work for you, and only as a last resort write functions that you cannot find in matlab or on the file exchange, that way you'll get more done quickly and more efficiently.

For your problem you can directly use the del2 function of matlab to do the heavy lifting:

D2ADD = del2(AmpDistributionDouble)/deltax/deltay; % This would give you the Laplacian of your image

Then you should have a think about the divisionwith AmpDistributionDouble, that will obviously blow up when you divide with small numbers, so you might consider replacing that with something like:

thresh = min(AmpDistributionDouble(AmpDistributionDouble(:)>0)); % or some small multiple of this, like 3?
D2ADDoverA = D2ADD./max(AmpDistributionDouble,thresh);

But first you should check the individual R/G/B-planes of each image you produce to check what their range of values are, then if you have small-scale structures in "dark" regions of your image |del2(D)| will obviously be large there, while D will be small so their ratio will become big and dominate the scaled image.

HTH

[Walker]

thank you very much for the reply， I found the reason for the black image is caused by zero value regions. Of course, thank you very much for the Laplacian function you tell me. I have tried with analytical functions and I can get resonable results since the values are not zeros although they are very small.

[Image Analyst]

Why not just use imgradent()? Or imgradientxy()?

[Bjorn Gustavsson]

Xinyuan, why not simply look at a 1-D case, just extract one row out of your image, plot the laplacian of that, plot the laplacian of that divided by the row itself and see where things go kaboom, and why. That things grow big when you multiply with values close to or equalt to zero is not strange.

[Walker]

@Image Analyst，thank you for your reply. My concerns are the laplacian difference of a function f divided by the function f itself, should be different from the gradient.

[Walker]

@Bjorn Gustavsson, thank you for the reply. Yes, I have actually confirmed that is caused by the image pattern. The distribution change of the image is not so obvious, which results in almost zeros values for 2 order difference(laplacian is 0) for quite a large of the image and the same time double precision values for the image are also very close to zeros. So I have to find ways to enlarge the difference.

[Walker]

I'm basically going back to another question: how to deal with nan and inf while ensuring the matrix data is continuous?

[Bjorn Gustavsson]

That is two completely different questions in one, inf typically occurs because of division-by-zero, tan(pi/2) etc, and is a mathematically reasonable result. Such things it is better to deal with by avoiding to end up in those situations - in principle.

NAN is the outcome of calculations like 0/0 (sin(0)/0 for example) that are numerically undefined, but might have a mathematically sensible value, or used to flag missing data etc. To handle this I typically use the inpaint_nans.

HTH

[Walker]

@Bjorn thank you very much for the reply.I used the min non -zero value and max finite value to replace the negative and the infinite values and have got some reasonable results. I'll try your method and compare the two methods. thank you so much. Have a nice weekend.

[Image Analyst]

Instead of

NormDelta = 255*(DiffoverA -abs(MinValue))/(MaxValue + abs(MinValue));

try using mat2gray(), rescale(), or imadjust(). And I would use imshow() with [] rather than image() or imagesc(). If the image still looks uniform, I'd examine the image in the workspace variable editor or look at its histogram. Maybe it really is largely the same value except for a very few pixels that are ruining the normalization.

[Walker]

@Image Analyst Thank you so much for your reply. imshow works well as you said. Yes, I'll try with other command. Until now, the results is basically resonable.@Bjorn Gustavsson @Image Analyst Thank you both very much.