> Greg,
>
> Thank you for your very clear and complete explanation.
>
> I have committed your patch with only a few modifications:
>
> 0) I fixed a bug with non-agg backends by setting im.is_grayscale.
>
> 1) I changed the handling of the interpolation kwarg. The default is
> still 'nearest'
[EMAIL PROTECTED] wrote:
> Hi Eric,
>
> I think I understand the two approaches you mention, I have about the
> same mental distinction although with a different spin, maybe because
> I come from finite element/data visualisation instead of image
> manipulation: I see basically two type of 2
Hi Eric,
I think I understand the two approaches you mention, I have about the
same mental distinction although with a different spin, maybe because
I come from finite element/data visualisation instead of image
manipulation: I see basically two type of 2D data that can be
visualized as a
Christopher Barker wrote:
> Michael Droettboom wrote:
>
>> It's funny you should mention this.
>>
>> One of the things I realized after SciPy this year is that there is a
>> lot of interfacing of Numpy with C++ (as opposed to C) that could really
>> benefit from a standard C++ wrapper around N
Grégory Lielens wrote:
> Thanks a lot for reviewing my patch!
> I have corrected most of the problems (I think ;-) )
> I indeed introduced memory leak, I think it is fixed now, I have also
> reorganized the code to avoid duplication of the cleanup code. I used an
> helper function instead of the go
Michael Droettboom wrote:
> It's funny you should mention this.
>
> One of the things I realized after SciPy this year is that there is a
> lot of interfacing of Numpy with C++ (as opposed to C) that could really
> benefit from a standard C++ wrapper around Numpy.
Absolutely. Though now that yo
It's funny you should mention this.
One of the things I realized after SciPy this year is that there is a
lot of interfacing of Numpy with C++ (as opposed to C) that could really
benefit from a standard C++ wrapper around Numpy. A bunch of different
projects all had home-grown, semi-complete s
Michael Droettboom wrote:
> I think we want to use std::vector where possible for new code, and
> convert as we go through old code. Manual malloc/free is just too error
> prone. (We're forced to do some by interfacing with Python, but it
> should be kept to a minimum).
My understanding is th
I'm going to again defer the real question of the functionality and
interface etc. to Eric and/or John etc., though it seems good in general.
I just have a couple of follow on comments related to implementation
details below.
Grégory Lielens wrote:
> std::vector would have been nice, but I trie
Hi John, Hi Eric,
In case this has slipped under the radar, I repost my patch for bilinear interp
in NonUniformImage (including the discussion around it). I think Eric is the
most concerned by this, but you were both
on holidays when I raised the issue in matplotlib newsgroup.
Best regards,
G
Thanks a lot for reviewing my patch!
I have corrected most of the problems (I think ;-) )
I indeed introduced memory leak, I think it is fixed now, I have also
reorganized the code to avoid duplication of the cleanup code. I used an
helper function instead of the goto, because this cleanup is neede
Hi all,
here is a patch which implement bilinear interpolation on irregular grid
( i.e. it allows NonUniformImage
to accept both 'nearest' and 'bilinear' interpoaltion, instead of only
'nearest'.)
It is not perfect, given the current architecture of the image module I
think there is not simple
12 matches
Mail list logo
