Why so different from Matlab to matplotlib (fft2 question)?

Community matplotlib-users
1

vmin and vmax dont seem to have any effect on the

    > resulting image, at least on my machine with the most
    > recent svn.

I haven't looked at his data or the output if fftshift. if vmin and
vmax do nothing, mpl is probably interpreting his image as RGB or
RGBA, which it would do if the output is MxNx3 or MxNx4 and thus would
not be applying scaling or color mapping. When using svn, vmin and
vmax do behave as expected in my test code:

In [3]: X = rand(10,10)

In [4]: subplot(211)
Out[4]: <matplotlib.axes.Subplot instance at 0xb5810f2c>

In [5]: imshow(X, vmin=0.45, vmax=.55)
Out[5]: <matplotlib.image.AxesImage instance at 0xb582516c>

In [6]: subplot(212)
Out[6]: <matplotlib.axes.Subplot instance at 0xb582af6c>

In [7]: imshow(X, vmin=0.0, vmax=1)
Out[7]: <matplotlib.image.AxesImage instance at 0xb58251ec>

I don't have time to look at this closely right now but maybe this
will give someone a hint...

JDH

2

That's the problem, I believe. 'imread' in mpl always reads images in
as MxNx4, while Matlab will check if the image is B&W and just do MxN.
Is there any way to force MxN behaviour in mpl?

Jay P.

···

On 1/26/07, John Hunter <jdhunter@...4...> wrote:

    > vmin and vmax dont seem to have any effect on the
    > resulting image, at least on my machine with the most
    > recent svn.

I haven't looked at his data or the output if fftshift. if vmin and
vmax do nothing, mpl is probably interpreting his image as RGB or
RGBA, which it would do if the output is MxNx3 or MxNx4 and thus would
not be applying scaling or color mapping. When using svn, vmin and
vmax do behave as expected in my test code: