On 28/02/15 00:04, Robert Kern wrote:
> When plt.imshow() is given floating point RGB images, it assumes that
> each channel is normalized to 1. You are mixing a 0..255 image with a
> 0..1 image. Divide `lenna` by 255.0 before you stack it with `_dct`. Or
> multiply `_dct` by 255 and cast it to ui
On Fri, Feb 27, 2015 at 10:33 PM, Sturla Molden
wrote:
>
> Somewhere... But where is it?
>
> NumPy, SciPy, Matplotlib, Cython or ipython?
>
> I am suspecting ipython, but proving it is hard...
>
>
http://nbviewer.ipython.org/urls/dl.dropboxusercontent.com/u/12464039/lenna-bug.ipynb
When plt.imsho
On 27/02/15 23:39, Benjamin Root wrote:
> Is this another white-gold vs. blue-black dress color thing?
No. It is what you said in you next post.
I hate that dress image. The first time I looked at it it was white and
gold, then it became blue and black, and the third time it was grayish
blue an
On 27/02/15 23:40, Benjamin Root wrote:
> oh... I think I see what you are referring to. The second image should
> have the regular lenna image, not the negative?
Yeah. The ndarray references are getting messed up. It is actually quite
serious.
Sturla
>
> Ben Root
>
> On Fri, Feb 27, 2015 at
oh... I think I see what you are referring to. The second image should
have the regular lenna image, not the negative?
Ben Root
On Fri, Feb 27, 2015 at 5:39 PM, Benjamin Root wrote:
> It is Friday evening here... I must be really dense. What bug are we
> looking at? Is this another white-gold
It is Friday evening here... I must be really dense. What bug are we
looking at? Is this another white-gold vs. blue-black dress color thing?
Ben Root
On Fri, Feb 27, 2015 at 5:33 PM, Sturla Molden
wrote:
> Somewhere... But where is it?
>
> NumPy, SciPy, Matplotlib, Cython or ipython?
>
> I am
Somewhere... But where is it?
NumPy, SciPy, Matplotlib, Cython or ipython?
I am suspecting ipython, but proving it is hard...
http://nbviewer.ipython.org/urls/dl.dropboxusercontent.com/u/12464039/lenna-bug.ipynb
Sturla
___
NumPy-Discussion mailing l
Fri, 25 Mar 2011 13:40:54 +0100, Sturla Molden wrote:
> Den 25.03.2011 13:33, skrev Pauli Virtanen:
>> That npy_intp will not be redefined as ssize_t does not mean that the
>> type of array indices could not be changed.
>
> By the way, what is the resonable array index for AMD64, where 32-bit is
>
Den 25.03.2011 13:33, skrev Pauli Virtanen:
> That npy_intp will not be redefined as ssize_t does not mean that the
> type of array indices could not be changed.
By the way, what is the resonable array index for AMD64, where 32-bit is
the native offset size but size_t is 64 bit?
Sturla
_
Fri, 25 Mar 2011 13:23:11 +0100, Sturla Molden wrote:
> FFTs should keep the GIL locked, because sharing the interpreter is not
> funny.
> Array indices should be sizeof(void*), because following C standard and
> Python C API is lame.
> Median should be calculated in O(n log n) instead of O(n) time
FFTs should keep the GIL locked, because sharing the interpreter is not
funny.
Array indices should be sizeof(void*), because following C standard and
Python C API is lame.
Median should be calculated in O(n log n) instead of O(n) time, because
redundant sorting is gymnatics for the CPU.
But at
11 matches
Mail list logo
