From: Jay P. <pa...@gm...> - 2007-01-26 16:08:18
|
I'm trying to learn about 2D fourier transforms and k-space right now. To do this, I'm using the image at http://django.jayparlar.com/4kSnake.png In Matlab, I run the following code: Im = double(imread('4kSnake.png')); FT = fftshift(fft2(Im)); FT_Amp = abs(FT); minAmp = min(min(FT_Amp)); maxAmp = max(max(FT_Amp)); colormap gray; imagesc(FT_Amp,[minAmp 0.01*maxAmp]); and I get the result http://django.jayparlar.com/matlab.png (which is what it should look like). It matplotlib/ipython, I do the following: In [53]: a = imread("4kSnake.png") In [54]: a = double(imread("4kSnake.png")) In [55]: FT = fftpack.fftshift(fftpack.fft2(a)) In [56]: FT_Amp = abs(FT) In [57]: imshow(FT_Amp, cmap=cm.gray) and I get the result http://django.jayparlar.com/matplotlib.png Can anyone offer any insight as to why? I'm fairly new to matplotlib, but I'm a LONG time Python user, and would much rather continue my work in Python than Matlab. One issue might be the use of "minAmp" and "maxAmp" in the Matlab code, and no equivalent in the Python. I thought maybe the vmin/vmax arguments to 'imshow' might work, but they don't make much of a difference. For all I know, this could be a scipy issue, and not a matplotlib one, but I thought I'd start at the top and work my way down. Many thanks, Jay P. |
From: John H. <jdh...@ac...> - 2007-01-26 16:14:46
|
>>>>> "Jay" == Jay Parlar <pa...@gm...> writes: Jay> One issue might be the use of "minAmp" and "maxAmp" in the Jay> Matlab code, and no equivalent in the Python. I thought maybe Jay> the vmin/vmax arguments to 'imshow' might work, but they Jay> don't make much of a difference. vmin and vmax do scale the image -- if they do not appear to make a difference you are probably choosing improper ranges. Jay> For all I know, this could be a scipy issue, and not a Jay> matplotlib one, but I thought I'd start at the top and work Jay> my way down. I suggest you start at the bottom and work your way up, and inspect the results of fftshift in matlab and scipy. imshow doesn't do all that much, so if you are seeing big differences it is more likely in my opinion that you are feeding in different values. JDH |
From: Darren D. <dd...@co...> - 2007-01-26 16:32:28
|
On Friday 26 January 2007 11:14, John Hunter wrote: > >>>>> "Jay" == Jay Parlar <pa...@gm...> writes: > > Jay> One issue might be the use of "minAmp" and "maxAmp" in the > Jay> Matlab code, and no equivalent in the Python. I thought maybe > Jay> the vmin/vmax arguments to 'imshow' might work, but they > Jay> don't make much of a difference. > > vmin and vmax do scale the image -- if they do not appear to make a > difference you are probably choosing improper ranges. vmin and vmax dont seem to have any effect on the resulting image, at least on my machine with the most recent svn. > Jay> For all I know, this could be a scipy issue, and not a > Jay> matplotlib one, but I thought I'd start at the top and work > Jay> my way down. > > I suggest you start at the bottom and work your way up, and inspect > the results of fftshift in matlab and scipy. imshow doesn't do all > that much, so if you are seeing big differences it is more likely in > my opinion that you are feeding in different values. Aside from the ranges behaving strangely, something seems funny with the image itself. He selected the grey colormap, yet there are hints of yellow in the image. Darren |
From: John H. <jdh...@ac...> - 2007-01-26 16:37:29
|
>>>>> "Darren" == Darren Dale <dd...@co...> writes: Darren> vmin and vmax dont seem to have any effect on the Darren> resulting image, at least on my machine with the most Darren> 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 |
From: Jay P. <pa...@gm...> - 2007-01-26 16:41:40
|
On 1/26/07, John Hunter <jdh...@ac...> wrote: > >>>>> "Darren" == Darren Dale <dd...@co...> writes: > > Darren> vmin and vmax dont seem to have any effect on the > Darren> resulting image, at least on my machine with the most > Darren> 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: 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. |
From: John H. <jdh...@ac...> - 2007-01-26 17:40:43
|
>>>>> "Jay" == Jay Parlar <pa...@gm...> writes: Jay> That's the problem, I believe. 'imread' in mpl always reads Jay> images in as MxNx4, while Matlab will check if the image is Jay> B&W and just do MxN. Is there any way to force MxN behaviour Jay> in mpl? No way currently, but one could modify the png reader to do it.... Probably easiest is to use PIL and get a grayscale numpy array out, then mpl's colormapping and normalization will work as advertised. JDH |
From: Jay P. <pa...@gm...> - 2007-01-26 17:50:06
|
On 1/26/07, John Hunter <jdh...@ac...> wrote: > >>>>> "Jay" == Jay Parlar <pa...@gm...> writes: > > Jay> That's the problem, I believe. 'imread' in mpl always reads > Jay> images in as MxNx4, while Matlab will check if the image is > Jay> B&W and just do MxN. Is there any way to force MxN behaviour > Jay> in mpl? > > No way currently, but one could modify the png reader to do it.... > Probably easiest is to use PIL and get a grayscale numpy array out, > then mpl's colormapping and normalization will work as advertised. Beautiful, that worked like a charm. from PIL import Image im = Image.open("4kSnake.png") a = scipy.asarray(im) ft = fftpack.fftshift(fftpack.fft2(a)) ... Perfect! Thanks so much, Jay P. |